Storage Account practice questions

Interactive logins: Storage account access keys

Why it fails: Storage account access keys are shared keys that confer full administrative control over the entire storage account, including the ability to read and delete all data, so they completely violate the principle of least privilege for an interactive user login. They cannot be scoped to a single user or operation, do not expire automatically, and are intended only for admin-level account management. In any interactive scenario, a user delegation SAS or Microsoft Entra ID-based access should be used instead.

Automated backups: User delegation SAS

Why it fails: A user delegation SAS is inherently user-oriented because it is signed with an individual Microsoft Entra ID user's credentials and expires after a short interval, so it is unsuitable for unattended, recurring backup processes. Automated backups need a credential that can authenticate without a manually signed token and that does not require scheduled rotation, which is exactly what a system-assigned managed identity provides. Relying on a SAS for backups would risk service interruption every time the token expires.

Cross-tenant access: System-assigned managed identity

Why it fails: A system-assigned managed identity is tied to both a single Azure resource and a single Microsoft Entra ID tenant, so it cannot authenticate to resources in a different tenant where it has no identity or trust relationship. Cross-tenant access depends on a service principal that is explicitly registered and consent-granted in the target tenant, allowing its RBAC assignments to cross tenant boundaries. Managed identities are therefore limited to same-tenant scenarios such as reading storage in the same subscription.

General-purpose v2: Premium performance for block blob and append blob data, with low latency.

Why it fails: This answer is incorrect because the description of premium performance for block blob and append blob data with low latency actually corresponds to BlockBlobStorage, not General-purpose v2. General-purpose v2 is a standard-tier, multiprotocol account that supports all Azure Storage services, but it does not provide the SSD-backed, ultra-low-latency protection of premium block blob accounts. Using GPv2 for a high-throughput, low-latency blob workload would lead to suboptimal performance because GPv2 is designed for general use, not specialized premium data workloads.

BlockBlobStorage: Legacy blob-only account type.

Why it fails: This answer is incorrect because BlockBlobStorage is not a legacy blob-only account type; that description accurately describes BlobStorage. BlockBlobStorage is a modern, premium-tier account optimized for block and append blobs, built on SSDs, and engineered for high transaction rates and low latency. Calling it legacy confuses it with the older BlobStorage type and ignores the distinct performance and hardware characteristics that set it apart.

A service endpoint on the subnet so the storage account uses a private IP address.

Why it fails: Service endpoints keep the storage account's public IP and merely extend the VNet identity to it; they do not assign a private IP or alter DNS. They suit restricting a storage firewall to specific subnets while public access remains enabled, which this account has disabled.

A storage account access key on the VM so the public endpoint will accept the connection.

Why it fails: An access key authenticates requests but cannot make a disabled public endpoint reachable, and DNS still returns the public IP. Keys are the correct credential mechanism when public network access is enabled and clients connect over the internet, not for private endpoint resolution.

A user-defined route sending storage traffic to the virtual network gateway.

Why it fails: A user-defined route cannot change name resolution; the VM still queries public DNS and receives the public IP, so traffic never reaches the private endpoint. UDRs steer existing traffic flows, and would be relevant for forcing subnet traffic through a firewall or NVA, not for resolving a private endpoint's name.

Private endpoint, because it is the only way to allow one subnet.

Why it fails: A private endpoint places a private IP address inside the virtual network, which the team explicitly wants to avoid. It is tempting because it does restrict access to selected subnets. Enabling a service endpoint on the storage account's firewall restricts traffic to that subnet without creating a private IP.

User-assigned managed identity, because it controls subnet access.

Why it fails: A managed identity issues OAuth tokens to Azure resources; it has no role in network filtering. Subnet-only traffic without a private endpoint requires service endpoints plus storage firewall rules. Managed identities suit credential-free access to Key Vault or Storage from compute, not restricting inbound subnet reachability.

Blob soft delete, because it helps restrict where traffic comes from.

Why it fails: Blob soft delete retains deleted blobs for recovery; it does not inspect source IP addresses or subnet IDs, so it cannot filter traffic. It is tempting because it is a storage security setting. Network rules or a service endpoint on the subnet restrict access without assigning a private IP.

A CanNotDelete lock was applied to the storage account.

Why it fails: A CanNotDelete lock on a storage account prevents only delete operations at the locked scope. It does not restrict modifying account properties, networking rules, or child resources, so normal configuration changes and writes would still succeed. The described symptom of write operations failing while read access remains is inconsistent with this lock, making it incorrect.

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

