Lab: Storage account and Azure Files configuration

Outcome

Create a constrained general-purpose v2 storage account, inspect its endpoint and immutable location choice, then create and alter a classic Azure file share while distinguishing its SMB/NFS protocol choice from the newer Microsoft.FileShares resource provider.

Before you begin

Use a disposable resource group and an account name made of lowercase letters and numbers that is globally unique. Choose the region deliberately: a storage account’s region cannot be changed after creation. For this lab, use the classic Azure Files share in a storage account; the separate Microsoft.FileShares provider currently supports NFS, whereas SMB shares belong in a storage account.

Do: create and inspect an account

1. List locations available to the subscription, select an approved training region, and create a standard general-purpose v2 account with a compatible SKU, TLS 1.2 minimum, and public Blob access disabled:

   az group create --name rg-azlearn-storage-config --location <region>
   az storage account create --name <uniqueaccountname> --resource-group rg-azlearn-storage-config \
     --location <region> --kind StorageV2 --sku Standard_LRS \
     --min-tls-version TLS1_2 --allow-blob-public-access false

2. In the portal or CLI, inspect kind, sku, location, primary endpoints, and the resource ID. Explain that the account name and service endpoint form each data-service URL.

3. Add a temporary tag and list the account again. Then compare the requested kind/SKU with a premium file-share or premium block-blob requirement before creating anything: performance, kind, and redundancy must be selected as a compatible combination.

Do: create and modify an Azure Files share

1. Create a classic Azure Files share in the account. Choose SMB for a Windows/client-share scenario or NFS for a supported Linux/VNet scenario, set a small training quota, and record the selected protocol and quota.
2. Mount from a supported client or use Azure Storage Explorer to create team/readme.txt; record the share properties and successful read/write. Use identity-based access if following the dedicated Azure Files identity lab; do not record a storage account key.
3. Change the quota or performance property through the supported portal/CLI flow, then confirm the new value. Do not assume that a quota is a retention policy or that NFS and SMB share the same identity, network, and client prerequisites.

Verify

Capture the create request, account ID/location/kind/SKU, primary endpoints, public-Blob setting, share protocol, quota, property change, and successful file operation. You should now understand: a storage account supplies the namespace and endpoints; account choices constrain later services; an Azure Files share is a protocol-specific file service with its own capacity and client prerequisites.

Break and fix

1. Attempt an account name that violates naming rules or is already taken. Diagnose the name error, choose a compliant unique name, and retry without changing unrelated settings.
2. Try to use a share with the wrong protocol or unsupported client/network path. Diagnose protocol, client OS, identity, DNS, and network prerequisites before changing permissions or using an account key.
3. Set a share property incorrectly in the disposable account. Inspect the current state, set the intended value, and verify it; do not delete a share to correct a mutable property.

Scenario practice

1. Configure: A web app needs blobs and queues in a low-cost training account, while another workload needs a premium SMB share. Select the account/share types, performance, and compatible redundancy.
2. Diagnose: A script points to the wrong Blob endpoint after an account rename was proposed. What facts show why a new account/migration is needed instead of a rename?
3. Distinguish: Contrast a storage account with a file share, SMB with NFS, and a capacity quota with backup retention.

Clean up

Unmount the test share, delete test files and the share, then delete the disposable resource group. Deleting a storage account deletes its data; verify no shared resource or retained training data remains first.

Sources and re-audit

• Create an Azure storage account, checked 2026-08-22.
• Storage account overview, checked 2026-08-22.
• Create a classic file share, checked 2026-08-22.
• Modify an Azure file share, checked 2026-08-22.

Re-audit when SKU/type support, Azure Files provider behavior, client prerequisites, or account endpoint rules change.

Related

storage-account · azure-files · storage-performance · redundancy-lrs-zrs-grs · All labs