Articles

ADLS Gen2 Interview Questions: RBAC, ACL Masks, and Directory Traversal

Practice ADLS Gen2 interview questions with RBAC authorization, ACL mask calculations, directory traversal cases, and verifiable permission-repair checks.

A workload can read an ADLS Gen2 file even after someone removes its ACL entry. Another workload can have r-- on that same file and still receive an authorization error. Both outcomes can follow the documented rules: the first may already have a sufficient RBAC grant, while the second cannot traverse a parent directory.

Approach ADLS Gen2 interview questions by separating the identity and authorization route, the operation being requested, and the permissions on the complete path. This guide develops that approach through a mask calculation, a directory-traversal case, and a repair review. It focuses on hierarchical-namespace accounts using Microsoft Entra identities. It does not claim that a particular employer asks these exercises.

For a warm-up, try Compute Effective Letter Permissions in a DAG. Treat its rules as that exercise's rules; ADLS access ACLs and default ACLs have their own semantics.

What should an ADLS Gen2 interview answer establish first?

Five questions determine the next useful investigation:

Which principal made the failing request, and which credential type did it use?
Does an applicable data-plane RBAC grant already authorize this operation?
If authorization reaches ACL evaluation, which entry and mask matter?
Can the principal traverse every parent and perform the requested target operation?
Did the change affect current access ACLs, future-child defaults, or both?

Official fact: Microsoft documents an authorization sequence in which a sufficient applicable RBAC grant, including relevant conditions, allows access before ACL evaluation. ACLs cannot restrict access already allowed that way. An insufficient grant does not itself establish the final outcome; ACL evaluation can still matter. See the ADLS access-control model.

Evidence boundary: Product behavior below comes from linked Microsoft documentation. The numerical cases, diagnostic order, and answer examples are original preparation exercises and reasoning. No independently verified candidate report is used here, so none of the questions is presented as an observed interview question or a prediction about interview frequency.

Starting at the wrong layer can send the investigation toward permissions that never governed the request. “Show me the ACL” is premature if the request used a different principal, or if an account key selected a different authorization route.

Does Storage Account Contributor mean the application can read files?

Official fact: Management roles and blob data roles serve different purposes. Microsoft distinguishes roles such as Contributor from Storage Blob Data Reader, Contributor, and Owner, and documents assignment scope. Creating a storage account does not automatically give its creator Entra-authorized data access. See assigning an Azure role for blob data access.

Interview exercise: An operator can open an account in the portal. A scheduled job cannot read its input file. The operator says, “I have Contributor, so permissions are fine.”

A stronger response identifies two principals and two operations. The operator's ability to manage the resource does not prove that the job's managed identity can read blob data. Ask for the job identity's object ID, role definition, assignment scope, and the exact failed operation. Do not substitute the application registration's display name for an identity comparison.

Microsoft's Entra authorization overview describes token-based access to Blob Storage. Use that distinction to explain why an administrator's successful interactive request is a poor control experiment for a workload using a different identity.

Now change the case: the job has Storage Blob Data Reader at the container scope, with an applicable unconditional grant. Removing the job's named ACL entry is not a reliable way to revoke its read access. The authorization route already explains the successful read.

The design discussion should therefore name the grant that must change, the intended scope, and who owns that access decision. First collect the identity, scope, operation, and effective permissions needed to justify a targeted repair. A narrow read probe under the actual workload identity is more informative than an administrator's successful directory listing.

How does an ACL mask change effective permissions?

Official fact: Microsoft's ACL documentation describes the mask as limiting named-user entries, named-group entries, and the owning group's permissions. The owning user and other entry are outside that mask limit. Directory execute permits traversal, while directory read permits listing.

Original calculation: Assume ACL evaluation applies, the principal matches a named-user entry, and no other authorization route grants the operation. Encode read, write, and execute as 4, 2, and 1. Intersect the entry's bits with the mask:

Named-user entry	Mask	Effective bits	Effective permissions
`rwx` = 7	`r-x` = 5	`7 & 5 = 5`	`r-x`
`rw-` = 6	`r-x` = 5	`6 & 5 = 4`	`r--`
`--x` = 1	`r--` = 4	`1 & 4 = 0`	`---`

The third row exposes a useful failure: adding execute to a named entry accomplishes nothing if the mask removes execute. Reading the named entry alone can therefore lead you to propose a fix that changes nothing.

This small function models only that intersection:

def effective_named_permissions(entry, mask):
    if not 0 <= entry <= 7 or not 0 <= mask <= 7:
        raise ValueError("permission bits must be between 0 and 7")
    return entry & mask

assert effective_named_permissions(7, 5) == 5
assert effective_named_permissions(6, 5) == 4
assert effective_named_permissions(1, 4) == 0

