You save $69.98
An infrastructure design was selected to meet: use a customer-managed encryption key under separately governed key custody. What caveat remains relevant during operation?
Customer-managed keys increase operational responsibility; unavailable or deleted keys can make stored data inaccessible. That remains a practical service boundary even after the recommended change (configure storage account encryption with a supported customer-managed key in Azure Key Vault or Managed HSM and authorize the account identity) is implemented; retest it when identities, policies, service capacity or network paths change.
The successful check 'Read an existing encrypted blob after granting intended key access' proves only the tested behavior and cannot eliminate every dependent failure. The specific remaining limitation is: Customer-managed keys increase operational responsibility; unavailable or deleted keys can make stored data inaccessible.
The two checks cover separate behavior: 'Read an existing encrypted blob after granting intended key access' and 'Temporarily deny key operations in a safe test and confirm failure is detected and recoverable'. Neither check removes the remaining operational limitation: Customer-managed keys increase operational responsibility; unavailable or deleted keys can make stored data inaccessible.
The incident (the storage account cannot read encrypted blobs after its key vault access permission is revoked) could recur if a related Azure dependency changes. The design still faces the limitation: Customer-managed keys increase operational responsibility; unavailable or deleted keys can make stored data inaccessible.
An Azure operations team is evaluating a proposed change: A security team wants a visual interface for browsing selected Azure Blob containers with controlled user sign-in. It must achieve: inspect and transfer storage items interactively without using the portal as the only client. Which solution fits the stated boundary?
Storage Explorer offers interactive data browsing and management while honoring the account's data authorization and networking rules. This achieves inspect and transfer storage items interactively without using the portal as the only client through use Azure Storage Explorer with a supported Microsoft Entra sign-in and appropriately scoped storage permissions instead of relying on merely similar resource settings.
Management groups organize policy scopes; they do not browse blob objects; that would not meet inspect and transfer storage items interactively without using the portal as the only client, for which the relevant Azure action is use Azure Storage Explorer with a supported Microsoft Entra sign-in and appropriately scoped storage permissions.
Advisor produces recommendations, not a file explorer; that would not meet inspect and transfer storage items interactively without using the portal as the only client, for which the relevant Azure action is use Azure Storage Explorer with a supported Microsoft Entra sign-in and appropriately scoped storage permissions.
Shared keys unnecessarily broaden access compared with scoped identities; that would not meet inspect and transfer storage items interactively without using the portal as the only client, for which the relevant Azure action is use Azure Storage Explorer with a supported Microsoft Entra sign-in and appropriately scoped storage permissions.
An engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch. Which root cause deserves priority?
The trace reports: An engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch. The causal misconfiguration is: The signed-in Entra principal has no applicable Storage Blob Data Reader or stronger blob data role at the requested scope. The targeted action is to assign the correct blob data role and verify the Storage Explorer connection method and firewall access.
The account uses GRS rather than a read-access geo-redundant configuration; that mechanism would be more consistent with an observation such as the application cannot read from the secondary endpoint before failover even though geo-replication is configured, rather than this case's an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch.
The selected redundancy keeps copies in one local fault domain instead of independent zones; that mechanism would be more consistent with an observation such as the app's LRS data becomes inaccessible during a zone-level storage failure, rather than this case's an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch.
Required versioning, change feed, or the active object replication policy was not configured correctly; that mechanism would be more consistent with an observation such as new block blobs stop appearing at the destination despite an intended object replication rule, rather than this case's an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch.
Storage Explorer can view management properties, but token-based List Blobs returns AuthorizationPermissionMismatch despite verified network reachability. What is the most targeted correction?
Assign the correct blob data role and verify the Storage Explorer connection method and firewall access. This addresses the documented failure condition: the signed-in Entra principal has no applicable Storage Blob Data Reader or stronger blob data role at the requested scope. Retest the affected operation and retain the original least-privilege boundaries.
Advisor produces recommendations, not a file explorer. In the reported incident (an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch), that change would not correct the cause: the signed-in Entra principal has no applicable Storage Blob Data Reader or stronger blob data role at the requested scope.
Shared keys unnecessarily broaden access compared with scoped identities. In the reported incident (an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch), that change would not correct the cause: the signed-in Entra principal has no applicable Storage Blob Data Reader or stronger blob data role at the requested scope.
Management groups organize policy scopes; they do not browse blob objects. In the reported incident (an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch), that change would not correct the cause: the signed-in Entra principal has no applicable Storage Blob Data Reader or stronger blob data role at the requested scope.
Before accepting the rollout, the administrator reviews: A security team wants a visual interface for browsing selected Azure Blob containers with controlled user sign-in. It must accomplish: inspect and transfer storage items interactively without using the portal as the only client. Which TWO independent checks matter most? Select TWO answers.
List and download a permitted test blob using the signed-in user. This provides direct evidence on named account and intended data-plane operation rather than relying on a resource name or a presumed configuration. Its coverage is distinct from the separate check to try an unauthorized container and verify least-privileged denial: both are necessary to support inspect and transfer storage items interactively without using the portal as the only client.
Try an unauthorized container and verify least-privileged denial. This provides direct evidence on named account and intended data-plane operation rather than relying on a resource name or a presumed configuration. Its coverage is distinct from the separate check to list and download a permitted test blob using the signed-in user: both are necessary to support inspect and transfer storage items interactively without using the portal as the only client.
Management-plane visibility for a privileged administrator does not verify a scoped Storage Explorer user can read the intended Blob data.
An account-key SAS follows a different authorization path. Its success cannot establish the intended Entra-based interactive user access.
The positive data read covers only the allowed path. The second independent test must prove that an out-of-scope container is actually rejected.
An Azure administrator describes a solution for: inspect and transfer storage items interactively without using the portal as the only client. What remaining limitation must not be misrepresented?
Interactive access through Storage Explorer is still constrained by data-plane RBAC and storage firewall rules. That remains a practical service boundary even after the recommended change (use Azure Storage Explorer with a supported Microsoft Entra sign-in and appropriately scoped storage permissions) is implemented; retest it when identities, policies, service capacity or network paths change.
The two checks cover separate behavior: 'List and download a permitted test blob using the signed-in user' and 'Try an unauthorized container and verify least-privileged denial'. Neither check removes the remaining operational limitation: Interactive access through Storage Explorer is still constrained by data-plane RBAC and storage firewall rules.
The incident (an engineer signs in to Storage Explorer with Microsoft Entra ID and can view the storage account resource. A network trace confirms the Blob endpoint is reachable; the list-blobs call fails with AuthorizationPermissionMismatch) could recur if a related Azure dependency changes. The design still faces the limitation: Interactive access through Storage Explorer is still constrained by data-plane RBAC and storage firewall rules.
The successful check 'List and download a permitted test blob using the signed-in user' proves only the tested behavior and cannot eliminate every dependent failure. The specific remaining limitation is: Interactive access through Storage Explorer is still constrained by data-plane RBAC and storage firewall rules.
An Azure operations team is evaluating a proposed change: A single-region application needs its storage data replicated across separate availability zones within the region without asynchronous cross-region failover. It must achieve: select a redundancy option that survives a zone outage within the same region. Which solution fits the stated boundary?
ZRS synchronously distributes copies across separate availability zones in one region. This achieves select a redundancy option that survives a zone outage within the same region through choose zone-redundant storage (ZRS) when the account type and region support it instead of relying on merely similar resource settings.
Snapshots within one region do not replicate the account across zones; that would not meet select a redundancy option that survives a zone outage within the same region, for which the relevant Azure action is choose zone-redundant storage (ZRS) when the account type and region support it.
LRS copies data within a local location, not across zones; that would not meet select a redundancy option that survives a zone outage within the same region, for which the relevant Azure action is choose zone-redundant storage (ZRS) when the account type and region support it.
Ordinary GRS secondaries are not generally readable unless RA mode is chosen or failover occurs; that would not meet select a redundancy option that survives a zone outage within the same region, for which the relevant Azure action is choose zone-redundant storage (ZRS) when the account type and region support it.
During incident triage, the cloud team observes: The app's LRS data becomes inaccessible during a zone-level storage failure. The goal was: select a redundancy option that survives a zone outage within the same region. Which configuration mistake most directly explains it?
The trace reports: The app's LRS data becomes inaccessible during a zone-level storage failure. The causal misconfiguration is: The selected redundancy keeps copies in one local fault domain instead of independent zones. The targeted action is to migrate to a supported ZRS account configuration for zone-level resilience.
The proposed mechanism concerns the account is using verified zone-redundant storage and continued to serve reads throughout the observed zonal outage, which is not established by the observed the app's LRS data becomes inaccessible during a zone-level storage failure. Test the more directly supported condition: The selected redundancy keeps copies in one local fault domain instead of independent zones.
The account uses GRS rather than a read-access geo-redundant configuration; that mechanism would be more consistent with an observation such as the application cannot read from the secondary endpoint before failover even though geo-replication is configured, rather than this case's the app's LRS data becomes inaccessible during a zone-level storage failure.
Required versioning, change feed, or the active object replication policy was not configured correctly; that mechanism would be more consistent with an observation such as new block blobs stop appearing at the destination despite an intended object replication rule, rather than this case's the app's LRS data becomes inaccessible during a zone-level storage failure.
A production configuration must be repaired: The app's LRS data becomes inaccessible during a zone-level storage failure. Which corrective action should the administrator take?
Migrate to a supported ZRS account configuration for zone-level resilience. This addresses the documented failure condition: the selected redundancy keeps copies in one local fault domain instead of independent zones. Retest the affected operation and retain the original least-privilege boundaries.
Snapshots within one region do not replicate the account across zones. In the reported incident (the app's LRS data becomes inaccessible during a zone-level storage failure), that change would not correct the cause: the selected redundancy keeps copies in one local fault domain instead of independent zones.
Ordinary GRS secondaries are not generally readable unless RA mode is chosen or failover occurs. In the reported incident (the app's LRS data becomes inaccessible during a zone-level storage failure), that change would not correct the cause: the selected redundancy keeps copies in one local fault domain instead of independent zones.
LRS copies data within a local location, not across zones. In the reported incident (the app's LRS data becomes inaccessible during a zone-level storage failure), that change would not correct the cause: the selected redundancy keeps copies in one local fault domain instead of independent zones.
Before accepting the rollout, the administrator reviews: A single-region application needs its storage data replicated across separate availability zones within the region without asynchronous cross-region failover. It must accomplish: select a redundancy option that survives a zone outage within the same region. Which TWO independent checks matter most? Select TWO answers.
Validate app reconnection and operational behavior during documented zonal-failure handling. This supplies observed evidence for select a redundancy option that survives a zone outage within the same region. It is not interchangeable with the second required check, inspect account redundancy and confirm the intended ZRS SKU is applied, because that checks a separate success or failure boundary.
Inspect account redundancy and confirm the intended ZRS SKU is applied. This supplies observed evidence for select a redundancy option that survives a zone outage within the same region. It is not interchangeable with the second required check, validate app reconnection and operational behavior during documented zonal-failure handling, because that checks a separate success or failure boundary.
A release checklist recording 'Inspect account redundancy and confirm the intended ZRS SKU is applied' is not evidence that the required operation actually succeeded or failed. To establish the correct result, the team must inspect account redundancy and confirm the intended ZRS SKU is applied on the actual workload to prove its independent boundary.
A configured resource is not proof of live behavior. The required check must exercise validate app reconnection and operational behavior during documented zonal-failure handling on the affected Azure deployment.
A privileged administrator in a different subscription may succeed at 'Validate app reconnection and operational behavior during documented zonal-failure handling' even though the intended caller fails. This does not prove the required behavior for validate app reconnection and operational behavior during documented zonal-failure handling.
An Azure administrator describes a solution for: select a redundancy option that survives a zone outage within the same region. What remaining limitation must not be misrepresented?
ZRS does not provide cross-region disaster recovery; region-wide outages require another protection strategy. That remains a practical service boundary even after the recommended change (choose zone-redundant storage (ZRS) when the account type and region support it) is implemented; retest it when identities, policies, service capacity or network paths change.
The incident (the app's LRS data becomes inaccessible during a zone-level storage failure) could recur if a related Azure dependency changes. The design still faces the limitation: ZRS does not provide cross-region disaster recovery; region-wide outages require another protection strategy.
The successful check 'Validate app reconnection and operational behavior during documented zonal-failure handling' proves only the tested behavior and cannot eliminate every dependent failure. The specific remaining limitation is: ZRS does not provide cross-region disaster recovery; region-wide outages require another protection strategy.
The two checks cover separate behavior: 'Validate app reconnection and operational behavior during documented zonal-failure handling' and 'Inspect account redundancy and confirm the intended ZRS SKU is applied'. Neither check removes the remaining operational limitation: ZRS does not provide cross-region disaster recovery; region-wide outages require another protection strategy.
or Guarantee your success by buying the full version which covers the full latest pool of questions. (606 Questions, Last Updated on Oct 25, 2026)
Please check your mailbox for a message from support@examlabs.com and follow the directions.
