Lab 07 — Secure Storage Access and Data Movement
azure administrator series
CLI + PowerShell + Portal + AzCopy + Storage Explorer • 150–210 minutes
ZIP SHA-256: d0b6f7c793360c037149d064cc597ed4c5a92dd618fe10e0e7f25e5c27fc9299
Upload a small synthetic dataset, compare authorization methods, and recover two independent access failures without broadening access. The final acceptance condition is the original file hash and intended configuration—not merely a successful command.
Learning objectives and environment
The workshop addresses storage firewalls and virtual networks, SAS, stored access policies, access keys, Files identity concepts, blob containers/file shares, and data movement with AzCopy and Storage Explorer. It covers selected objectives, not the entire storage domain or a guarantee of exam readiness. See the AZ-104 study guide.
Use the existing Visual Studio Enterprise subscription in West Europe. The foundation is a new resource group, one GPv2 Standard_LRS account, two private blob containers (incoming and exports), and a Transaction Optimized pay-as-you-go Files share with a 1 GiB quota. No compute is deployed.
An empty VNet uses 10.107.0.0/24; its training subnet uses 10.107.0.0/26, disables default outbound access, and enables Microsoft.Storage. Its rule is inspected, but every data request in this lab originates from the local workstation. This is not a live service-endpoint workload test.
The storage account requires HTTPS/TLS 1.2, disables anonymous blob access, and uses selected networks with default deny and no trusted-service bypass. Only the current recorded workstation IPv4 and training subnet are allowed. Shared Key remains enabled solely for this disposable account's explicitly selected key and service-SAS exercises.
Allow about 20 minutes for preparation, 30 for foundation/checkpoints, 35 for transfers, 20 for SAS, 35 for the two faults/recoveries, 15 for rotation, and 25 for evidence/cleanup. Propagation or sign-in can extend the total toward 210 minutes. Stop exercises at five hours and clean up before six.
Prepare tools and private runtime
Open a PowerShell 7.5+ console in the extracted workshop directory. Use a fresh runtime folder outside it. The example uses a folder beneath local application data; its initializer refuses to replace an existing folder or ACL.
$runtime = Join-Path $env:LOCALAPPDATA ('AzureWorkshopz-Lab07-' + [guid]::NewGuid().ToString('N'))
./Initialize-Lab07StateDirectory.ps1 -Path $runtime -Execute
$state = Join-Path $runtime 'state-private.json'
./Prepare-Lab07Tools.ps1 -PrivateDirectory $runtime -ExecuteThe tool script verifies Microsoft Authenticode signatures before execution and records executable paths/versions privately. Do not accept an unexpected publisher, unofficial download, or installation that requests broader access. Storage Explorer requires your own interactive Microsoft Entra sign-in; do not share credentials with the script.
Sign in to Azure CLI and Az PowerShell using the same authorized user, tenant, and subscription. Complete MFA yourself. Select the intended subscription in both clients, then run:
./Start-Az104Lab07.ps1 -StatePath $state -Stage PreflightInspect the private policy, lock, deny-assignment, permissions, pricing, and current-cost report. Preflight does not register providers, upgrade modules, grant permissions, or exempt policy. A denied requirement is a stop, not a reason to weaken governance.
Confirm the workstation uses a stable public IPv4. VPN/proxy changes, multiple outbound NAT addresses, or a changing connection make a single-IP firewall experiment ambiguous. Stop when the recorded IP changes. Never compensate by allowing all networks or a broad address range.
The pricing estimate is a conservative six-hour retail envelope, not your Visual Studio bill. Keep active consumption below EUR15 and EUR5 reserved for cleanup. Recheck actual costs after the session because billing data can lag.
Preview and deploy the foundation
Preparation creates only the uniquely named, tagged empty group, validates the template, and saves the what-if privately.
./Start-Az104Lab07.ps1 -StatePath $state -Stage Foundation -PrepareOnly -ExecuteReview the intended creates and exact scope. Expect no VM, private endpoint, public IP, or existing-resource modification. The template uses Incremental mode. Verify the storage security settings, subnet address, and three role assignments:
Storage Blob Data Contributor on incoming.
Storage Blob Data Contributor on exports.
Storage Blob Delegator on the account, enabling the delegation-key operation.
The data roles are assigned to the current training operator, not a new identity. Do not add subscription-wide storage roles. Existing operator management permissions are prerequisites and are not changed by the lab.
After review:
./Start-Az104Lab07.ps1 -StatePath $state -Stage Foundation -ReviewedWhatIf -ExecuteThe manifest records exact resource and assignment IDs and ownership tags. Never use name prefixes as proof of ownership. Do not replay foundation over a completed run.
In Portal, inspect the group, storage configuration, Networking, each container's access level/IAM, subnet service endpoint, and file share. Screenshots must hide subscription/tenant/resource IDs, account identifiers, email, and source IP. Do not open key values or generate a SAS in the Portal for a screenshot.
Upload and download with AzCopy and Azure Files
./Start-Az104Lab07.ps1 -StatePath $state -Stage Data -ExecuteThe stage generates marker.txt and a deterministic 256 KiB sample.bin, records lengths/hashes, and enforces a 5 MiB maximum. Do not substitute customer data.
AzCopy uses the existing Azure CLI Microsoft Entra session through AZCOPY_AUTO_LOGIN_TYPE=AZCLI. The account URL is not a signed URL; no SAS or key is passed in command arguments. Private job diagnostics remain outside the public package. The script uploads to incoming/azcopy, performs a fresh OAuth read, downloads both files, and compares SHA-256 hashes.
For Azure Files, PowerShell creates onboarding, uploads the same marker, downloads it, and compares its hash. These operations use HTTPS REST with an in-memory lab account key. They do not establish identity-based SMB access or prove TCP 445 connectivity.
The difference matters: both clients move data, but authorization, protocol, and required permissions are distinct. Record the observed method with each result.
Complete the separate Storage Explorer transfer
Use the installed Storage Explorer application. Select Microsoft Entra account sign-in rather than an account-key/SAS connection. Complete authentication yourself, select the intended subscription, locate the recorded account, and open exports.
Upload the runtime's data/explorer-input/explorer-marker.txt into the container root. Verify a completed transfer in Activities. Download the same blob into data/explorer-download without altering its filename. Capture the transfer and blob listing with any sensitive identifiers redacted deterministically.
./Register-Lab07StorageExplorerCheckpoint.ps1 -StatePath $state `
-ScreenshotPath '<private genuine transfer screenshot path>' `
-DownloadedFile (Join-Path $runtime 'data/explorer-download/explorer-marker.txt') -ExecuteThe registration checks the local file and a fresh remote blob hash. It does not authenticate the UI on your behalf; the live reviewer must observe Microsoft Entra sign-in and the genuine completed transfer. An unrelated screenshot or an AzCopy transfer is not a substitute.
Compare the access methods
Run the SAS stage shortly before the fault exercises. Its policy window is intentionally short; do not pause for an hour halfway through the fault sequence.
./Start-Az104Lab07.ps1 -StatePath $state -Stage Sas -Execute
./Test-Az104Lab07.ps1 -StatePath $state -Phase Baseline -ExecuteMethod | Scope in this workshop | Credential and control |
Microsoft Entra OAuth | Recorded container scopes | User token and blob data roles |
User-delegation SAS | One blob, read only | Delegation key from Microsoft Entra; short expiry |
Service SAS | One container, read/list | Account-key signature plus the recorded stored policy |
Shared Key | Disposable lab account | Broad credential; restricted by the firewall |
Account SAS | Explanation only | No token generated |
Stored access policies can govern service SAS, but not user-delegation SAS or account SAS. A SAS does not override the storage firewall. Microsoft recommends user-delegation SAS when possible; see the SAS overview.
The service SAS is preserved only as DPAPI ciphertext for the next script process. Its value and full URL are never evidence. The delegation SAS remains in memory. Do not paste either into shell commands, browser history, a console transcript, or a screenshot.
Diagnose the SAS policy fault
./Set-Az104Lab07Fault.ps1 -StatePath $state -FaultKind SasPolicy -Execute
./Test-Az104Lab07.ps1 -StatePath $state -Phase Fault -FaultKind SasPolicy -ExecuteThe fault removes only training-read, the exact lab-owned stored policy. Examine the observed response from the *same* service SAS. A generic 403 alone is insufficient: prove that the policy is absent, OAuth still reads all original blobs, the account network configuration and role assignments match, and the original data/ETag are unchanged.
Allow bounded propagation retries. Capture the actual structured Storage error returned; do not relabel it as an assumed error. A token that simply expired does not prove policy-controlled revocation.
Restore the exact policy identifier, permissions, start, and expiry through PowerShell:
./Restore-Az104Lab07.ps1 -StatePath $state -FaultKind SasPolicy -Execute
./Restore-Az104Lab07.ps1 -StatePath $state -FaultKind SasPolicy -Execute
./Test-Az104Lab07.ps1 -StatePath $state -Phase Recovery -FaultKind SasPolicy -ExecuteThe same service SAS must read the original hash again. The repeat is an inspection without duplicate policy creation. Restoring the same identifier can reactivate an associated SAS; deleting a policy is not a promise of irreversible revocation. For the server-side behavior and propagation caveat, see stored access policy guidance.
Diagnose the separate firewall fault
Proceed only after SAS recovery passed. The network fault removes just the recorded workstation IP rule; the selected subnet rule, default deny, no bypass, roles, policy, and data remain in place.
./Set-Az104Lab07Fault.ps1 -StatePath $state -FaultKind Firewall -Execute
./Test-Az104Lab07.ps1 -StatePath $state -Phase Fault -FaultKind Firewall -ExecuteObserve fresh OAuth requests and the same service SAS fail. Check management-plane configuration independently. Management reads succeeding while data reads fail is not contradictory: these are different endpoints and controls.
Do not grant another role or generate a new token to fix a removed IP rule. Do not infer the cause solely from a 403 or a still-open Explorer tab. Restore only the recorded IP rule with PowerShell:
./Restore-Az104Lab07.ps1 -StatePath $state -FaultKind Firewall -Execute
./Restore-Az104Lab07.ps1 -StatePath $state -FaultKind Firewall -Execute
./Test-Az104Lab07.ps1 -StatePath $state -Phase Recovery -FaultKind Firewall -ExecuteRequire fresh reads, original hashes, unchanged ETag, and the original configuration fingerprint. If the workstation's source IP changed, stop rather than silently replacing the rule.
Rotate one lab access key
./Start-Az104Lab07.ps1 -StatePath $state -Stage KeyRotation -ExecuteThe demonstration request client first proves both keys work, uses key2 before regenerating key1, and then checks old key1, replacement key1, key2, and OAuth. The old key must fail while the other three return the original hash. Key values never appear in the report.
The exercise follows the two-key continuity principle in Microsoft's access-key rotation guidance. Service SAS signed by the rotated key can also be affected; finish the stored-policy exercise before rotation. This is not a production migration procedure or a test of every dependent client.
Capture only key names/creation metadata with values hidden. Do not click Show keys. A repeat of the stage must not regenerate a second time after its successful check is recorded.
If the process stops during rotation, do not retry regeneration blindly. Run reconciliation, which compares observed outcomes using the protected old key and current credentials. An uncertain outcome stops for review; it is not converted into a success.
Review Files identity based SMB access
This section is guided only. The preparation workstation is neither domain-joined nor Microsoft Entra-joined, and no directory integration is enabled in this lab.
For a real SMB design, choose a supported identity source, validate its client/account prerequisites, assign appropriate share-level roles, and apply file/directory ACLs. Then verify DNS, the actual SMB path, and network reachability including TCP 445. Share authorization and file/directory permissions are separate layers. See Azure Files identity prerequisites.
Do not claim that the REST upload proves a domain identity mount, that an account key is an identity source, or that the 1 GiB quota bounds every possible charge. No SMB mount is attempted here.
Export evidence and clean up
./Test-Lab07Safety.ps1 -StatePath $state -Execute
./Export-Lab07Evidence.ps1 -StatePath $state `
-OutputPath (Join-Path $runtime 'sanitized-evidence-before-cleanup.json') -Execute
./Remove-Az104Lab07.ps1 -StatePath $state -Execute
./Remove-Az104Lab07.ps1 -StatePath $state -Execute
./Export-Lab07Evidence.ps1 -StatePath $state `
-OutputPath (Join-Path $runtime 'sanitized-evidence-final.json') -ExecuteCleanup first removes the three recorded assignments, then the exact storage account, VNet, deployment record, and empty group. It refuses changed ownership, unexpected objects, and pending operations. It deletes the temporary DPAPI secret files and verifies absence by exact IDs. Keep raw diagnostics private; only review the sanitized export for publication.
If a pending operation blocks cleanup, use Reconcile-Lab07Operation.ps1 -StatePath $state -Execute, review its outcome, then rerun cleanup. Never clear pending state by editing JSON. Interrupted transfers or SAS setup require cleanup and a fresh run rather than uncertain replay.
Label the wrong-context/mismatched-ID/interruption fixtures as simulated. The concurrency check is real local file-lock contention, not two simultaneous Azure deployments. A screenshot checklist is not evidence that a screenshot was captured.
Finish by confirming no active exact lab resources or assignments remain, rechecking costs, and verifying the ZIP and its individual hashes.
Lab 07 storage access challenge
Work from a healthy synthetic-data baseline. Preserve the recorded resource IDs, file hashes, restrictive network configuration, and scoped assignments. Do not change unrelated resources.
Incident one
A previously usable delegated read request no longer returns the marker. The operator's Microsoft Entra read still returns the original hash. Identify the changed control and recover the original request without creating a replacement signed URL, rotating a key, or widening permissions.
Provide fresh request evidence, the relevant configuration difference, proof that other controls/data are unchanged, the recovery action, and a safe repeated recovery.
Incident two
After the first incident is recovered, fresh authenticated data reads stop working through both Microsoft Entra and the delegated request. Management-plane inspection remains available. Restore the intended configuration without enabling all networks, trusted-service bypass, or extra role assignments.
Provide the actual response and changed-control evidence. A generic 403 is not a diagnosis. Prove the original hash after recovery and after a safe repeat.
Completion conditions
Demonstrate the two-key rotation separately, retaining working key2 and OAuth requests while old key1 becomes invalid. Submit sanitized evidence only—no credentials, signed URLs, resource IDs, source IP, or private state. Clean up exact recorded lab objects and verify repeated cleanup.
Open the progressive hints only when needed. The separate solution is not part of this symptom-only challenge.
Knowledge checks
Why can a valid Microsoft Entra token still receive a denied data request?
Which SAS types can use a stored access policy?
Why is Storage Blob Delegator assigned at account scope while the data roles are on containers?
Does restoring a deleted policy with the same identifier guarantee its old SAS stays revoked?
Why use key2 before regenerating key1?
Why is a 403 alone insufficient to diagnose either fault?
Does a key-authorized Files HTTPS REST upload prove identity-based SMB access?
Does the empty subnet's Microsoft.Storage endpoint prove this workstation's requests use that subnet?
The download includes progressive hints, a separate solution, eight knowledge-check answers, the validation report, sanitized evidence, and individual file checksums. Try the challenge before opening the solution.
Comments