Why it fails: An Azure Policy audit assignment uses the 'Audit' effect, which checks resources against policy rules and logs non-compliance in the Activity Log without in any way blocking or denying the attempted operation. When an administrator changes a storage account setting under this policy, the action is allowed and simply recorded as non-compliant. Therefore audit policies never produce authorization failures or read-only symptoms, so this is not the cause.

The account was moved to a different subscription.

Why it fails: Moving a storage account to a different subscription changes its ARM resource path and transfers management planning, but it does not lock down configuration or block writes. The move operation requires validation and should preserve role assignments, keys, and existing settings; after completion the account remains fully writable. Applications also continue to access the account using its existing endpoints and keys, so a subscription move does not explain write-blocked access.

Create container → Create storage account → Set access level → Upload blob → Generate SAS

Why it fails: This sequence is invalid because a container is a child resource that cannot be provisioned independently; you must have a storage account in place to provide the endpoint (e.g., https://<account>.blob.core.windows.net) and the authentication context required to create the container. Attempting to create a container first will fail with an authentication or resource-not-found error. Even if a container could be pre-created, the access level and blob upload steps would be meaningless without the storage account's service endpoint and key. The correct dependency chain demands that the storage account exists before any container, blob, or SAS token can be created.

Create storage account → Upload blob → Create container → Set access level → Generate SAS

Why it fails: This order is wrong because blobs are stored within containers, and a container acts as the partition that holds blob data. Uploading a blob before creating a container is impossible in the Azure Storage REST API—the Put Blob operation requires a valid container path in the URL. Even if you created the container immediately after uploading (which cannot succeed), the access level configuration would be applied too late, as the container's public access setting is evaluated when the blob is uploaded to determine whether the blob is immediately accessible. The correct sequence must establish the container first, then set its access policy, and only then upload blobs so that the policy is in effect from the start.

Create storage account → Create container → Upload blob → Set access level → Generate SAS

Why it fails: This is incorrect because setting the access level before uploading the blob is recommended to enforce permissions, but technically you can set it after; however, the standard best practice is to set access before upload.

Create a service endpoint on VNet-B and leave DNS unchanged.

Why it fails: Service endpoints extend VNet identity to a service's public endpoint; they do not create a private IP or alter DNS resolution, so VM-B still resolves the storage account to its public address. Service endpoints suit restricting access to specific subnets while traffic stays on the Azure backbone, not private-endpoint name resolution.

Assign a public IP address to the private endpoint.

Why it fails: A private endpoint's network interface holds a private IP by design; assigning a public IP contradicts that model and does not affect the DNS record VM-B queries. Public IPs on endpoints are not supported for this purpose. Public IPs belong to scenarios requiring inbound internet access, not private name resolution.

Add a route table with a next hop to the storage account.

Why it fails: User-defined routes control packet forwarding, not DNS name resolution; a next hop cannot point at a storage account, and no route changes what the name resolves to. Route tables are correct for forcing traffic through an NVA or virtual appliance, which is unrelated to resolving a private endpoint's IP.

Remove the policy assignment from the subscription until the migration finishes.

Why it fails: Removing the assignment disables the control for all storage accounts, not just the legacy one. That creates a governance gap and allows any other storage account to become public. The requirement is to keep the policy active everywhere except one resource.

Change the policy effect from Deny to Audit.

Why it fails: Switching the effect from Deny to Audit would stop Azure Policy from blocking noncompliant storage accounts, meaning every storage account in the subscription—not just stlegacy01—would be allowed to become publicly accessible. The policy would then only log compliance data, which does not satisfy the requirement to enforce the control for other resources. An exemption targets a single scope and preserves the Deny effect everywhere else, whereas changing the effect weakens the entire policy baseline. This option is fundamentally a policy change, not a scoped exception, so it fails to maintain the intended security posture.

Move the legacy storage account to a separate subscription and assign the policy there.

Why it fails: Moving the resource to another subscription is disruptive and does not directly address the governance need. It is also unnecessary when Azure Policy exemptions already support temporary, scoped exceptions. The question asks for the simplest correct governance action.

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

Why it fails: An account access key is the storage account's master key, granting full administrative and data-plane control over every blob, table, queue, and file share in the account. It cannot be scoped to one container, nor does it support a native expiration, so handing it to a contractor for a six-hour import task exposes the entire account indefinitely. Even if the key can be pasted into an import tool, that convenience is offset by the critical lack of least-privilege and time-limiting.

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

Why it fails: A shared key connection string bundles the account name, an access key or SAS, and the service endpoint into a single string, and tools commonly accept it. However, when it contains an account key, it offers the same account-wide permissions as the key itself and must be rotated manually if exposed; it cannot be restricted to a single blob container. Although it 'works with any tool,' that universality is not a security feature—it simply means the key is transmitted in plaintext to any software that receives the string.

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

Why it fails: Managed identity tokens are issued to Azure resources—like a VM or Functions app—that have been assigned an identity in Microsoft Entra ID, and they are intended for that resource's outbound authentication, not for an external individual. A contractor cannot simply install or use a managed identity token on their own machine; the identity has no secrets to carry away and its access is tied to the Azure resource's RBAC assignments. Therefore, using one for an outside contractor is conceptually impossible, and it is irrelevant to granting scoped, time-limited access to a single blob container.

Enable blob soft delete and mount the share with a blob container SAS token.

Why it fails: Blob soft delete is a data-protection feature that preserves deleted blobs for a retention window, so it has absolutely no role in authentication or in granting SMB access to an Azure file share. A blob container SAS token is designed for REST/API operations against Azure Blob Storage, not for the SMB file share protocol; Azure Files requires either a storage account key, an identity-based Kerberos ticket, or a file-share SAS, and even a file-share SAS wouldn't satisfy the AD DS credential requirement. This option conflates blob features with file-share identity.

Enable a service endpoint for Microsoft.Storage on the subnet.

Why it fails: A service endpoint for Microsoft.Storage restricts network traffic to the storage account from a specific virtual network subnet, but it is a network-layer control and does not affect how clients authenticate. Even with the service endpoint enabled, the VM would still need to supply some credential, such as a storage account key or a SAS token, unless identity-based authentication is separately configured. Because the question specifically demands use of existing AD DS credentials, a service endpoint alone cannot fulfill that requirement.

Create a shared access signature for the file share and map it as a local drive.

Why it fails: A shared access signature (SAS) for the file share is a delegated URI that grants time-limited access to the share, but it is not tied to any directory identity and cannot be used with the SMB protocol in the way the VM's existing AD DS login expects. Mapping a drive with a SAS URI requires embedding the token in the path or using PowerShell, which creates a connection authenticated by the token rather than by the user's domain account. Since the requirement is to use existing AD DS credentials, this approach fails.

The storage account access key, because it is easier to revoke later.

Why it fails: The storage account access key grants full administrative control over the entire storage account, including all containers, blobs, queues, tables, and the ability to modify access policies. It is not scoped to a specific container or permission level, so using it for a contractor violates least privilege and exposes the whole account. Revoking it later requires regenerating the key, which can disrupt any application still relying on it, making it harder, not easier, to manage temporary access.

A shared key rotation policy, because it grants time-limited access to one container.

Why it fails: A shared key rotation policy is a management procedure for periodically regenerating the storage account's access keys, not a credential or access delegation mechanism. It does not scope permissions to a single container, nor does it assign an expiry to a contractor's access; rotating the shared keys would invalidate access for every client using the account, providing neither granularity nor time-bound control for a one-time upload task.

A user-assigned managed identity assigned to the contractor’s laptop.

Why it fails: A user-assigned managed identity is an Microsoft Entra ID identity intended for authenticating Azure resources such as virtual machines, App Services, or Azure Functions; it cannot be assigned to a contractor's laptop because the laptop is an external non-Azure device. Even if the identity were somehow used, it would not automatically possess write permissions on the storage container—explicit RBAC or SAS assignment would still be required, and managed identity credentials are not designed for external, time-limited delegation scenarios.

Enable blob versioning on the storage account

Why it fails: Blob versioning preserves previous versions of blobs for recovery; it has no bearing on network reachability or public endpoint exposure. Versioning is tempting because it appears in storage security discussions, and would be correct when the requirement is recovering overwritten or deleted blob data rather than restricting subnet access.

Assign a ReadOnly lock to the storage account

Why it fails: A ReadOnly lock only prevents modification or deletion of the storage account; it does not filter network traffic, so public access remains possible. Locks are tempting because they sound like access control, and would be correct when the requirement is protecting a resource from accidental changes or deletion.

Enable a shared access signature

Why it fails: A shared access signature grants time-limited delegated access to storage objects but does not restrict the account's network endpoint; public network access stays enabled. SAS tokens are tempting because they control authorisation, and would be correct when granting scoped, revocable access to specific blobs without sharing account keys.

Azure Bastion to connect through the browser and complete setup interactively.

Why it fails: Azure Bastion is a fully managed jump host that provides secure, browser-based RDP/SSH connectivity to the VM without exposing public IPs. It still requires a human administrator to interactively sign in and manually perform the installation, which directly contradicts the requirement for an automated, zero-touch deployment where the app is installed during VM provisioning.

A managed identity assigned to the VM without any extensions.

Why it fails: A managed identity assigns the VM an Microsoft Entra ID identity used by applications to authenticate to Azure resources such as Key Vault, Storage, or SQL — for example, to retrieve a secret. Without an accompanying extension or bootstrap mechanism, the identity alone does nothing to execute the installation script. The app still needs a process to run, and that process requires a scripting or orchestration layer.

An availability set so the VM comes online faster during provisioning.

Why it fails: An availability set controls the physical placement of VMs across fault and update domains to safeguard against hardware failures or maintenance downtime. It has no bearing on the VM's provisioning speed, nor does it carry any payload to install software; it purely affects resiliency topology. Therefore, it cannot contribute to installing the required application.

A new storage account access key

Why it fails: Regenerating an access key grants full control over the entire storage account and cannot be scoped to one container or time-limited, so it fails the six-hour, single-container requirement and still shares a key. Keys suit long-lived service-to-service authentication where per-request revocation and granular scope are unnecessary.

A management group assignment

Why it fails: Management groups organise subscriptions for policy and RBAC inheritance; they grant no blob data access. It tempts because RBAC scopes seem relevant, but a management group assignment would be correct for governing many subscriptions, not issuing a six-hour container-scoped SAS token.

A private endpoint for the contractor

Why it fails: A private endpoint only provides private IP connectivity to the storage account over a virtual network; it grants no upload permission and cannot be time-limited to six hours. Private endpoints suit restricting public network exposure for resources already authorised via other mechanisms, not issuing temporary write access to an external contractor.

A storage account access key, because it can be limited to one container by policy.

Why it fails: A storage account access key grants full administrative access to the entire storage account, including all containers, blobs, tables, queues, and the ability to regenerate keys or change firewall settings. You cannot scope an account key to a single container via policy; any key-based connection string or signed request built from the key bypasses fine-grained permissions. Rotating the key to revoke the contractor would also break access for any other applications using that key, and the key itself does not have a native expiration, making it a poor fit for temporary access.

Anonymous public access on the container, because it is the easiest way to time-limit access.

Why it fails: Anonymous public access on a container does not support time-limited access at all; the container remains publicly readable (or writable, if configured) until you manually remove the anonymous permission, and you cannot set an expiration date. Even if you changed the access level temporarily, the ACL applies to everyone on the internet, so it is not a scoped credential for a specific contractor. Unlike a SAS token, anonymous access also cannot be revoked mid-session without re-configuring the container's public access setting, and it offers no audit trail of who used it.

Azure RBAC on the storage account only, because RBAC automatically expires after a few hours.

Why it fails: Azure RBAC assignments on the storage account do not automatically expire after a few hours; expiration requires an external governance mechanism like Azure PIM (Privileged Identity Management) with a time-bound activation, which is not inherent to RBAC itself. Even with PIM, RBAC grants access by Microsoft Entra ID identity, so the contractor would need to authenticate as a user or service principal, not just present a token. Scoping RBAC to the storage account level would also grant broad control over all containers and settings—far more than the contractor's upload/download needs—whereas a SAS with a stored access policy can be confined to a single container with precise actions.

The storage account key, because it is the simplest way to authenticate an application securely.

Why it fails: Using the storage account key fails because the key is a shared secret that must be stored in application settings or configuration, directly violating the requirement to avoid keys or secrets. It also grants full access to the entire storage account, including all containers and blobs, rather than least-privilege access to just the target container. The key must be manually rotated, and any leak exposes the whole account, whereas a managed identity has no persistent secret to steal.

A shared access signature embedded in the app settings, because SAS is the same as managed identity.

Why it fails: A shared access signature (SAS) is still a secret token that must be embedded in app settings, so it does not satisfy the no-secrets requirement. Unlike a managed identity, a SAS is not tied to an Microsoft Entra ID identity; it is a cryptographic key that grants access based on the token's signature and expiry. It also needs to be regenerated and rotated over time, and if it is exposed, an attacker can use it until it expires. A managed identity, by contrast, is backed by Microsoft Entra ID and needs no stored credential in the application.

An anonymous public container with write access disabled on the account.

Why it fails: Anonymous public container access does not provide any authenticated write capability; disabling write access on the container means the web app cannot upload images at all. It would allow unauthenticated public read access to blobs, which is a severe security exposure and far beyond the minimal permissions needed for an application to upload images. The scenario requires controlled, authenticated access, which cannot be achieved with public containers, regardless of write settings.

Service endpoint on the subnet plus public DNS, because the storage account will expose a private IP automatically.

Why it fails: A service endpoint on the subnet extends the subnet's network identity to the storage service and routes traffic over the Azure backbone, but the storage account continues to be reachable only via its public endpoint. The service does not acquire a private IP address in your VNet; enabling the endpoint merely adds an effective route for the service's public IP range from the subnet. Public DNS still resolves the storage account name to the public IP, so the premise that a private IP appears automatically is incorrect.

Network security group rules only, because they can force traffic to use private addressing.

Why it fails: Network security group rules are stateful packet filters applied at the subnet or network interface level; they can permit or deny traffic but cannot provision a private endpoint or modify DNS name resolution. Even if you create an NSG rule that allows all outbound traffic, the storage account still resolves to its public endpoint IP. NSGs have no mechanism to redirect or translate that destination to a private address, so they cannot alone make storage accessible via a private IP.

Storage account firewall rules with Allow trusted Microsoft services, because that gives a private address path.

Why it fails: Storage account firewall rules, even with 'Allow trusted Microsoft services' enabled, operate as access-control filters on the public endpoint. They do not assign a private IP address to the storage account in the VM's virtual network, nor do they alter DNS resolution so the account name maps to a private address. The VM would still traverse the public endpoint (or Microsoft's backbone via the trusted-service exception) using the storage account's public IP, not a private IP inside the VNet.

