Build ADLS Gen2 filesystem configurations with POSIX ACLs and lifecycle policies.
Last verified: May 2026
Build ADLS Gen2 filesystem, ACL, and lifecycle management configurations.
Required Fields
storageAccountNameresourceGroupisHnsEnabledfilesystemsfilesystems[0].nameOutput will appear here...The builder configures ADLS Gen2 with: storage account creation parameters (tier: Hot/Cool/Cold, redundancy: LRS/ZRS/GRS, hierarchical namespace ENABLED), filesystem containers, POSIX ACLs (per file/directory with named users/groups, default ACLs for inheritance), lifecycle policies (rules for tiering and deletion based on age/access time), and network access rules. Output is generated as az storage commands and Terraform azurerm_storage_account + azurerm_storage_data_lake_gen2_filesystem resources.
Azure Data Lake Storage Gen2 combines the scalability of Azure Blob Storage with a hierarchical namespace optimized for big data analytics. Built on top of Azure Storage accounts, Gen2 adds POSIX-compliant access control lists (ACLs), directory-level operations, and integration with analytics services like Synapse, Databricks, and HDInsight. Configuration involves enabling the hierarchical namespace, defining filesystem containers, setting POSIX ACLs for fine-grained access, and creating lifecycle management policies for tiering data to cool or archive tiers. The Config Builder helps you define these settings correctly.
Your team is building a multi-tenant data lake where 5 analytics teams need isolated access to their own data within a shared lake. The builder generates: a single ADLS Gen2 storage account with hierarchical namespace, 5 filesystem containers (one per team), default ACLs on each setting team-specific group permissions (e.g., team-1-analysts get read+execute, team-1-engineers get full control), and lifecycle policies tiering data older than 90 days to cool. Centralized lake with team isolation, no cross-team data exposure, automatic cost optimization via tiering.
ENABLE the hierarchical namespace at storage account creation — it CANNOT be enabled later. If you accidentally create a regular Blob storage account and need Gen2 features, you have to migrate data to a new account. Always default to enabling hierarchical namespace for any analytics-oriented storage account.
Default ACLs on parent directories are inherited by NEWLY CREATED children, but NOT applied retroactively. If you change the default ACL, existing files keep their original ACLs. For consistency across an existing data lake, you may need to recursively reapply ACLs via a script.
RBAC is checked FIRST, then ACLs. If a user has Storage Blob Data Reader at the storage account level via RBAC, they can read EVERYTHING regardless of ACLs. For data-lake-style isolation across teams, grant minimum RBAC at the storage account level and use ACLs for fine-grained control within.
Gen2 supports POSIX-style ACLs with access ACLs (control permissions for a specific file or directory) and default ACLs (inherited by new child items in a directory). Each ACL entry specifies a principal (user, group, or other), and permissions are read (r), write (w), and execute (x). The execute permission on directories allows listing contents. ACLs are evaluated in order: owning user, named users, owning group or named groups, other. Unlike Blob Storage RBAC, ACLs provide file-level and directory-level granularity, which is essential for multi-team data lake architectures.
Use both, but for different purposes. Azure RBAC roles (Storage Blob Data Owner, Contributor, Reader) are evaluated first and grant broad access at the storage account or container level — ideal for service principals and administrators. POSIX ACLs provide fine-grained control at the directory and file level — ideal for restricting data scientists to specific folders. A common pattern is to assign Storage Blob Data Contributor to ETL pipelines (they need broad write access) and use ACLs to give analytics users read-only access to specific datasets within the lake.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.