Skip to article
Storage Data Lake Storage Gen2

Data Lake storage account

A storage feature or access model in Data Lake Storage Gen2 that helps teams store, protect, move, and govern application or analytics data with clearer ownership, safety, and operational context.

Source: Microsoft Learn - Azure Data Lake Storage Gen2 documentation Reviewed 2026-05-03

Exam trap
Treating Data Lake storage account as an isolated setting instead of checking the surrounding identity, network, data protection, and cost context.
Production check
Can you identify the subscription and resource group that own Data Lake storage account?
Practice this topic Microsoft Learn
Article details and learning context
Aliases
None listed
Difficulty
advanced
CLI mappings
19
Last verified
2026-05-03
Learning paths Graph Storage concept cluster Data Lake storage account
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Think of Data Lake storage account as part of the storage operating model. It gives architects, developers, and operators a named way to discuss what must be configured, checked, automated, or monitored before a production change.

Why it matters

Data Lake storage account matters because storage decisions become production behavior: cost, security, reliability, performance, and supportability all depend on whether the team understands the resource, setting, or pattern before changing it.

Official wording and source

Data Lake storage account is a Microsoft Learn storage feature or access model for Data Lake Storage Gen2. It affects how teams store, protect, move, and govern application or analytics data across accounts, blobs, files, queues, tables, data lakes, replication, and access controls.

Open Microsoft Learn

Technical context

In Azure, Data Lake storage account belongs to the Data Lake Storage Gen2 area and usually shows up when a workload crosses resource configuration, identity, networking, data, or operations boundaries. The mapped CLI commands, especially commands near az storage fs, help turn the term from a definition into something you can inventory, verify, automate, or troubleshoot.

Exam context

Compare with

Data Lake Storage Gen2 Blob Storage

Where it is used

Where you see it

  1. Data Lake Storage Gen2
  2. Storage account overview
  3. Containers
  4. File shares
  5. Data Lake file systems

Common situations

  • Choose how files, objects, queues, or lake data are stored and accessed.
  • Troubleshoot permissions, private networking, lifecycle, replication, or performance issues.
  • Separate application storage from analytics lake storage and backup/archive storage.
  • Document data access, retention, and recovery behavior.

Illustrative Azure scenarios

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

Using Data Lake storage account during a production Azure change

Before a team changes a live workload, they can review Data Lake storage account, check the related terms, run read-only CLI discovery commands, and confirm the Microsoft Learn source. That gives the change owner enough context to decide whether the next step is safe, cost-impacting, security-impacting, or destructive.

Azure CLI

Use Azure CLI for Data Lake storage account when you need repeatable evidence or automation instead of a one-off portal check. Commands near az storage fs let you inspect current state, script environment setup, compare dev/test/prod, and document exactly what changed.

Useful for

  • List containers, shares, file systems, keys, and account settings during operations.
  • Automate storage account, container, ACL, or lifecycle setup.
  • Verify network rules, encryption, identity, and public access configuration.
  • Capture storage state before changing data access or deletion policies.

Before you run a command

  • Run az account show and confirm the tenant, subscription, and user or service principal context.
  • Confirm the resource group, resource name, and region match the environment you intend to inspect or change.
  • Prefer read-only discovery commands first; only run mutating, cost-impacting, security-impacting, or destructive commands after review.
  • Copy command output into a change record or incident notes when the command is used for production evidence.

What the output tells you

  • Whether Data Lake storage account exists at the expected Azure scope and under the expected resource owner.
  • Which location, SKU, identity, network, state, or relationship fields are currently configured.
  • Whether the command is showing a resource problem, an access problem, a naming/scope problem, or a missing dependency.
  • What safe follow-up command or related term should be checked next.

Mapped commands

Data Lake Storage Gen2 operations

