Domain 2: Implement and Manage Storage (15-20%)
What this domain actually covers
Everything about Azure Storage accounts and Azure Files as a managed service.
Storage account fundamentals. Account types (StorageV2 general purpose, Premium BlockBlob, Premium FileStorage, Premium PageBlob), performance tiers (Standard vs Premium), access tiers for blobs (Hot, Cool, Cold, Archive), redundancy options (LRS, ZRS, GRS, GZRS + RA variants).
Blob storage. Containers, access levels (Private, Blob, Container), block/append/page blob types, blob versioning, soft delete for blobs and containers, immutable storage (time-based + legal hold), lifecycle management policies, blob inventory.
Azure Files + File Sync. SMB and NFS shares, identity-based auth (on-prem AD DS, Entra Domain Services, Entra Kerberos for Entra-joined clients), snapshots, quotas, Standard vs Premium file shares. File Sync agent, sync groups, cloud endpoints, server endpoints, cloud tiering (volume free space and date policies).
Security + connectivity. SAS variants (account SAS, service SAS, user delegation SAS), account keys and rotation, storage firewall + network rules, service endpoints, private endpoints, disabling shared-key access, customer-managed keys (CMK) via Key Vault, infrastructure encryption, encryption at host for VMs.
Data movement. AzCopy, Storage Explorer, az storage CLI, Data Box family (physical shipping), Storage Migration Service (server-based migration), object replication (async blob copy across accounts).
Storage account limits. 500 TiB soft cap, IOPS/throughput targets, request rate targets.
Questions
Q1
Which redundancy option provides the highest durability by replicating across three availability zones in the primary region AND asynchronously to a paired secondary region?- A. LRS
- B. ZRS
- C. GRS
- D. GZRS
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real redundancy: LRS keeps copies within one datacenter; it does not supply both zone and regional protection.
Why this is not the answer
Real redundancy: ZRS spans primary-region zones but does not add a secondary-region replica.
Why this is not the answer
Real redundancy: GRS adds asynchronous regional replication but does not provide the requested primary-region ZRS design.
✓ Correct choice
Real redundancy: GZRS combines primary-region zone redundancy with asynchronous secondary-region replication.
The reasoning
GZRS is synchronously zone-redundant in the primary region plus asynchronously geo-replicated to the paired secondary. Add "RA-" (RA-GZRS) if you need read access to the secondary. LRS is one datacenter. ZRS is three zones same region. GRS is two regions (single zone each). Durability ladder: LRS 11 nines, ZRS 12 nines, GRS and GZRS both 16 nines (geo-replication is what buys the extra 4 nines).
Q2
You need to store medical imaging files that must be immutable for 7 years for compliance. Correct combination?- A. Blob soft delete with 2555-day retention
- B. Blob versioning with policy
- C. Immutable storage with a time-based retention policy in Locked state
- D. Legal hold with tag "compliance"
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real recovery feature, invalid retention claim: soft delete is reversible protection with a shorter supported window, not seven-year immutable retention.
Why this is not the answer
Real version history: versioning retains earlier versions but does not by itself prohibit deletion for seven years.
✓ Correct choice
Real WORM protection: locked time-based retention prevents shortening or removing the policy during its retention period.
Why this is not the answer
Real immutability control: a legal hold has no fixed expiry and can be cleared by authorized users; it is not the specified locked seven-year timer.
The reasoning
Time-based retention (WORM) in Locked state prevents modification and deletion until the retention period expires, meeting SEC 17a-4(f), FINRA, and CFTC compliance. Soft delete allows recovery but does not prevent deletion. Legal hold works for ad-hoc holds (litigation) but is not schedule-based. Locked state is one-way.
Q3
A user needs to upload files to a specific container for 8 hours from a specific IP. Least-privileged SAS?- A. Account SAS
- B. Service SAS scoped to the container with IP filter and expiry
- C. User delegation SAS at storage account scope
- D. Static account key sent by email
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real SAS type: account SAS can cover broader services/resources; a container-scoped service SAS is narrower among these choices.
✓ Correct choice
Real limited token: container scope, upload permissions, expiry and IP restriction match the stated access constraints.
Why this is not the answer
Real SAS type, invalid scope claim: user delegation SAS authorizes Blob resources; storage-account-wide scope is not its supported scope.
Why this is not the answer
Real credential, unsafe scope: an account key grants broad access and cannot itself encode this IP/time/container restriction.
The reasoning
Service SAS is scoped to a single service (blob) and can target one container. IP filter and expiry are supported. Account SAS spans multiple services and is broader than needed. User delegation SAS is preferred when available: its issuer needs Entra permissions, but its recipient does not. Option C incorrectly describes storage-account scope; a container-scoped user delegation SAS would also meet this requirement. Never share account keys via email.
Q4 (multi-answer, pick two)
Which are TRUE about Azure Files identity-based authentication (SMB shares)?- A. On-prem AD DS auth requires the storage account to be joined to the domain
- B. Entra Kerberos supports hybrid users only when they are synced from AD DS
- C. Entra Domain Services and on-prem AD DS auth can both be enabled on the same storage account
- D. Entra Kerberos is the recommended path for Entra-joined clients
- E. NFS shares use identity-based auth by default
Show answer & explain every option
Listed key (under review): A, D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real AD DS integration: classic domain authentication requires the storage account's AD identity/domain configuration.
Alternative · under review
Outdated exclusivity claim: Entra Kerberos supports documented hybrid-user scenarios and evolving cloud-only support; verify current eligibility.
Alternative · under review
False simultaneous configuration: a storage account uses one selected identity source for this SMB authentication configuration.
Listed key · under review
Real integration: Entra Kerberos is useful for supported Entra-joined client/user combinations; check current prerequisites.
Alternative · under review
False protocol assumption: NFS uses its supported network/POSIX authorization model, not SMB identity authentication by default.
Original explanation · under review
A: AzFilesHybrid PowerShell module creates a computer object for the storage account in AD DS. D: Entra Kerberos is Microsoft's forward path for Entra-joined clients accessing SMB Files. B is false: Entra Kerberos supports both cloud-only and hybrid users. C is false: only one identity source at a time per storage account. E is false: NFSv4.1 uses network + export policy for access, no identity attached.
Field anchor: you have used Azure Files. Exam trap: SMB Files supports three identity paths (AD DS, Entra DS, Entra Kerberos); only one can be active per account, and the exam sometimes hides this in a scenario where a customer wants to combine them.
Q5
For classic Azure NFSv4.1 file shares deployed inside a storage account, which account type is required?- A. General purpose v2 (StorageV2)
- B. Premium FileStorage
- C. BlobStorage
- D. General purpose v1
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real general-purpose account: it does not host the classic premium NFSv4.1 share required by this specifically scoped question.
✓ Correct choice
Real premium account kind: FileStorage supports classic Azure Files NFSv4.1 shares.
Why this is not the answer
Real legacy account kind: BlobStorage is for blobs, not Azure Files NFS shares.
Why this is not the answer
Real legacy account kind: general purpose v1 does not supply the required premium NFS share capability.
The reasoning
NFSv4.1 file shares require a Premium FileStorage account with provisioned shares. Standard general purpose v2 supports NFSv3 for BLOB (a separate feature) but not NFS Files. GPv1 is legacy and lacks most modern features.
Q6
Azure File Sync tiering policy is set toVolume Free Space = 20%. What does this mean?
- A. 20% of the sync group volume must be free before tiering begins
- B. Tiering runs continuously to keep at least 20% of the local server volume free
- C. 20% of files are always kept locally
- D. Tiering only runs when disk usage exceeds 80%
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Incorrect direction: tiering tries to preserve the free-space target; it does not wait for free space to exceed that target.
✓ Correct choice
Real policy: cloud tiering removes local file content as needed to maintain the free-space target, subject to operational constraints.
Why this is not the answer
False interpretation: this is a volume-space target, not a fixed percentage of files that must stay cached.
Why this is not the answer
Incomplete trigger claim: the volume threshold matters, but date policies and other tiering behavior mean this is not the only possible trigger.
The reasoning
Volume free space is a target: File Sync tiers cold files off the server to Azure until at least 20% of the local volume is free. Free space contributions across all sync groups on that volume count together. Combine with a date policy (tier files not accessed in N days) for finer control. Full files remain queryable via reparse points.
Field anchor: you have deployed File Sync. Exam trap: cloud tiering is enabled and configured on each server endpoint, with policies controlling how local space is reclaimed.
Q7
What is the maximum size of a single block blob in a modern general purpose v2 storage account?- A. 5 TB
- B. 190.7 TiB (with 4000 MiB blocks)
- C. 500 GB
- D. 4.75 TB
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Numeric distractor: 5 TB is not the modern maximum block-blob size under the specified block limits.
✓ Correct choice
Documented calculation: 50,000 blocks of up to 4,000 MiB yield about 190.7 TiB.
Why this is not the answer
Numeric distractor: 500 GB is not the block-blob maximum; it names no alternative blob service.
Why this is not the answer
Older-limit confusion: older API block-size limits produced much smaller maxima; this is not the specified modern limit.
The reasoning
Since 2020 the block blob maximum is 190.7 TiB (50,000 blocks x up to 4000 MiB per block). Older docs cite 4.75 TB, that number is out of date. Page blob max is 8 TiB. Azure Files capacity limits depend on the media tier and provisioning model; they are separate from blob limits.
Q8
You must migrate 40 TB of on-prem file data to Azure Files over a 100 Mbps link. Fastest supported method?- A. AzCopy over the internet
- B. Azure Data Box (physical device shipped to Microsoft)
- C. Storage Explorer drag-and-drop
- D.
az storage file upload-batch
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real transfer tool: AzCopy can upload the data, but 40 TB over 100 Mbps takes many days before overhead.
✓ Correct choice
Real offline-transfer service: Data Box ships bulk data physically, avoiding the constrained WAN upload; delivery logistics still matter.
Why this is not the answer
Real management tool: Storage Explorer still transfers over the available network and does not remove the bandwidth bottleneck.
Why this is not the answer
Real CLI command: batch uploading files still uses the same constrained network connection.
The reasoning
Data Box provides offline transfer that avoids the 100-Mbps upload bottleneck (40 decimal TB alone requires roughly 37 days at line rate). Current device choices include 120-TB and 525-TB usable capacities where available. Data Box Heavy is retired; orderability and shipping time depend on region.
Q9
Which combination lets you authorize access to blob data using Entra ID?- A. Enable public blob access on the container
- B. Grant a data-plane role (for example Storage Blob Data Contributor) on the storage account and connect with an Entra-aware client
- C. Rotate account keys
- D. Enable SAS-only access
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real access setting: anonymous public access bypasses identity-based authorization rather than using Entra ID.
✓ Correct choice
Real authorization: a data-plane role plus an Entra token enables identity-based blob access within the assigned scope.
Why this is not the answer
Real credential maintenance: rotating shared keys does not grant a principal Entra data permissions.
Why this is not the answer
Invalid account-mode shorthand: SAS authorization is distinct from granting Entra data-plane RBAC; there is no required SAS-only switch.
The reasoning
Data-plane RBAC (Storage Blob Data Reader/Contributor/Owner) plus a client that requests an Entra token (AzCopy after azcopy login, PowerShell Az.Storage with -UseConnectedAccount, .NET SDK with DefaultAzureCredential) allows Entra-authorized reads. Public access is anonymous. Shared Key authorization uses account keys; user delegation SAS is secured using Microsoft Entra credentials.
Q10
Lifecycle management can move blobs between tiers based on rules. Which is a valid rule action?- A. Move to Cool after 30 days without modification
- B. Delete 365 days after last access (requires last-access tracking enabled)
- C. Move to Archive after 180 days without modification
- D. All of the above
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real lifecycle action: eligible blobs can transition to Cool based on days since last modification. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real lifecycle action: deletion can use last-access conditions when the required access-time tracking is configured. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real lifecycle action: eligible blobs can transition to Archive using modification age; account and blob compatibility still apply. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: all three are supported rule patterns; lifecycle processing is asynchronous rather than an exact-time scheduler.
The reasoning
Lifecycle rules support tierToCool, tierToCold, tierToArchive, and delete actions, scoped by blob type (blockBlob, appendBlob), name prefix, blob index tag match, and either daysAfterModificationGreaterThan or daysAfterLastAccessTimeGreaterThan. Last-access tracking must be enabled separately and adds a small cost. Tier transitions apply to block blobs; append blobs support deletion, not tiering. Cold tier was added in 2023.
Q11 (scenario)
Users complain of slow read performance from a Standard storage account holding 3 TB of hot blobs served to a US web app. The same objects are downloaded thousands of times per day. Recommendation?- A. Move to Premium BlockBlobStorage
- B. Enable read-access geo-redundant (RA-GRS)
- C. Enable Azure CDN with the storage account as origin
- D. All of the above are reasonable depending on access pattern
Show answer & explain every option
Listed key (under review): D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Alternative · under review
Real premium storage: it can improve eligible transaction-heavy workloads but adds cost and does not inherently cache repeated downloads near users.
Alternative · under review
Real secondary read access: applications must explicitly use the secondary endpoint; replication alone does not accelerate primary reads.
Alternative · under review
Real edge caching: a supported CDN/Front Door configuration can cache repeated objects near clients and reduce origin traffic.
Listed key · under review
Overbroad combined claim: each option needs workload evidence; the described repeat-read pattern most directly motivates caching.
Original explanation · under review
(single-best answer if forced: C, because the pattern described is high-repeat reads of the same objects)
CDN caches at the edge, best for high-repeat downloads (media, static site). Premium BlockBlobStorage helps for high-transaction workloads with sub-millisecond latency needs. RA-GRS helps geo-distributed reads by serving from the secondary region. The exam prefers the answer that matches the workload most directly; here the "same objects, thousands of times" hint points to CDN.
Q12
You enable soft delete on a container and a blob. A user then deletes a blob. With blob versioning disabled, which two methods recover it within the retention window?- A. Undelete blob via portal or REST
Undelete Blob(PUT ...?comp=undelete) - B. Restore from geo-secondary
- C. Enable versioning; then "Undelete" the version
- D.
az storage blob undelete
Show answer & explain every option
Correct: A, D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real recovery operation: Undelete Blob restores eligible soft-deleted data during retention when versioning is disabled.
Why this is not the answer
Real disaster-recovery replica: geo-replication is not a per-blob undelete mechanism and can replicate deletion.
Why this is not the answer
Real feature, not retroactive: enabling versioning after deletion does not manufacture a pre-deletion version.
✓ Correct choice
Real CLI operation: az storage blob undelete invokes the supported soft-delete recovery path.
The reasoning
Soft delete keeps deleted blobs (or overwritten versions) in a soft-deleted state for the retention period (1-365 days). Undelete brings it back. Blob versioning (a separate feature) keeps a version on every write, which is a stronger protection when enabled together. Container soft delete is yet another separate setting.
Q13
Which of the following is TRUE for a single standard general purpose v2 storage account?- A. Max 5 PiB total capacity (soft target, raised from 500 TiB in 2023)
- B. Default request-rate target is 20,000 or 40,000 requests/sec depending on region
- C. Both A and B
- D. Neither, storage accounts have no soft limits
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real capacity target: 5 PiB is a documented standard-account capacity target; the other listed throughput statement also matters. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real request-rate targets: documented defaults vary by region, so this statement is also true. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: both capacity and regional request-rate targets apply; limits can depend on account configuration and approved increases.
Why this is not the answer
False unlimited claim: storage accounts have documented scalability targets and limits.
The reasoning
A standard GPv2 account has a default 5-PiB capacity limit. Request-rate targets are regional: 40,000 requests/sec in the listed regions and 20,000 elsewhere. Capacity and throughput targets are distinct; consult the current table and request increases where supported.
Q14
Which encryption option requires you to manage the key in Key Vault?- A. Microsoft-managed keys (default SSE)
- B. Customer-managed keys (CMK)
- C. Customer-provided keys (CPK, per-request header)
- D. Both B and C
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real default encryption: Microsoft manages these keys, so the customer does not manage a Key Vault key.
✓ Correct choice
Real encryption option: CMK uses a customer-controlled key in Key Vault or Managed HSM to protect the account's encryption key.
Why this is not the answer
Real per-request option: CPK sends an AES key with supported requests; it is not the account CMK/Key Vault integration.
Why this is not the answer
Incorrect combination: CPK is real but does not require the same Key Vault management model as account CMK.
The reasoning
Microsoft-managed keys are automatic, no config. CMK uses a Key Vault or Managed HSM key that you rotate; you also enable a system or user-assigned identity on the storage account to authorize the wrap/unwrap operation. CPK is per-request and the client supplies the key with each blob operation, no vault involved.
Q15 (multi-answer, pick two)
Select TWO true statements about the Archive tier.- A. Data in Archive is offline and takes hours to rehydrate to Hot/Cool
- B. Rehydration priority "High" targets under 1 hour for objects under 10 GB
- C. You can read directly from Archive without rehydration
- D. Minimum storage duration is 180 days; early deletion incurs a fee
Show answer & explain every option
Listed key (under review): A, D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real offline tier: archived blobs must rehydrate before online reads; completion time depends on priority and workload.
Alternative · under review
Real priority option: high-priority rehydration can target faster restoration of small blobs, but is not a universal completion guarantee.
Alternative · under review
False direct-read capability: offline Archive contents cannot be read normally before rehydration.
Listed key · under review
Real billing rule: Archive has minimum-duration/early-deletion charges, distinct from a mandatory retention lock.
Original explanation · under review
(B is also technically true; A and D are the safest picks)
Archive is offline: reads require rehydration to Hot or Cool. Standard rehydration up to 15 hours; High priority up to 1 hour for small objects, subject to service limits. Minimum durations: Cool 30 days, Cold 90 days, Archive 180 days. Deleting or moving earlier triggers a prorated early-deletion charge.
Q16
Which private connectivity option gives each storage sub-service (blob, file, table, queue) its own private IP in your VNet?- A. Service endpoint
- B. Private endpoint
- C. VNet integration
- D. ExpressRoute Microsoft peering
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real connectivity feature: a service endpoint identifies the subnet to the public service endpoint; it does not create a private service IP.
✓ Correct choice
Real Private Link resource: a private endpoint places a private IP in the VNet for the selected storage subresource.
Why this is not the answer
Real application-networking concept: VNet integration enables outbound access for supported services, not a storage subresource's private IP.
Why this is not the answer
Real ExpressRoute peering: Microsoft peering reaches supported public services; it does not create per-subresource private endpoints.
The reasoning
Private endpoints assign a NIC in your VNet per storage sub-service (one PE for blob, another for file, etc.). Service endpoints keep traffic on the Microsoft backbone but the target keeps its public IP (locked by firewall). Private endpoints are preferred for regulated environments because private DNS resolves the PaaS FQDN to the private IP inside the VNet.
Q17
Account keys provide broad data access to a storage account. Microsoft-recommended pattern for reducing key exposure?- A. Rotate keys every 90 days manually via portal
- B. Configure a key rotation policy and integrate with Key Vault
- C. Disable shared key access entirely and use Entra ID data-plane roles + managed identities
- D. Both B and C
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real rotation procedure: manual rotation reduces credential lifetime but still distributes broad shared secrets and depends on operators.
Why this is not the answer
Real controls with a caveat: rotation reminders and Key Vault integration need an actual rotation workflow; a reminder alone does not rotate keys. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real preferred authorization where supported: disable Shared Key and use Entra/managed identities; check workload compatibility first. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Qualified combination: eliminate shared keys where possible and govern/rotate remaining keys; these controls are complementary, not automatic magic.
The reasoning
Best practice: disable Allow shared key authorization and use Entra auth for humans + managed identities for services. Where keys are still required, rotate on schedule and store in Key Vault (never in code/config).
Q18
Azure File Sync uses which agent on the on-prem server?- A. Azure Arc agent
- B. Azure File Sync agent (StorageSync)
- C. Azure Migrate agent
- D. Log Analytics agent
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real hybrid-management agent: Azure Arc manages connected machines; it does not perform Azure File Sync replication.
✓ Correct choice
Real synchronization agent: the Azure File Sync agent connects Windows Server endpoints to the Storage Sync Service.
Why this is not the answer
Real migration tooling: Azure Migrate assesses/migrates workloads; it is not the persistent File Sync agent.
Why this is not the answer
Real legacy monitoring agent: Log Analytics collected telemetry, not file synchronization; current monitoring uses Azure Monitor Agent.
The reasoning
The Storage Sync Agent is installed on a supported Windows Server version; check the agent support matrix, including its .NET prerequisites. It registers the server with a Storage Sync Service and joins it to a sync group. Log Analytics may be added for telemetry but is not required.
Q19
A blob has a lifecycle rule that moves it to Cool at 30 days and Archive at 180 days. On day 60 you manually tier it to Archive. What happens?- A. The rule reverts it to Cool
- B. The blob stays in Archive; the day-180 rule is a no-op
- C. The rule pauses until day 180
- D. The blob is auto-restored to Hot
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
False reverse transition: lifecycle tiering does not automatically rehydrate an archived blob back to Cool.
✓ Correct choice
True behavior: an already archived blob stays archived unless explicitly rehydrated; the later archive action has nothing further to do.
Why this is not the answer
False scheduler model: manual tiering does not pause all lifecycle processing until a specified birthday.
Why this is not the answer
Real tier, false automation: Hot access requires rehydration; this rule does not perform it automatically.
The reasoning
Lifecycle management cannot rehydrate an archived blob. It therefore stays in Archive; a later tierToArchive action does not change an already archived blob. Policy execution is asynchronous, not a guaranteed daily completion deadline.
Q20
Storage account key rotation reminder policy accepts what range of days?- A. Any value 1-365 days
- B. Any value 1-720 days
- C. Only 90 or 180 days
- D. Rotation reminders are not supported
Show answer & explain every option
Listed key (under review): B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Alternative · under review
Unverified numeric range: the documented reminder feature does not establish this claimed maximum; do not memorize it as a limit.
Listed key · under review
Unverified numeric range: the old answer key claims 720, but the cited documentation does not establish that bound.
Alternative · under review
Unsupported fixed-choice claim: documentation describes a configurable reminder interval, not only these two values.
Alternative · under review
False feature claim: key rotation reminders are supported, although a reminder does not automatically rotate the access key.
Original explanation · under review
Key rotation policy allows 1 to 720 days for the reminder threshold. Full auto-rotation (as opposed to reminder) is available when the account is integrated with Key Vault for the key wrap.
Q21 (scenario)
A backup tool must write to a container 24x7 unattended from an Azure VM. Best identity?- A. Storage account key in the VM's env vars
- B. Service SAS with 10-year expiry
- C. System-assigned managed identity + Storage Blob Data Contributor role on the storage account
- D. User account with MFA in the connection string
Show answer & explain every option
Correct: C
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real credential, high exposure: account keys in environment variables are long-lived broad secrets that need secure distribution/rotation.
Why this is not the answer
Real token, excessive lifetime: a ten-year SAS is a persistent bearer credential rather than a secretless workload identity.
✓ Correct choice
Real workload identity: managed identity plus a scoped blob data role avoids storing an account secret on the VM.
Why this is not the answer
Invalid connection-string model: an interactive user MFA challenge is not a secretless unattended storage connection credential.
The reasoning
Managed identity plus RBAC is the modern secret-free path. No secret to rotate, no leak surface, auditable through Entra sign-in logs. Long-lived SAS is discouraged. Keys in env vars are worse. MFA cannot be used unattended.
Q22 (multi-answer)
Which are TRUE about Standard vs Premium file shares?- A. Standard uses HDD-backed capacity; Premium uses SSD-backed
- B. Premium file shares live in a FileStorage account
- C. Standard file shares support both SMB and NFS
- D. Premium supports snapshots; Standard does not
- E. Max IOPS and throughput on Premium scale with provisioned size
Show answer & explain every option
Listed key (under review): A, B, E
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real classic storage distinction: standard HDD and premium SSD models have different performance/cost characteristics; newer provisioning models need separate review.
Listed key · under review
Real classic account model: premium classic shares use FileStorage accounts; verify the current provisioned model's resource structure.
Alternative · under review
False classic protocol claim: standard HDD Azure Files shares do not supply the premium NFSv4.1 capability.
Alternative · under review
False snapshot distinction: both supported standard and premium Azure Files configurations support snapshots.
Listed key · under review
Qualified performance model: provisioned-v1 premium performance scales with size; newer provisioned models allow independent tuning.
Original explanation · under review
C is false: NFS Files requires Premium. D is false: both support snapshots (up to 200 per share). Premium performance scales with provisioned GiB: baseline IOPS = ceil(GiB / 1), baseline throughput = 60 + 0.06 * GiB MiB/s, burst up to 3x for 60 minutes.
Q23
Which tool triggers server-side blob copy (no data transiting your workstation)?- A. AzCopy (with source + destination SAS URLs)
- B. Azure Storage Explorer
- C.
az storage blob copy start - D. All of the above trigger server-side copy under the hood
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real tool: supported blob-to-blob AzCopy operations use service-side transfer, rather than downloading all bytes through the workstation. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real tool: Storage Explorer supports service-side blob copy; local uploads/downloads are different operations. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real CLI command: az storage blob copy start asks the service to copy from the source URL. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination for blob-to-blob copy: all three tools support this service-side path with appropriate source and destination access.
The reasoning
These tools support server-side blob copying; AzCopy uses server-to-server APIs such as Put Block From URL, rather than always the Copy Blob operation. AzCopy has the best parallelism. CLI is scriptable. Storage Explorer is GUI. For very large copies also consider Object Replication policies (async, versioning is needed on both accounts, and change feed on the source).
Q24
Object replication asynchronously copies blobs between accounts. Prerequisites?- A. Blob versioning enabled on both source and destination
- B. Change feed enabled on the source
- C. Both accounts must be in the same region
- D. A and B only
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real prerequisite: object replication relies on versioning on both accounts; source change feed is also required. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real prerequisite: source change feed tracks changes; versioning on both accounts is also required. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
False regional restriction: object replication can operate across supported accounts in different regions.
✓ Correct choice
Valid combination: versioning plus source change feed are required; same-region placement is not required.
The reasoning
Object replication requires versioning on both sides and change feed on source. Accounts can be in different regions and subscriptions (a common DR pattern). Replication is one-way per policy; a destination container cannot accept direct writes while its rule is active. Separate source/destination containers are required for any two-direction design.
Q25
A blob is stored with SSE using Microsoft-managed keys. You then enable customer-managed keys on the account. What happens to existing blobs?- A. They are re-encrypted synchronously with the new key
- B. The customer-managed key protects the account root encryption key; existing blob data remains encrypted and accessible
- C. Existing blobs must be re-uploaded
- D. They become inaccessible until re-keyed
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Incorrect mechanism: changing the key-encryption key does not synchronously rewrite every blob's encrypted payload.
✓ Correct choice
Real envelope encryption: CMK protects the account root encryption key while existing encrypted data remains accessible.
Why this is not the answer
False migration requirement: enabling CMK does not require customers to upload existing blobs again.
Why this is not the answer
False mandatory outage: correctly configured CMK does not inherently make existing blobs inaccessible pending manual re-keying.
The reasoning
Switching to CMK changes the key that protects the account root encryption key. Blob data is not synchronously re-encrypted or re-uploaded. Existing data remains encrypted while the key protection changes.
Q26
Which is TRUE about supported customer-managed unplanned storage account failover?- A. Available on GRS, RA-GRS, GZRS, RA-GZRS accounts
- B. After failover the account becomes LRS in the former secondary region
- C. Unsynchronized writes can be lost; inspect Last Sync Time and do not assume a fixed recovery deadline
- D. All of the above
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real eligible redundancy families: customer-managed unplanned failover applies to supported geo-redundant accounts, subject to feature restrictions. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real post-failover state: the former secondary becomes primary with LRS until geo-redundancy is reconfigured. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real asynchronous-replication risk: writes beyond the secondary's last synchronized point may be lost. This is part of the answer; the combined choice includes the other applicable statements too.
✓ Correct choice
Valid combination: eligibility, post-failover redundancy and potential unsynchronized-data loss all need consideration.
The reasoning
For supported geo-redundant accounts, unplanned failover promotes the secondary and normally leaves LRS in the new primary region. Re-enable geo-redundancy afterward. Planned failover has different prerequisites and preserves geo-redundancy; neither path should be confused with a guaranteed universal RPO/RTO.
Q27
Which is BLOCKED when you setAllow Shared Key access = Disabled on a storage account?
- A. Account key auth
- B. SAS tokens generated from the account key (account SAS and service SAS)
- C. Entra ID data-plane RBAC
- D. A and B only
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real authorization method, blocked for applicable requests: direct Shared Key authentication relies on the disabled account keys. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real token types, blocked for applicable requests: account-key-signed SAS uses Shared Key authorization. This is part of the answer; the combined choice includes the other applicable statements too.
Why this is not the answer
Real authorization method, preserved: Entra-authorized requests use identity permissions rather than shared account keys.
✓ Correct choice
Valid combination: the shared-key paths are blocked; supported user-delegation SAS and Entra authorization remain separate paths.
The reasoning
Disabling shared key auth blocks both the raw account key AND any SAS signed with the account key. User delegation SAS (signed with Entra credentials) and Entra RBAC still work. This is a common hardening lever on the exam.
Q28
Max size of a single Azure Files share using the HDD pay-as-you-go model in a StorageV2 account?- A. 5 TiB default
- B. 100 TiB per share
- C. 500 GiB
- D. 20 TiB
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Historical-size confusion: 5 TiB is not the stated model's current maximum; account/share configuration still matters.
✓ Correct choice
Documented share limit: the specified HDD pay-as-you-go model supports shares up to 100 TiB.
Why this is not the answer
Numeric distractor: 500 GiB is not the specified Azure Files model's maximum share capacity.
Why this is not the answer
Numeric distractor: 20 TiB is not the specified model's maximum; other provisioning models have their own limits.
The reasoning
HDD pay-as-you-go classic shares can grow to 100 TiB. The old large-file-share switch is a legacy setting, not an LRS/ZRS-only rule for all current accounts. Provisioned v2 and SSD models have separate capacity limits.
Docs: Azure Files scalability targets | Enable large file shares
Scenario-Style Questions
Real-exam-style stems. Multi-sentence context, judgment or troubleshooting. Each has doc links so you can drill into the source.
S1
Video-on-demand catalog: 3 TB total, 100 GB new daily, files hot for 30 days then rarely accessed, 7-year retention required. Design?- A. Hot tier only + lifecycle to Archive at day 30
- B. Hot + lifecycle to Cool at day 30 + Archive at day 90; delete at 7 years; enable last-access tracking
- C. Archive only
- D. Cool tier only, no lifecycle
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real tiers, incomplete plan: immediate Archive after day 30 adds offline retrieval and this choice omits the full retention/deletion policy.
✓ Correct choice
Real lifecycle design: staged Hot/Cool/Archive and eventual deletion match the described aging pattern; confirm actual retrieval needs before production use.
Why this is not the answer
Real offline tier, wrong active period: Archive is unsuitable while viewers need prompt access to new videos.
Why this is not the answer
Real online tier, incomplete policy: Cool alone does not automate long-term tier changes or eventual deletion.
The reasoning
Progressive tiering matches the access pattern. Minimum durations: Cool 30d, Cold 90d, Archive 180d. Day-30 to Cool and day-90 to Archive respect these minimums. Delete at 7 years satisfies retention.
S2
2 TB on-prem Windows file server needs cloud extension. Users continue accessing via SMB from HQ. Steps?- A. Install Azure File Sync agent; create Storage Sync Service + sync group + cloud endpoint on Azure Files; register server; create server endpoint on local path; enable cloud tiering
- B. AzCopy migration only
- C. Azure Migrate assessment
- D. Data Box for one-shot copy
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real hybrid design: File Sync maintains an Azure Files cloud endpoint and Windows Server cache while users keep their SMB access path.
Why this is not the answer
Real copy tool: a one-time AzCopy migration does not provide ongoing server/cloud synchronization and tiered caching.
Why this is not the answer
Real assessment service: Azure Migrate assessment inventories suitability; it does not create the required live file cache.
Why this is not the answer
Real offline transfer: Data Box seeds bulk data but is not an ongoing synchronization service.
The reasoning
File Sync keeps the local server as an active endpoint with authoritative copy in Azure. Tiering keeps hot files local; cold files become reparse points. No change to user paths or performance for hot data.
S3
Application intermittently gets HTTP 503 ServerBusy from a storage account under peak load. Root cause?- A. Approaching account IOPS/throughput/request rate targets for the account and region; shard across accounts, move to Premium, or add client backoff
- B. Insufficient client RAM
- C. Firewall rule
- D. Wrong SAS token
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real likely mechanism: server-side throttling can produce ServerBusy; confirm service metrics and logs, then apply backoff/capacity changes.
Why this is not the answer
Real client constraint, wrong evidence: low client RAM alone does not explain a service-generated ServerBusy response.
Why this is not the answer
Real network control: firewall denial typically produces access failures, not this peak-load throttling diagnosis.
Why this is not the answer
Real access token: an invalid SAS normally causes authorization failures, not ServerBusy during load spikes.
The reasoning
503 ServerBusy can indicate throttling. Standard GPv2 request-rate defaults are 20K or 40K requests/sec depending on region; they are not a universal IOPS cap. Solutions: shard across accounts, move to Premium BlockBlob (much higher per-container rate), or add exponential backoff.
Docs: Storage scalability targets | Performance and scalability checklist
S4
Regulator requires 5-year immutable retention. Compliance officer must not be able to shorten. Config?- A. Container-level time-based retention policy in Locked state (WORM) with a day count covering at least the required five calendar years, including leap days
- B. Legal hold with tag
compliance - C. Soft delete 5 years
- D. Blob versioning
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real WORM enforcement: locked time-based retention cannot be shortened; calculate the retention period to cover the required calendar years.
Why this is not the answer
Real legal protection: a legal hold has no scheduled expiry and can be cleared by authorized users; it is not the requested locked duration.
Why this is not the answer
Real recovery feature, invalid duration/use: soft delete is neither five-year immutable retention nor protection from authorized early removal.
Why this is not the answer
Real history feature: versioning alone does not prohibit deleting protected content for five years.
The reasoning
Locked time-based retention prevents modification AND cannot be shortened (one-way lock). Legal hold is for ad-hoc holds. Soft delete is recoverable, not truly immutable. A locked time-based policy meets the fixed nonshortenable-retention requirement; regulatory compliance also depends on the full configuration and process.
S5
NFS share mounts fine from a VM in the storage account's own VNet. Peered VNet's VM gets "Permission denied." Cause?- A. Storage account's Network firewall (Selected networks) must explicitly whitelist the peered subnet as a service endpoint, or a Private Endpoint reachable from the peered VNet must exist
- B. Wrong NFS version
- C. VM missing NFS client
- D. Missing SAS token
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real network-access requirement: peering does not automatically authorize the remote subnet at the storage firewall; validate private reachability and DNS too.
Why this is not the answer
Real protocol concern: version compatibility can matter, but the working same-VNet mount points first toward differing network access.
Why this is not the answer
Real client prerequisite: missing NFS software generally prevents mounting at all, rather than causing this network-specific permission difference.
Why this is not the answer
Real Blob/Files token concept, wrong protocol: Azure Files NFS does not authenticate mounts with a SAS token.
The reasoning
NFS Files use network-only ACL (no identity). Storage firewall must whitelist the peered subnet, or a PE must be reachable from that subnet. Peered subnets are not automatically trusted.
S6
AzCopy transfer from a VM to a storage account plateaus at 100 MB/s despite a 5 Gbps NIC. Bottleneck investigation?- A. AzCopy concurrency default (AZCOPY_CONCURRENCY_VALUE) may be low; VM SKU may have lower egress cap than the NIC suggests; check for storage throttling (SlowDown responses in AzCopy log)
- B. Storage account is slow
- C. Only one file at a time
- D. AzCopy has a hard cap
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real diagnostic controls: inspect transfer concurrency, VM throughput, disks and service throttling before assuming advertised NIC speed is achievable.
Why this is not the answer
Unsupported diagnosis: labeling the account slow identifies no limit or measured bottleneck.
Why this is not the answer
False universal behavior: AzCopy supports concurrent transfers; it is not inherently restricted to one file at a time.
Why this is not the answer
False fixed-limit claim: 100 MB/s is not a universal AzCopy cap; throughput depends on the full transfer path.
The reasoning
Concurrency, VM egress cap, and storage throttling are the three usual suspects. Increase AZCOPY_CONCURRENCY_VALUE for many small files. Check VM SKU network baseline (smaller SKUs have lower egress caps than the NIC advertises).
Docs: AzCopy optimize | VM network bandwidth
S7
Storage account bill jumped 300% last month. Metrics + logs?- A. Transaction metrics (billed per 10K), egress metrics, capacity metrics, tier change activity (lifecycle rewrites), Azure Monitor storage resource logs by API operation
- B. Only capacity metric
- C. VM Insights
- D. NSG flow logs
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real billing investigation: correlate capacity, transactions, transfer and operation logs with the actual billing meters; pricing varies by operation/tier.
Why this is not the answer
Real metric, incomplete: capacity alone misses transaction, retrieval and transfer charges.
Why this is not the answer
Real VM telemetry: VM Insights describes compute performance rather than directly explaining storage service billing meters.
Why this is not the answer
Real legacy network telemetry: NSG flow records alone do not account for storage transactions, capacity and tier-related charges.
The reasoning
Cost drivers: transactions (heavy reads on Cool/Archive are expensive), egress (cross-region or internet), tier changes (lifecycle rewrites count), Archive rehydration. Cost Management + Storage Insights workbook + billed-meter breakdown surface them.
Docs: Understand storage billing | Storage Insights workbook
S8
Serve a static website from blob storage overwww.example.com with HTTPS + free auto-renewing cert. Steps?
- A. Enable static website on the storage account, front with Azure Front Door Standard/Premium with a managed certificate for HTTPS on the custom domain
- B. Enable static website + use storage account's certificate for custom domain (not supported)
- C. Public blob container with
index.html - D. Azure DNS only
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real HTTPS front end: Front Door supports a custom-domain managed certificate in front of the storage website endpoint.
Why this is not the answer
False certificate capability: a storage endpoint certificate does not automatically cover your custom hostname.
Why this is not the answer
Real public container: publishing index.html alone does not provide the custom-domain managed HTTPS certificate.
Why this is not the answer
Real DNS service: name resolution alone cannot terminate TLS or issue/install the site's HTTPS certificate.
The reasoning
Storage accounts don't serve HTTPS on custom domains natively. CDN or Front Door terminates HTTPS with a free managed certificate on the custom domain. Enable Static Website on the account for the $web container mapping.
Docs: Static website hosting | Custom domain with HTTPS via Front Door
S9
A SAS token leaked in a support ticket. Immediate actions?- A. Rotate the account key that signed the SAS (invalidates all SAS signed with that key); for user delegation SAS, revoke the storage account's user delegation keys; audit logs; rotate again after review
- B. Delete the container
- C. SAS tokens are safe once shared
- D. Change storage account name
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real revocation methods: revoke according to signing type; key rotation affects all dependent clients/tokens, so coordinate recovery and inspect usage.
Why this is not the answer
Real destructive operation: deleting the container destroys availability/data instead of revoking the leaked credential appropriately.
Why this is not the answer
False security claim: SAS is a bearer credential; anyone possessing a valid token can exercise its permissions.
Why this is not the answer
Unsupported rename fix: storage accounts cannot simply be renamed to revoke a token; use supported credential revocation.
The reasoning
Account-key-signed SAS: rotate that key. Stored access policy SAS: delete/update the policy. User delegation SAS: revoke user delegation keys (for example, az storage account revoke-delegation-keys); changing RBAC can be subject to caching. Always follow with a log audit and second rotation cycle.
S10
Two regions writing blobs active-active. Sync bidirectional within one hour. Mechanism?- A. Object Replication with two one-way policies (A -> B and B -> A); versioning + change feed enabled on both accounts; per-container rules
- B. GRS failover
- C. AzCopy scheduled tasks
- D. Front Door
Show answer & explain every option
Listed key (under review): A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real replication feature, invalid proposed design: destination containers reject writes; opposing policies do not provide same-container active-active conflict resolution.
Alternative · under review
Real disaster recovery: GRS has a primary writer and asynchronous secondary, not two simultaneously writable peers.
Alternative · under review
Real transfer tool: scheduled copies require conflict handling and monitoring; scheduling alone guarantees neither convergence nor one-hour replication.
Alternative · under review
Real traffic-routing service: Front Door routes HTTP requests; it does not synchronize blob contents or resolve conflicting writes.
Original explanation · under review
Object Replication async replicates blobs, typical lag under 15 minutes. Bidirectional requires two policies. Both accounts need versioning + change feed. Last-writer-wins on conflicts.
Docs: Object replication overview | Configure object replication
S11
Backup job writes 1 TB/day to blob, retained 90 days. Best access tier?- A. Hot
- B. Cool (30-day minimum, low storage cost, occasional reads OK)
- C. Archive (180-day minimum too long for a 90-day retention window)
- D. Cold (90-day minimum aligns exactly with retention)
Show answer & explain every option
Listed key (under review): D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Alternative · under review
Real online tier: Hot favors frequent access; price cannot be judged from retention alone.
Alternative · under review
Real online tier: Cool trades lower storage cost for higher access costs; it may fit depending on restore frequency.
Alternative · under review
Real offline tier: Archive has rehydration delays and early-deletion billing considerations when retention is shorter than its minimum period.
Listed key · under review
Real online tier: Cold's 90-day minimum aligns with retention, but this alone does not prove lowest total cost.
Original explanation · under review
(Cold if you truly don't test restores in-window; Cool if you do)
Explanation: Cold's 90-day minimum aligns with retention. If you test restores regularly, Cool (30-day minimum) at higher storage cost is safer. Archive is wrong: deleting at 90 triggers early-deletion fee (180-day minimum).
S12
Data scientist needs read on ONE container's blobs only. No other permissions. Setup?- A. Storage Blob Data Reader scoped to that container (RBAC supports container-level scope in the portal)
- B. Storage Blob Data Reader at the storage account
- C. Reader at the account
- D. 90-day SAS token
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real scoped data role: container-level Storage Blob Data Reader grants the requested read access without covering sibling containers.
Why this is not the answer
Real data role, excessive scope: account-level assignment covers all containers in the account.
Why this is not the answer
Real management-plane role: Reader views account configuration, not blob contents through Entra data authorization.
Why this is not the answer
Real token alternative: a SAS could grant scoped access, but this choice specifies no safe scope and uses a long-lived bearer credential.
The reasoning
Data-plane RBAC supports container scope. Assign Storage Blob Data Reader at the container resource for least-privilege. No read on other containers is granted. The role includes container metadata read as well as blob data read.
S13
GRS account underwent customer-managed unplanned failover 2 weeks ago. Ops wants to fail back to the original region. Steps?- A. Initiate reverse failover in one click
- B. No direct failback. Post-failover the account is LRS in the former secondary; re-enable GRS (full re-copy to a new secondary), then failover back
- C. AzCopy the data
- D. Automatic
Show answer & explain every option
Correct: B
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
False one-click assumption: after unplanned failover the account must regain suitable geo-redundancy before another failover.
✓ Correct choice
Real recovery sequence: re-establish geo-redundancy, wait for replication and assess a supported return strategy and data-loss risk.
Why this is not the answer
Real copy tool: copying objects does not itself restore account-level geo-redundancy or perform the service failback workflow.
Why this is not the answer
False automatic behavior: customer-managed unplanned failover does not imply automatic return to the original region.
The reasoning
After this unplanned failover the account is LRS. Re-establish geo-redundancy before failing back; planned failover has a different workflow. Re-enable geo-redundancy (full re-copy, hours to days depending on size), then a subsequent failover moves the primary back. This weight is why failover is a heavyweight decision.
Docs: Account failover | Initiate failover
S14
HR uploads sensitive PII. Keys must live in HR's Key Vault and rotate quarterly. Config?- A. Enable CMK on the storage account referencing HR's Key Vault key; grant the account's identity Get/Wrap/Unwrap on the key; rotate the KEK on schedule
- B. Account keys, rotated quarterly
- C. ADE
- D. Blob-level SAS
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real CMK design: the storage identity needs access to the Key Vault key; schedule rotation and verify key-version update behavior.
Why this is not the answer
Real access credentials, wrong key purpose: storage account keys authorize data requests; they are not customer-managed encryption keys in HR's vault.
Why this is not the answer
Real VM encryption technology: Azure Disk Encryption protects VM disks, not this Blob Storage account's encryption key hierarchy.
Why this is not the answer
Real delegated-access token: a SAS grants request permissions; it does not configure customer-managed encryption keys.
The reasoning
CMK stores the KEK in Key Vault. Grant the storage account's system-assigned or user-assigned identity Get, Wrap Key and Unwrap Key (or Key Vault Crypto Service Encryption User in RBAC mode). Rotate the KEK; storage updates protection of its root encryption key; configure automatic key-version updates or explicitly update the version.
Docs: Customer-managed keys | Configure CMK
S15
App writes 10K small files/sec to one blob container. Throttling at ~500 req/sec. Fix?- A. Storage scales by partition (account + container + prefix); investigate hot partitions and actual account/blob targets; distribute object names, shard across accounts, or move to Premium BlockBlob
- B. Bigger client VM
- C. Enable soft delete
- D. Change region
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real scaling investigation: verify actual account/blob targets and name distribution; measured hot partitions may justify redistribution or partitioning.
Why this is not the answer
Real compute change, unproven fix: a larger client does not remove a server-side storage target or hot partition.
Why this is not the answer
Real recovery protection: soft delete does not raise storage throughput targets and can add retained data.
Why this is not the answer
Real deployment choice, unproven fix: region changes should follow measured limits and eligibility, not an assumed universal 500-request cap.
The reasoning
Do not infer a universal 500-TPS container limit from observed throttling. Check ServerBusy/OperationTimeout responses, request patterns, client concurrency and the applicable account/blob scale targets. Backoff, distributing load, sharding accounts, or premium block blob storage may help.
S16
File Sync agent registered but server endpoints show "Provisioning" indefinitely. Diagnostic path?- A. Check outbound HTTPS to
.file.core.windows.netand.afs.azure.net; agent version supported; RBAC for Storage Sync Service on the storage account;C:\ProgramData\AzureFileSync\StorageSync.log - B. Reinstall Windows
- C. Key rotation broke it
- D. NSG on the storage account
Show answer & explain every option
Listed key (under review): A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real diagnostic categories: connectivity, supported agent and provisioning errors matter; the old precise log path/role claims need verification.
Alternative · under review
Real but drastic action: reinstalling Windows discards diagnostic evidence and is not a first-line provisioning investigation.
Alternative · under review
Possible hypothesis, unproven: inspect the specific authentication error before attributing provisioning to key rotation.
Alternative · under review
Incorrect resource model: an NSG attaches to a subnet or NIC, not directly to a storage account; inspect actual network controls.
Original explanation · under review
Common causes: firewall blocking egress to Storage or Sync endpoints, outdated agent, missing "Reader and Data Access" role on the storage account for the Storage Sync Service. StorageSync.log surfaces the specific failure.
S17
Auditor: prove no data left the region for the last 90 days. Which logs?- A. Storage Analytics logs (Diagnostic Settings > StorageRead/StorageWrite) with RequesterIpAddress + Region fields, KQL over 90 days; NSG flow logs; PE + firewall logs
- B. Activity logs only
- C. AzCopy logs
- D. These request logs alone cannot prove the stated regional non-egress claim
Show answer & explain every option
Correct: D
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Why this is not the answer
Real logging concepts, insufficient proof: request IPs do not establish every data path or physical-region residency; the asserted Region field is also questionable.
Why this is not the answer
Real control-plane log: Activity Log records management actions, not every data transfer or replica location.
Why this is not the answer
Real client transfer log: AzCopy logs describe that client's jobs, not all storage service replication and other clients.
✓ Correct choice
True evidence limitation: request logs alone cannot prove universal regional non-egress; review architecture, replication, exports and service residency guarantees.
The reasoning
Storage request logs can support an audit of observed access, but client IP addresses are not proof of data residency or all downstream data movement. Assess replication configuration, network controls, destinations, and retained evidence together. Do not claim a KQL query proves universal non-egress.
S18
Change existing production storage account from LRS to GZRS. Impact + steps?- A. Use the supported conversion to zone redundancy, then enable geo-replication as required; verify account/region eligibility
- B. Requires full re-upload
- C. Data becomes read-only for hours
- D. Must recreate the account
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real supported conversion: zone-redundancy conversion and geo-replication depend on the account type, features and available regions.
Why this is not the answer
False universal requirement: supported in-place redundancy changes do not inherently require re-uploading all data.
Why this is not the answer
Unsupported universal outage claim: read-only hours are not a blanket consequence; follow the specific supported conversion procedure.
Why this is not the answer
False universal requirement: compatible accounts can use supported conversion without recreating the account.
The reasoning
Follow the migration matrix for the source and target redundancy. Zone-redundancy conversion is a background operation for supported accounts and keeps data available. Conversions and subsequent geo-replication can take time; do not assume every direction is a simple setting change or a support-only reverse conversion.
Docs: Change redundancy | Redundancy overview
S19
Compliance requires deletion within 24 hours of retention expiry. Lifecycle rule + verification?- A. Lifecycle rule with delete action at day N; validate via Blob Inventory report + KQL for blobs older than the threshold; document daily eval cadence
- B. Delete manually monthly
- C. Set soft delete to 1 day
- D. Rely on backup expiration
Show answer & explain every option
Listed key (under review): A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
Listed key · under review
Real lifecycle/inventory tools, insufficient guarantee: asynchronous processing and reports do not establish deletion within a strict 24-hour deadline.
Alternative · under review
Real manual deletion, wrong cadence: monthly cleanup cannot meet a 24-hour expiration requirement.
Alternative · under review
Real recovery setting, wrong action: soft delete retains deleted objects; it does not initiate deletion at the business retention deadline.
Alternative · under review
Real backup lifecycle, wrong dataset: backup expiration does not prove deletion of live blobs, versions or snapshots.
Original explanation · under review
Lifecycle evaluates once per day (~24h SLA), meeting the 24-hour post-expiry window. Blob Inventory + KQL proves compliance. Soft delete retention adds days to true deletion; set it to the minimum acceptable.
Docs: Blob inventory | Lifecycle delete rule
S20
Storage account had public access disabled during hardening. Azure Monitor diagnostic-settings delivery to the Storage archive then fails. Cause + fix?- A. Use the documented Azure Monitor trusted-services bypass on a supported storage account firewall; a private endpoint alone does not route diagnostic-settings delivery
- B. Log Analytics is offline
- C. Wrong workspace
- D. Diagnostic Settings requires Basic
Show answer & explain every option
Correct: A
Understand every option
A wrong choice can name a real feature. Here is what each option means and how it fits this question.
✓ Correct choice
Real service integration: Azure Monitor diagnostic delivery needs the documented storage firewall/trusted-service configuration; a private endpoint alone is insufficient.
Why this is not the answer
Possible unrelated outage, unsupported diagnosis: the failing destination is a storage archive, not necessarily Log Analytics.
Why this is not the answer
Real configuration concern, wrong destination: workspace selection does not directly repair storage firewall restrictions.
Why this is not the answer
Invented requirement: there is no universal Basic tier requirement for diagnostic-settings delivery.
The reasoning
Diagnostic settings send directly from Azure Monitor to each destination. For a firewalled Storage destination, configure the documented trusted Microsoft services exception and validate the public-network-access/firewall combination. A workspace private endpoint is not the route for storage archive delivery.
Docs: Storage trusted Microsoft services | Storage private endpoints