ReadOnly lock, because it prevents all changes and keeps resources fully protected.

Why it fails: ReadOnly is too restrictive because it blocks write operations as well as deletions. The scenario says administrators must still be able to update settings, so a ReadOnly lock would prevent legitimate management tasks and break the requirement.

No lock is needed because Azure RBAC already prevents deletion by default.

Why it fails: Azure RBAC does not block deletion by default; it only grants or denies permissions based on assigned roles. A user holding a role such as Contributor or Owner has the authority to delete resources unless an explicit deny assignment is in place. Resource locks function as an authoritative restriction that overrides RBAC for all users, protecting the resource group from accidental deletion even when administrators need update permissions.

Management group lock, because all changes in the tenant must be blocked centrally.

Why it fails: Management groups are for organizing subscriptions and applying governance at a high level, but the question is about protecting one resource group. A management group lock is not the right concept here and would be far broader than required.

Delete the policy assignment from corp-root and recreate it later.

Why it fails: Deleting the assignment would remove enforcement for the entire management group, not just the requested resource group. That would create a governance gap and allow other noncompliant resources to slip through during the merger period.

Move rg-merger01 to a separate subscription so the policy no longer applies.

Why it fails: Moving the resource group is disruptive and unnecessary. It also does not solve the policy control problem in the simplest way. Azure Policy exemptions are specifically designed for temporary, scoped exceptions without restructuring the environment.