It is not a complete ADLS authorization engine. It does not implement role conditions, credential routes, identity matching, group handling, or operation-specific path requirements. State that boundary before presenting the function as evidence.

In an interview, also distinguish a missing permission from a deny rule. An ACL entry without write is not an independently overriding veto on a sufficient RBAC grant. Avoid importing a generic “deny wins” policy into this product without checking its documented authorization model.

Why can a readable file still be inaccessible?

Original directory-traversal case: A service needs to read /analytics/2026/oct/report.parquet. Assume it uses Entra authorization, has no sufficient RBAC grant, is not an owning user, and its named-user entries determine the permissions shown below. The table already includes each item's mask.

Item	Effective permission	Requirement for this direct file read	Result
`/`	`--x`	Traverse	Pass
`/analytics`	`--x`	Traverse	Pass
`/analytics/2026`	`r--`	Traverse	Fail
`/analytics/2026/oct`	`--x`	Traverse	Pass
`report.parquet`	`r--`	Read file	Pass

Under these explicit ACL-only assumptions, the missing execute permission on the parent explains the failed file read. For this stated case, the smallest proposed permission repair is effective execute on /analytics/2026. Rechecking its mask is part of that proposal. Granting write to the file does not address the missing traversal permission.

Now ask a different question: “Can this service list /analytics/2026/oct?” The target directory needs listing permission as well as traversal. A principal that can read a known file path may be unable to enumerate its directory. That difference is useful for least-privilege designs and for interpreting a debugging probe.

A third operation, creating a child file, changes the target requirement again. An interview answer should name the operation before calculating permissions. “Access works” is too broad when read, list, create, delete, and ACL administration can have different requirements.

For each proposed fix, predict two observations: the operation that should begin succeeding, and an operation that should remain unauthorized under the exercise's intended policy. A permission change without a negative check can accidentally hide an overly broad grant.

Will changing a parent default ACL repair existing files?

Official fact: The ACL guide distinguishes an access ACL from a default ACL. A directory's default ACL supplies permissions for newly created children; changing it does not retroactively update existing children. Files have access ACLs, while directories can also carry defaults. This is a creation-time template, not continuous propagation through a permission graph.

Original timeline exercise: At 09:00, oct has a default named-user entry that permits reading. At 09:10, a.parquet is created. At 09:20, an administrator changes the parent's default entry to remove that read permission. At 09:30, b.parquet is created.

Do not infer that a.parquet and b.parquet now have identical access ACLs. Inspect their current entries. The older file is not repaired merely because a newer sibling reflects the new template.

Add another complication: the parent access ACL changes at 09:20, but the default ACL does not. That may change access to the parent itself without changing the permissions that future children receive. A repair request that says “update the folder permissions” needs to identify both scopes explicitly.

This is why the DAG practice questions below are transfer exercises, not specifications of ADLS inheritance. Their graph rules help you reason carefully about propagation; the product's creation-time defaults determine what actually propagates here.

How would you review a recursive ACL repair?

Official fact: Microsoft's Python ACL guide distinguishes recursive update from recursive set: update modifies supplied entries, while set replaces the ACL. It also documents failure handling, continuation tokens, and success/failure counters.

Original review checklist: Before approving a recursive proposal, request an inventory containing the root path, principal object ID, access/default scope, intended entries, mask expectations, and ownership of the change. Compare the proposed operation with existing entries that must survive.

A recursive update of one named-user entry and a recursive replacement of the complete ACL have different review risks. Replacing an entire ACL can remove unrelated permissions if the replacement payload omits them. Updating one entry still needs mask review: a correct-looking named-user value may remain ineffective.

Define completion in terms of inspected results. Record successful file and directory counts, failure counts, the remaining continuation state when applicable, and sampled ACL readbacks. “The script returned” does not prove that every item received the intended permissions.

If some children fail because the repair identity cannot modify them, preserve their paths and error evidence. Address that specific authority problem before resuming or restarting according to the SDK's documented behavior. Do not change the reader identity's role simply to make the repair process finish.

The portal ACL guide explains the authority needed to manage ACLs. Keep that administrative identity separate from the workload whose eventual read behavior you are testing.

Give an answer that another engineer can verify

A concise answer to the traversal case could be:

“I would first confirm the request's identity and credential route. In the stated ACL-only case, the file permits reading, but /analytics/2026 lacks effective execute. I would propose a targeted traversal repair, inspect its mask, and retry the exact read under the service identity. I would separately test directory listing because that is a different permission request.”

That answer includes assumptions, a calculation, a narrow change, and observable verification. If the interviewer introduces a sufficient container-level RBAC grant, revise the explanation instead of defending the original ACL diagnosis.

For your next practice session, solve Compute Effective Letter Permissions in a DAG, then rewrite its answer for the ADLS named-user mask and parent-path case. The useful preparation is explaining exactly which rules changed and what evidence would confirm the result.