direct 
az storage fs list --account-name <storage-account> --auth-mode login
az storage fsdiscoverStorage
read-only Microsoft Learn 
az storage fs create --name <filesystem> --account-name <storage-account> --auth-mode login
az storage fsprovisionStorage
mutating Microsoft Learn 
az storage fs directory create --file-system <filesystem> --name <directory> --account-name <storage-account> --auth-mode login
az storage fs directoryprovisionStorage
mutating Microsoft Learn 
az storage fs file upload --file-system <filesystem> --source <path> --path <target-path> --account-name <storage-account> --auth-mode login
az storage fs fileoperateStorage
mutating Microsoft Learn 
az storage fs delete --name <filesystem> --account-name <storage-account> --auth-mode login
az storage fsremoveStorage
destructive Microsoft Learn

Storage Fs operations

direct 
az storage fs create --name <filesystem> --account-name <storage-account>
az storage fsprovisionStorage
mutating Microsoft Learn 
az storage fs list --account-name <storage-account>
az storage fsdiscoverStorage
read-only Microsoft Learn 
az storage fs directory create --file-system <filesystem> --name <directory> --account-name <storage-account>
az storage fs directoryprovisionStorage
mutating Microsoft Learn 
az storage fs file list --file-system <filesystem> --path <directory> --account-name <storage-account>
az storage fs filediscoverStorage
read-only Microsoft Learn 
az storage fs access show --file-system <filesystem> --path <path> --account-name <storage-account>
az storage fs accessdiscoverStorage
read-only Microsoft Learn 
az storage fs access set --file-system <filesystem> --path <path> --permissions <permissions> --account-name <storage-account>
az storage fs accesssecureStorage
security-impacting Microsoft Learn

Storage Account operations

direct 
az storage account list --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage account show --name <storage-account> --resource-group <resource-group>
az storage accountdiscoverStorage
read-only Microsoft Learn 
az storage account create --name <storage-account> --resource-group <resource-group> --location <region> --sku Standard_LRS
az storage accountprovisionStorage
cost-impacting Microsoft Learn 
az storage account update --name <storage-account> --resource-group <resource-group> --https-only true
az storage accountconfigureStorage
mutating Microsoft Learn 
az storage account blob-service-properties show --account-name <storage-account>
az storage account blob-service-propertiesdiscoverStorage
read-only Microsoft Learn 
az storage account network-rule list --account-name <storage-account> --resource-group <resource-group>
az storage account network-rulediscoverStorage
read-only Microsoft Learn 
az storage account network-rule add --account-name <storage-account> --resource-group <resource-group> --ip-address <ip-address>
az storage account network-rulesecureStorage
security-impacting Microsoft Learn 
az storage account keys list --account-name <storage-account> --resource-group <resource-group>
az storage account keysdiscoverStorage
security-impacting Microsoft Learn

Architecture context

A Data Lake storage account is the storage control boundary that hosts ADLS Gen2 file systems, paths, ACLs, network rules, redundancy, lifecycle management, and diagnostic settings. I treat it as a platform component, not just a bucket for files. The account configuration decides whether analytics engines can use hierarchical namespace, whether private access is enforced, which identities can list or write paths, and how data survives regional or operational failures. Naming, replication, firewall rules, encryption, soft delete, and logging should be decided before workloads start landing data. Changing those choices later can be disruptive because pipelines, mounts, catalogs, and access reviews often depend on the storage account’s endpoints and security model.

Security
Check public access, shared keys, SAS, RBAC, ACLs, private endpoints, and encryption.
Cost
Watch redundancy, access tier, transactions, lifecycle retention, snapshots, and egress.
Reliability
Choose replication, soft delete, versioning, and backup behavior based on recovery needs.
Performance
Account limits, partitioning, file size, access tier, and client pattern matter for throughput.
Operations
Storage needs clear ownership, lifecycle automation, monitoring, and safe deletion controls.

Common mistakes

  • Treating Data Lake storage account as an isolated setting instead of checking the surrounding identity, network, data protection, and cost context.
  • Running mutating or destructive CLI commands without confirming subscription, resource group, and target resource names.
  • Treating Data Lake storage account as just a label instead of checking the Azure scope, owner, and resource that it affects.
  • Running a mutating or destructive CLI command before confirming the active subscription, resource group, and target name.