A pipeline's service principal gets 403 reading `/raw/sales/2026/10/15/orders.parquet` in ADLS Gen2, even though you gave it Read on that file. After you fix it, files that land the next day fail again. What is going on, and how do you set permissions so it stays fixed?

2 separate mistakes. First, ACLs need Execute on every folder on the path, from the container root down, not only Read on the file. Second, the ACL you set was an access ACL on existing items; new folders and files take their ACL from the parent's default ACL, which you never set. Grant a security group Execute on the parents, Read and Execute on the data folders with a matching default ACL, apply it recursively once, and put the service principal in the group.

1. How ADLS decides

1. Azure roles first: a Storage Blob Data Reader, Contributor or Owner role on the account or container grants access, and ACLs are not consulted. (Owner or Contributor on the resource does not grant data access.)
2. Then ACLs, checked on every item along the path.

So the 403 means the principal has no data role there and the ACLs along the path fall short.

2. What reading 1 file needs with ACLs only

Execute on a folder means "may pass through it". Without it on any one level, the file is unreachable whatever its own ACL says. To list a folder (which Spark and ADF usually do), that folder needs r-x.

3. Why tomorrow's files fail

Each day creates new folders 2026/10/16/. A new item gets its access ACL from its parent's default ACL. You set only access ACLs, so the new folder and its files carry none of your entries. Changing a default ACL later also does not change items that already exist, so both steps are needed.

4. The setup that lasts

1. Create a security group for readers of raw sales and add the service principal to it.
2. On / and /raw, add group:<group>:--x to the access ACL of those folders alone (portal, Storage Explorer or the SDK), so the group can pass through but not list everything below raw.
3. On /raw/sales, the folder that holds the data, add read and execute for now and for everything created later, applied to what exists:

az storage fs access update-recursive \
  --acl "group:<group-object-id>:r-x,default:group:<group-object-id>:r-x" \
  -p raw/sales -f datalake --account-name lake01 --auth-mode login

Every year, month and day folder created under sales from now on inherits the entries.

Practices that avoid repeats:

• Groups, not principals in ACLs. Each item allows 32 entries (about 28 usable), and changing a group's members needs no ACL change on millions of files.
• Use the service principal's object ID (enterprise application), not the app registration's, if you ever add one directly.
• If the job is broadly trusted, a Storage Blob Data Reader role on the container is simpler than ACLs. Keep in mind an ACL cannot take back what a role grants.
• Check the mask if a named entry looks right but still fails: it caps the effective permission of named and group entries.

What interviewers want: Execute on each parent folder, Read and Execute to list, access versus default ACLs and why new items miss out, role assignments evaluated before ACLs, groups instead of individual principals, and the object ID trap.