Microsoft AZ-104 Practice Test 24
Question 230
A blob private endpoint works but Azure Files SMB traffic still resolves a public file endpoint. What is missing?
- Check TCP port 445 reachability and intervening firewall or ISP rules.
- Create and approve a separate file-subresource private endpoint and its DNS mapping.
- Identify whether the client relies on account-key-signed SAS rather than Entra-backed authorization.
- Inspect the browser preflight request and storage CORS response headers.
Explanation
Correct Answer
B:Private endpoints target storage subresources such as blob or file independently. A blob endpoint does not privately expose the file service.
Incorrect Answers
A:Correct DNS and private endpoint state do not guarantee SMB connectivity. Network filtering of TCP 445 can block mounting. This matters here because a blob private endpoint works but Azure Files SMB traffic still resolves a public file endpoint. What is missing.
C:Account SAS depends on shared-key authorization. User delegation SAS and supported Entra authorization use different mechanisms. This matters here because a blob private endpoint works but Azure Files SMB traffic still resolves a public file endpoint. What is missing.
D:Browsers enforce cross-origin policy while command-line clients normally do not. The difference can arise even when the underlying authentication succeeds.
Question 231
A disaster-recovery design needs asynchronous secondary-region storage copies without allowing reads at the secondary during normal operation. Which tier fits?
- Choose zone-redundant storage in a supported region.
- Configure geo-redundant storage without read-access secondary enabled.
- Create a standard general-purpose v2 StorageV2 account.
- Enable RA-GZRS to make secondary-region copies readable before failover when the requirement forbids secondary reads.
Explanation
Correct Answer
B:GRS maintains a geographically separate replica for failover; ordinary read traffic is not supported on the secondary until appropriate failover. This matters here because a disaster-recovery design needs asynchronous secondary-region storage copies without allowing reads at the….
Incorrect Answers
A:ZRS synchronously replicates copies across availability zones within the primary region, retaining in-region data locality. This matters here because a disaster-recovery design needs asynchronous secondary-region storage copies without allowing reads at the….
C:General-purpose v2 provides common Azure Storage services and current feature options. Specialized premium account types are designed for narrower workloads. This matters here because a disaster-recovery design needs asynchronous secondary-region storage copies without allowing reads at the….
D:Read-access geo-zone redundancy deliberately permits reading from the secondary endpoint before failover. This exceeds the stated secondary-read restriction; supported GRS provides geo-copying without ordinary secondary reads.
Question 232
A developer tries to fetch from a read-only secondary hostname for standard GRS and receives an unsupported response. What is missing?
- Disable public blob access at the storage account while retaining authorized RBAC or SAS routes.
- Keep the account in ordinary GRS and query its secondary blob endpoint before failover without enabling read-access redundancy.
- Check the storage account's last synchronization time for geo-replication.
- Use read-access geo-redundant storage if secondary read access before failover is required.
Explanation
Correct Answer
D:RA-GRS adds a secondary read endpoint, unlike ordinary GRS. Remote copy existence alone does not mean the secondary can answer routine reads.
Incorrect Answers
A:Disabling anonymous access does not inherently block authenticated requests. Data-plane roles and network restrictions still govern those users.
B:GRS by itself does not expose the secondary replica for regular reads before failover. The requirement calls for a read-access geo-redundant option.
C:Async geo-replication can lag behind writes in the primary region. The last-sync indication helps estimate possible data-loss exposure.
Question 233
A resilient storage account must combine primary-region zone copies and a secondary-region disaster replica. Which replication option matches?
- Choose geo-zone-redundant storage when supported by region and account kind.
- Configure plain LRS and assume a copy will be maintained automatically in another Azure region.
- Choose zone-redundant storage in a supported region.
- Configure geo-redundant storage without read-access secondary enabled.
Explanation
Correct Answer
A:The requirement explicitly combines tolerance of a primary-zone loss with durability in a secondary region. GZRS provides both forms of replication when the account kind and region support it; secondary read access would separately require RA-GZRS.
Incorrect Answers
B:LRS protects against local hardware failures only. The question requires primary-zone resilience and a remote disaster copy; GZRS is the matching supported account-level redundancy option.
C:ZRS synchronously replicates copies across availability zones within the primary region, retaining in-region data locality. This matters here because a resilient storage account must combine primary-region zone copies and a secondary-region disaster replica. Which….
D:GRS maintains a geographically separate replica for failover; ordinary read traffic is not supported on the secondary until appropriate failover. This matters here because a resilient storage account must combine primary-region zone copies and a secondary-region disaster replica. Which….
Question 234
The architect expects GZRS to permit read-only secondary queries before failover. What additional property is needed?
- Use GRS without the read-access option and expect ordinary reads from the secondary before failover.
- Switch from GZRS to RA-GRS and assume this retains primary-region zonal replication unchanged.
- Disable public blob access at the storage account while retaining authorized RBAC or SAS routes.
- Use RA-GZRS rather than GZRS when pre-failover secondary read access is required.
Explanation
Correct Answer
D:Read-access variants expose a secondary read endpoint. Geo redundancy without RA is not a normal read path to secondary copies.
Incorrect Answers
A:Basic GRS does not expose a regularly readable secondary endpoint before failover. The zonally resilient account must use RA-GZRS for the requested capability.
B:RA-GRS adds secondary-region read capability but does not retain the primary-region zone redundancy of GZRS. RA-GZRS adds the required read option while preserving zonal resilience.
C:Disabling anonymous access does not inherently block authenticated requests. Data-plane roles and network restrictions still govern those users. This matters here because the architect expects GZRS to permit read-only secondary queries before failover. What additional property is needed.
Question 235
An application uses a read-heavy geo-replicated account and needs to inspect the last secondary synchronization time. Which metric/state should be checked?
- Check the storage account's last synchronization time for geo-replication.
- Review the selected connection identity and storage Blob Data permission at the data scope.
- Use the total Blob capacity metric as the timestamp of the last successful secondary-region synchronization.
- Review the configured index and error documents and client-side routing behavior.
Explanation
Correct Answer
A:Async geo-replication can lag behind writes in the primary region. The last-sync indication helps estimate possible data-loss exposure. This matters here because an application uses a read-heavy geo-replicated account and needs to inspect the last secondary synchronization….
Incorrect Answers
B:ARM resource visibility and blob content authorization can differ. An authenticated GUI still needs the correct data access. This matters here because an application uses a read-heavy geo-replicated account and needs to inspect the last secondary synchronization….
C:Blob capacity reports stored size, not the replication currency of a secondary region. The storage account's Last Sync Time is the relevant indicator of geo-replication lag.
D:Static hosting serves named objects rather than dynamically resolving every application route. Single-page applications often need suitable fallback behavior.
Question 236
A region failure occurs just after a primary write with asynchronous geo-replication. What risk must be communicated?
- Rely on Azure Storage encryption at rest with Microsoft-managed keys unless CMK is required.
- Treat an acknowledged GZRS write as guaranteed to be present in the secondary region immediately.
- Use RA-GZRS rather than GZRS when pre-failover secondary read access is required.
- Recognize that asynchronous secondary replication can have a nonzero recovery point and lose unreplicated writes.
Explanation
Correct Answer
D:Geographic redundancy is not synchronous across regions. New primary data may not have reached the secondary when failover occurs.
Incorrect Answers
A:Azure Storage encrypts data at rest automatically. Customer-managed keys are an additional key-governance option, not the base requirement for encryption.
B:GZRS synchronizes across primary-region zones but asynchronously copies to its paired region. A just-committed write may be absent at disaster time, so the RPO is not necessarily zero.
C:Read-access variants expose a secondary read endpoint. Geo redundancy without RA is not a normal read path to secondary copies. This matters here because a region failure occurs just after a primary write with asynchronous geo-replication. What risk must be communicated.
Question 237
A storage workload must recover a deleted blob during a 21-day window. Which protection should be configured?
- Stage block data with Put Block and finalize with Put Block List.
- Set container soft-delete retention to 14 days and assume it restores a single blob deleted 20 days ago.
- Share soft-delete recovery applies only inside the configured retention window.
- Enable blob soft delete and set its recovery retention to 21 days.
Explanation
Correct Answer
D:Blob soft delete retains eligible deleted blob content for the configured duration. It is not identical to container soft delete.
Incorrect Answers
A:Block blobs support staged blocks and an explicit commit list, providing a controlled final object assembly.
B:Container recovery and individual blob recovery are separate features. A 14-day container setting cannot satisfy the required 21-day individual-blob recovery window.
C:A deleted share that exceeds the retention period is not ordinarily recoverable through that feature. An independent backup may be necessary. This matters here because a storage workload must recover a deleted blob during a 21-day window. Which protection should be configured.
Question 238
An employee deletes an entire container, but individual blob soft delete was enabled and the container cannot be restored. What is missing?
- Create a lifecycle policy that archives old blobs but do not enable soft delete for the container itself.
- Enable container soft delete with a suitable retention interval before future deletions.
- Increase individual blob soft-delete days and expect a fully deleted container to be recoverable automatically.
- Turn on Azure Files share soft delete with an appropriate retention period.
Explanation
Correct Answer
B:Deleting a container is a separate operation from deleting one blob. Container-level soft delete is the relevant whole-container recovery feature.
Incorrect Answers
A:Lifecycle tiering changes blob retention costs and transitions, not the recovery of a deleted container. Container soft delete must be enabled before the deletion event to provide the whole-container recovery window.
C:Blob soft delete protects blobs and versions, not the enclosing deleted container. Enable container soft delete and set an appropriate retention before future container deletions.
D:Share soft delete retains eligible deleted file shares so the entire share can be recovered. Share snapshots focus on content states and do not replace share deletion protection. This matters here because an employee deletes an entire container, but individual blob soft delete was enabled and the container cannot be….
Question 239
An application overwrites an Azure blob each hour but must recover its prior contents from yesterday. Which capability helps?
- Rely only on a 21-day blob deletion safety window to recover previous content from repeated successful overwrites.
- Enable Blob Storage versioning for supported blob types and operations.
- Enable only container soft delete and treat each overwrite of a live blob as a recoverable previous object version.
- Enable blob versioning and lifecycle policy rules for eligible previous versions.
Explanation
Correct Answer
B:Versioning keeps earlier committed versions when supported changes occur. It serves different recovery needs from simple soft delete.
Incorrect Answers
A:Soft delete addresses deleted data, but retaining each overwrite's earlier contents requires Blob versioning or supported snapshots and an appropriate lifecycle policy.
C:Container soft delete addresses container deletion rather than historical overwrites of an existing blob. Use compatible blob versioning to retain prior bytes.
D:Versioning provides history, while lifecycle cleanup bounds retained versions under policy. A versioning switch alone can grow storage indefinitely.
Question 240
A blob has previous versions but a restore script downloads only the current revision. How can older data be retrieved?
- Enable blob versioning and lifecycle policy rules for eligible previous versions.
- Review previous-version lifecycle age filters and actual retention requirements.
- Select the desired blob version ID or promote a previous version through the supported API.
- Use Azure Data Lake Storage Gen2 hierarchical namespace in a compatible account.
Explanation
Correct Answer
C:Blob versions have distinct identifiers. Ordinary reads without a version selector target the current committed blob.
Incorrect Answers
A:Versioning provides history, while lifecycle cleanup bounds retained versions under policy. A versioning switch alone can grow storage indefinitely. This matters here because a blob has previous versions but a restore script downloads only the current revision. How can older data be retrieved.
B:Lifecycle policies can remove eligible past versions. Recovery expectations must align with the configured cleanup window.
D:Hierarchical namespace supports directories and ACLs for data-lake workloads, with Blob API integration. Design must check feature compatibility.
