Skip to article
Storage Data Lake Storage Gen2

Default ACL

A default ACL in Azure Data Lake Storage Gen2 is an ACL entry on a directory that new child files and directories inherit when they are created under that directory.

Source: Microsoft Learn - Access control lists in Azure Data Lake Storage Reviewed 2026-05-13

Exam trap
Changing production before checking the exact owner, scope, downstream dependency, monitoring evidence, and rollback impact.
Production check
Can you name the owner, parent resource, environment, and downstream dependency without guessing?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
default access control list, ADLS Gen2 default ACL, directory default ACL
Difficulty
intermediate
CLI mappings
4
Last verified
2026-05-13
Learning paths Graph Storage concept cluster Default ACL
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Default ACL is a Data Lake Storage Gen2 directory permission template that new child files and directories inherit at creation time. In Azure, it helps teams make future data lake paths receive predictable POSIX-like permissions without manually setting every new folder or file. Plainly, it is a named operating concept that connects design intent with live configuration, evidence, ownership, and production impact. A useful glossary entry should show where it lives, who controls it, what depends on it, and what signal proves it is working.

Why it matters

Default ACL matters because it turns architecture language into something teams can secure, monitor, troubleshoot, and explain under pressure. When it is documented shallowly, engineers may change the wrong resource, policy, identity, database, queue, workspace, or path while the real dependency remains untouched. In enterprise Azure projects, the value is shared language: platform, security, data, finance, and operations teams can discuss the same object without guessing. That reduces incident time, improves audit evidence, prevents avoidable rework, and makes migrations safer because downstream consumers and failure modes are visible before release. Treat Default ACL as production owned when scheduled jobs, regulated data, customer traffic, or security monitoring depends on it.

Technical context

Technically, Default ACL appears in ADLS Gen2 hierarchical namespace, directory ACL entries, path permissions, storage account RBAC, data lake tooling, and recursive ACL jobs and interacts with Azure Data Lake Storage Gen2, Azure Storage, Azure Databricks, and Azure Synapse Analytics. Configuration is reviewed through default user ACL, default group ACL, mask entry, and access ACL, while operators validate live state through path ACL output, inherited child permissions, effective mask, and owner and group. Scope matters because the same word can refer to a portal setting, API property, runtime behavior, or governance control.

Exam context

Compare with

Path ACL RBAC SAS permissions

Where it is used

Where you see it

  1. In Storage Explorer or the portal, a directory ACL shows default entries separately from access entries that control the current path during production review before an approved change.
  2. In pipeline failures, default ACL appears when newly created folders behave differently from older paths that were never recursively updated during production review before an approved change.
  3. In security reviews, default ACL appears when teams prove future landed files inherit approved group permissions without granting broad account-level access during production review before an approved change.

Common situations

  • Set inherited permissions for new data lake files and folders created by ingestion pipelines.
  • Troubleshoot why a new child folder has different permissions than an existing sibling.
  • Design least-privilege zone access without granting broad storage account permissions.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Default ACL in action for consumer packaged goods Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Luma Foods, a consumer packaged goods organization, needed to address new supplier folders landed without the group permissions analysts expected. The architecture team used Default ACL as the control point for a measurable production improvement.

Goals
  • Standardize permissions for new folders
  • Reduce manual ACL fixes by 70 percent
  • Keep supplier data separated by region
Approach using Default ACL

The storage team designed Default ACL entries on each regional ingestion directory in ADLS Gen2. Microsoft Entra groups represented analysts, pipeline identities, and support users. Existing folders received a controlled recursive update, while new child paths inherited default entries automatically when ingestion jobs created them. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps.

Potential outcomes
  • Manual permission fixes dropped 82 percent
  • New supplier onboarding time fell from two days to four hours
  • No regional data boundary exception was found in review
What to learn

Default ACL keeps future data lake paths aligned with the access model teams approved.

Scenario 02 Default ACL in action for higher education research Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Northlake University, a higher education research organization, needed to address research projects created nested data folders that inherited inconsistent permissions. The architecture team used Default ACL as the control point for a measurable production improvement.

Goals
  • Apply repeatable project-folder access
  • Protect restricted research data
  • Give principal investigators clear ownership evidence
Approach using Default ACL

The platform team mapped Default ACL entries to project groups and service identities on top-level ADLS Gen2 directories. Access ACLs controlled the current directory, while default ACLs controlled new experiment folders. A monthly report compared effective ACLs, masks, and group ownership for each active research workspace. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout.

Potential outcomes
  • Access review effort dropped 60 percent
  • Unauthorized cross-project access exceptions went to zero
  • New experiment folder setup became self-service
What to learn

Default ACL turns data lake permission inheritance into a governable operating practice.

Scenario 03 Default ACL in action for public sector data sharing Scenario, objectives, solution, measured impact, and takeaway.
Scenario

CivicData Exchange, a public sector data sharing organization, needed to address public and restricted datasets were created under the same lake with confusing inherited access. The architecture team used Default ACL as the control point for a measurable production improvement.

Goals
  • Separate public and restricted inheritance
  • Reduce accidental broad grants
  • Support repeatable audit checks
Approach using Default ACL

Architects created distinct ingestion, curated, and open-data directories with different Default ACL entries. Managed identities received only the paths they needed, and human access used Microsoft Entra groups. The team documented when recursive ACL updates were required for existing files versus when defaults would protect new files. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps. The design was tested in a lower environment so security, operations, and finance teams could review the impact before production rollout. Support staff received clear checks for resource state, identity, cost, telemetry, and downstream dependency health. Engineers captured before-and-after evidence, updated the runbook, and tied the change to named owners, monitoring signals, and rollback steps.