Change the policy effect to Audit so the resources can remain noncompliant.

Why it fails: Changing the policy effect to Audit would alter the enforcement behavior for every resource under the corp-root management group, not just rg-merger01. Audit mode only logs noncompliance without blocking or remediating, so it would silently allow all tag violations across the entire hierarchy, creating a broad governance gap. This is a disproportionate, global change when a scoped exemption is the intended mechanism for a temporary, single-resource-group exception.

ReadOnly lock at the resource group scope.

Why it fails: A ReadOnly lock at the resource group scope blocks all write operations, not just deletes. This means common production maintenance actions such as resizing a VM, adding or updating tags, applying a new deployment, or writing blobs to the storage account would fail with a conflict error. It is intended for situations where the configuration must be frozen for audit or compliance, but it is too restrictive when routine configuration changes still need to be made.

Azure Policy assignment that denies all delete requests.

Why it fails: An Azure Policy assignment denying delete requests would prevent accidental deletions and allow configuration changes, but it is a continuous governance mechanism, not a direct operational control. Policies are designed for broad, ongoing compliance enforcement rather than temporary removal and re-application for specific maintenance windows. This option is tempting because policies are excellent for enforcing organisational standards, such as preventing resource deletion across subscriptions or resource groups, ensuring continuous adherence to security or cost management rules.

Apply the lock only to individual virtual machines.

Why it fails: Locking only the individual VMs would leave the storage account and any other resources in the resource group unprotected from accidental deletion. Because resource locks are inherited only from parent scopes, a VM-level lock does not extend to sibling resources, and every VM would need a separate lock assignment — including any future VMs added later. This approach is inconsistent and operationally fragile compared with a single CanNotDelete lock at the resource group scope, which inherits to all current and future child resources.