Storage Account practice questions

Interactive logins: Storage account access keys

Why wrong: 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 Azure AD-based access should be used instead.

Automated backups: User delegation SAS

Why wrong: A user delegation SAS is inherently user-oriented because it is signed with an individual Azure AD 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 wrong: A system-assigned managed identity is tied to both a single Azure resource and a single Azure AD 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 wrong: 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 wrong: 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.

Blob SAS token

Why wrong: A blob SAS token is for blob data, not for mounting an Azure Files SMB share.

Network security group rule

Why wrong: NSG rules control traffic flow, but they do not authenticate file-share access.

Azure resource lock

Why wrong: A lock protects the storage account from changes, but it does not help clients mount the share.

A CanNotDelete lock was applied to the storage account.

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: A user-assigned managed identity is an Azure Active Directory 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.

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

Why wrong: 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 wrong: A managed identity assigns the VM an Azure Active Directory 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 wrong: 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 storage account access key, because it can be limited to one container by policy.

Why wrong: 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 wrong: 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 wrong: 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 Azure AD 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 wrong: 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 wrong: 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 Azure AD 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 Azure AD and needs no stored credential in the application.

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

Why wrong: 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.

A private endpoint for the storage account.

Why wrong: A private endpoint would give the storage account a private IP and usually changes the access pattern away from the public endpoint.

A site-to-site VPN connection to the storage account.

Why wrong: VPN connects networks, not individual PaaS service access paths, and is unnecessary here.

An application security group assigned to the storage account.

Why wrong: Application security groups are for NICs in NSG rules, not for securing Azure Storage.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

BlobStorage, because it is optimized only for block blob workloads.

Why wrong: BlobStorage accounts are limited to blob data and do not provide the broader feature set required for Azure Files shares. They are not the right choice when the application needs multiple storage services and lifecycle management across the account.

General-purpose v1, because it can host any storage object type.

Why wrong: General-purpose v1 is older and lacks many modern storage capabilities used in current Azure designs. It is not the recommended choice for lifecycle policies and the full range of storage features expected in this scenario. The requirement calls for the newer general-purpose model.

BlockBlobStorage, because it is the best choice for any application that stores files.

Why wrong: BlockBlobStorage is optimized for premium block blob scenarios, but it does not provide Azure Files support. The question explicitly requires both blob containers and a file share in the same account, so this account kind is too specialized for the workload.

A system-assigned managed identity on each VM.

Why wrong: System-assigned managed identities are tied to an individual VM resource. They disappear when that VM is deleted and cannot be directly reused by future VMs, which makes them a poor fit for shared identity reuse.

A storage account shared key embedded in the application settings.

Why wrong: A storage account shared key is a static credential, not an Azure identity. Embedding it in application settings means the key must be stored, protected, and rotated manually, and it exposes the entire storage account if leaked. Since the requirement is to avoid any credential management and use a reusable Azure identity, this option fails because it introduces a secret that must be handled and does not scale across VMs as an identity.

A service principal credential stored in a Key Vault secret.

Why wrong: A service principal can authenticate, but it still relies on a secret or certificate that must be managed. The requirement specifically asks for an identity that can be reused across VMs without creating another credential.

An account SAS signed with the storage account key

Why wrong: An account SAS is signed with the storage account key but grants access to one or more storage services and permits account-level operations, not just container-scoped uploads. This is broader than needed for a single blob container and still relies on the shared account key, so rotating that key invalidates all SAS tokens derived from it. It also lacks support for Microsoft Entra identity-based authorization, so it fails the security requirement of avoiding key-based credentials.

A service SAS signed with the storage account key

Why wrong: A service SAS is scoped to a single resource such as a container or blob, but it is signed with the storage account shared key. This means the signer must possess the account key, and if that key is rotated or compromised, the SAS is invalidated. It also cannot be revoked independently without re-signing, and it does not use Microsoft Entra identity-based authorization, so the principle of least privilege is still tied to a shared secret.

The storage account access key itself in a temporary script variable

Why wrong: Sharing the storage account access key outright grants unrestricted full access to all storage services, data, and even management operations in the account. It is a long-lived shared secret with no granular scoping, so placing it in a temporary script variable does not limit the contractor's access. Rotating the key later is disruptive and may break other applications, and the key cannot be revoked or audited at the container level, violating the principle of least privilege.