Potential outcomes
  • Broad storage-account access was reduced by 75 percent
  • Audit sampling found consistent permissions on new paths
  • Support tickets about inherited access fell by half
What to learn

Default ACL is valuable because future child paths are where permission drift often starts.

Azure CLI

CLI checks for Default ACL are useful because they turn portal assumptions into repeatable evidence. Start with read-only commands that show the resource, definition, permissions, metrics, or runtime state, then compare the output with the intended design. Use mutating commands only through an approved change process with owner, rollback, and impact notes. For Default ACL, evidence should be captured before and after production changes.

Useful for

  • Set inherited permissions for new data lake files and folders created by ingestion pipelines.
  • Troubleshoot why a new child folder has different permissions than an existing sibling.
  • Design least-privilege zone access without granting broad storage account permissions.

Before you run a command

  • Run az account show, confirm tenant and subscription, and verify the operator identity has approved read access for the exact scope.
  • Confirm the resource group, workspace, account, queue, container, file system, app registration, or security plan name before collecting evidence.
  • Prefer read-only commands first; review any command that changes access, cost, compute state, network exposure, message settlement, or production data.

What the output tells you

  • Whether the object exists in the expected Azure resource, tenant, workspace, account, namespace, or governance boundary.
  • Which owner, identity, permission, status, metric, endpoint, throughput setting, ACL, security plan, or runtime value is visible to the current operator.
  • Whether the issue is missing scope, permission drift, wrong environment, network misconfiguration, stale deployment, service health, or resource state.

Mapped commands

Default ACL operational checks

direct 
az storage account show --name <storage-account> --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage fs list --account-name <storage-account> --auth-mode login
az storage fsdiscoverStorage
read-only Microsoft Learn 
az storage fs directory show-permission --account-name <storage-account> --file-system <file-system> --name <directory> --auth-mode login
az storage fs directorydiscoverStorage
read-only Microsoft Learn 
az storage fs directory set-permission --account-name <storage-account> --file-system <file-system> --name <directory> --acl <acl> --auth-mode login
az storage fs directoryoperateStorage
mutating Microsoft Learn

Architecture context

Default ACL belongs to Storage architecture decisions where identity, networking, monitoring, cost ownership, and production support need shared evidence.

Security
Security for Default ACL starts with least privilege, identity clarity, and evidence that access matches the workload classification. Review least-privilege groups, RBAC and ACL combination, mask entries, sensitive directory boundaries, and recursive updates before approving production use. A common failure is assuming that a successful portal action, query, message receive, or scan result proves the design is secure. Use Microsoft Entra groups, managed identities, role assignments, private connectivity, audit logs, and service-specific privileges where applicable. Keep exceptions ticketed, time-bounded, and tied to a named owner. For regulated workloads, align the configuration with classification, retention, break-glass, and incident-response procedures. Remove broad access, stale secrets, unreviewed public paths, and undocumented administrator permissions before Default ACL becomes an incident path.
Cost
Cost for Default ACL appears through compute duration, request units, protected endpoints, storage growth, diagnostic retention, operational toil, and the downstream work triggered by bad configuration. Review manual permission fixes, failed pipeline reruns, support tickets, overbroad access remediation, and recursive operation time before expanding production use. Some costs are direct, such as DWU compute, container app profile instances, Cosmos DB throughput, security plan coverage, or storage; others are indirect, such as retries, manual evidence collection, delayed restores, and failed jobs. Tag related Azure resources, monitor usage, and separate exploratory work from production workloads. A cost review should connect spend to a real owner and measurable value.
Reliability
Reliability for Default ACL depends on repeatable configuration, tested dependencies, and clear failure signals. Watch new file inheritance, existing child paths, recursive ACL consistency, pipeline identity access, and folder rename behavior because drift often appears later as missed schedules, failed restores, broken private connectivity, stuck messages, slow queries, or incomplete security coverage. Use lower environments, source-controlled definitions where possible, deployment checks, monitoring, and rollback notes before changing production. Operators should know which resource, endpoint, identity, data path, queue, database, or downstream system fails first and which log or metric proves the failure. The goal is predictable recovery: detect Default ACL drift, protect data, restore service, and explain the incident without guessing.
Performance
Performance for Default ACL depends on workload shape, data layout, network path, scale limits, governance choices, and the compute or broker path used to access it. Review authorization checks, recursive ACL operation scale, folder depth, pipeline retries, and data lake listing volume before increasing capacity. The better fix might be scheduling, query tuning, partition design, throughput allocation, lock handling, file compaction, path validation, or clearer orchestration. Measure with representative traffic and data, not a tiny sample that hides production behavior. Operators should connect symptoms to evidence: latency, queue depth, RU consumption, CPU, scan volume, failed stages, status changes, or run duration.
Operations
Operations for Default ACL should focus on ownership, observability, and safe repeatability. Standardize naming, tags, owner groups, environment labels, diagnostic destinations, runbook links, and change approvals so support teams do not reverse-engineer the design during an incident. Use read-only CLI, API, SQL, or portal checks first, then compare live state with the intended configuration. For production, connect alerts, audit events, cost records, access reviews, and release notes to the same term. The support question should be simple: who owns it, what changed, and what proves the current state?. Capture owner, scope, evidence, and rollback before changing Default ACL in a production environment.

Common mistakes

  • Changing production before checking the exact owner, scope, downstream dependency, monitoring evidence, and rollback impact.
  • Using a portal screenshot as the only record when CLI, API, audit logs, SQL, or source-controlled configuration can provide repeatable evidence.
  • Assuming management-plane permissions, data-plane permissions, and service-specific privileges are granted and reviewed by the same team.