Storage Account practice questions

Assign Storage Account Contributor at the resource group scope.

Why wrong: This grants management-plane control over the storage account and is much broader than needed.

Assign Reader and give the service principal a storage account access key.

Why wrong: This introduces stored credentials and does not follow the Entra-based least-privilege requirement.

Assign Contributor at the subscription scope and restrict access with naming conventions.

Why wrong: Naming conventions do not enforce security, and subscription scope is unnecessarily broad.

A metric alert on storage capacity with an action group.

Why wrong: Capacity metrics do not indicate platform outage conditions or regional service health events.

A log alert on storage diagnostic logs that watches for 503 responses.

Why wrong: This depends on continuous log collection and may miss the platform-level health signal the team wants.

An Azure Policy assignment that audits the storage account state.

Why wrong: Policy can report compliance, but it does not notify operators about live availability incidents.

A CanNotDelete lock was applied to the storage account.

Why wrong: CanNotDelete blocks deletion only and would not stop normal write operations such as changing settings.

An Azure Policy audit assignment was applied to the storage account.

Why wrong: Audit policies report compliance but do not block configuration changes or create this type of failure symptom.

The account was moved to a different subscription.

Why wrong: A subscription move would not specifically produce the described write failures while still allowing read access.

A user-defined route

Why wrong: A route affects packet forwarding, not DNS resolution.

An Azure Firewall policy

Why wrong: Firewall policy governs filtering and does not provide service name mapping.

A Recovery Services vault

Why wrong: A Recovery Services vault is unrelated to private endpoint DNS resolution.

Create a private endpoint and disable public network access on the storage account.

Why wrong: This changes the access model to private IP access instead of keeping the public endpoint available.

Place the subnet behind a NAT gateway and use a shared public IP.

Why wrong: A NAT gateway controls outbound internet translation, not authorization to a storage account.

Add a VPN gateway and route storage traffic through the branch office.

Why wrong: A VPN gateway is for hybrid connectivity and does not by itself restrict storage access to one subnet.

Use a blob container and mount it through the Blob API

Why wrong: Blob containers are object storage, not shared file systems, and they do not provide the same SMB file-share experience.

Use anonymous access on an Azure File share

Why wrong: Anonymous access is not appropriate for a secured enterprise file share and would not satisfy the access control requirement.

Use a premium NFS file share with a shared access signature

Why wrong: NFS does not provide the same Windows-and-AD-DS file-sharing model, and a SAS is a secret-based access mechanism that violates the key restriction.

Create a route table that sends storage traffic to the private endpoint subnet.

Why wrong: Routing does not control name resolution, so a route table will not change the DNS answer.

Enable a service endpoint on the subnet that hosts the VMs.

Why wrong: Service endpoints do not make a storage account resolve to a private IP address.

Assign a public IP address to the private endpoint subnet.

Why wrong: Private endpoints are meant to stay private, and a public IP would not correct DNS behavior.

Enable anonymous blob access

Why wrong: Anonymous access affects authorization, not network path control, so it would not restrict internet traffic.

Move the container to the Archive tier

Why wrong: Tiering changes storage cost and availability behavior, but it does not limit which networks can connect.

Assign the Contributor role to the subnet

Why wrong: Azure RBAC does not assign roles to a subnet for storage network filtering, so this would not control access path.

Create a private endpoint and a private DNS zone for the storage account.

Why wrong: That would give the service a private IP and require DNS integration, which the requirement explicitly avoids.

Allow access only from the VM public IP address.

Why wrong: That secures by public IP, not by subnet, and it breaks if the VM is replaced or its address changes.

Place the storage account in the same resource group as the VM.

Why wrong: Resource-group placement does not control network access or restrict traffic to a subnet.

A service endpoint on the subnet and a storage account firewall rule for the subnet.

Why wrong: Service endpoints do not create a private IP address and do not change DNS to a private endpoint address.

Allow trusted Microsoft services on the storage account and keep the public endpoint enabled.

Why wrong: Trusted Microsoft services is not private VNet connectivity and does not provide a private IP or private DNS resolution.

Create a public DNS record that maps the blob FQDN to the storage account's public IP address.

Why wrong: A public record would defeat the requirement for private-only name resolution inside the VNet.

A user-defined route on the subnet

Why wrong: Routes affect packet forwarding, not DNS resolution.

An additional public IP address

Why wrong: A public IP is not needed for private endpoint name resolution.

An Azure Firewall policy

Why wrong: Firewall policy controls filtering and does not provide DNS mapping.

Generate a service SAS by using the storage account key and email the URL to the partner.

Why wrong: A service SAS depends on the shared key, which the exhibit says is disabled. Sharing the account key also gives broader access than needed and is harder to control safely.

Make the container public and remove the SAS requirement from the partner workflow.

Why wrong: Public container access would expose data to anyone who knows or can discover the URL. It would also remove the ability to tightly control the six-hour access window required in the exhibit.

Assign the partner Storage Blob Data Contributor on the storage account and let them sign in interactively.

Why wrong: RBAC can work for Azure identities, but this does not match a temporary external sharing scenario well. It also grants broader ongoing access than the exhibit requires and is not as convenient for a one-time access window.

Locally redundant storage (LRS)

Why wrong: LRS keeps copies within one datacenter only, so a zone failure can still affect availability.

Geo-redundant storage (GRS)

Why wrong: GRS adds replication to a paired region, but it is not the best match when only intra-region zone resilience is required.

Read-access geo-redundant storage (RA-GRS)

Why wrong: RA-GRS includes geo-replication and read access to the secondary region, which is more than this requirement asks for.

A network security group on the subnet.

Why wrong: An NSG controls traffic filtering, not DNS name resolution.

A public DNS zone for the storage account name.

Why wrong: A public DNS zone would not provide private endpoint resolution within the VNet.

A user-defined route table on the subnet.

Why wrong: Route tables control packet forwarding paths, not DNS resolution.

Create a resource lock on the workspace and let each team send emails when incidents happen.

Why wrong: A lock protects the workspace from changes, but it does not collect logs or make them available for KQL analysis.

Move the VM and storage account into the same availability set so their logs appear together.

Why wrong: Availability sets provide resiliency for VMs only and do not centralize or combine telemetry from different services.

Enable a private endpoint for the workspace and disable all diagnostic collection.

Why wrong: Private connectivity can be useful, but it does not replace telemetry collection, and disabling diagnostic collection would prevent troubleshooting.

Azure RBAC, because it controls whether users can create resources.

Why wrong: This is incorrect because RBAC controls who can perform actions, not whether a resource configuration meets a compliance rule.

A resource lock, because it can force resources to use tags.

Why wrong: This is incorrect because locks prevent deletion or modification, but they do not evaluate deployment rules like required tags.

A service endpoint, because it can filter which resources are allowed in a subscription.

Why wrong: This is incorrect because service endpoints are for network access to Azure services, not compliance enforcement.

A storage account access key, because it can be copied into the import tool.

Why wrong: An account key grants broad access to the entire storage account and is not scoped to one container.

A shared key connection string, because it works with any tool that needs blob access.

Why wrong: A shared key connection string exposes broad account-level credentials and is not limited to one container.

A managed identity token, because the contractor can use it outside Azure directly.

Why wrong: Managed identities are tied to Azure resources and are not something an external contractor directly receives.

LRS, because it keeps copies only within one datacenter and does not provide zone or geo protection.

Why wrong: LRS protects against local hardware failures, but all copies stay in one datacenter and one region.

ZRS, because it replicates across zones in one region but does not add secondary-region replication.

Why wrong: ZRS helps with a zone outage, but by itself it does not provide replication to another region.

RA-GRS, because it allows reading from the secondary region but does not use zone-redundant storage in the primary region.

Why wrong: RA-GRS gives read access to the secondary region, but it does not provide zone redundancy in the primary region.

Grant the partner Contributor access on the storage account

Why wrong: Contributor is broader than needed and still requires the partner to have an identity in the tenant.

Share the storage account access key and let the partner create their own token

Why wrong: Sharing the account key exposes full secret material and defeats the requirement to avoid key distribution.

Enable anonymous public write access on the container

Why wrong: Anonymous write access is not a secure or controlled way to grant temporary partner access.

Remove the policy assignment from the management group until the migration is finished.

Why wrong: Removing the assignment weakens governance for every subscription under the management group, not just the one legacy resource.

Apply a CanNotDelete lock to the storage account.

Why wrong: A resource lock helps prevent deletion, but it does not override a policy denial for public network access settings.

Assign a Contributor role to the migration team on the storage account.

Why wrong: RBAC permissions do not bypass policy evaluation, so additional access rights will not permit a denied configuration.