Managed Identity practice questions

Recreate the virtual machines before the policy can evaluate them.

Why wrong: There is no need to recreate or redeploy the virtual machines because Azure Policy's Modify effect, combined with a remediation task, is designed to update existing resources in place without downtime. Recreating a VM may also fail to add the desired tag unless your deployment template explicitly includes the tag, and the new VM would still be evaluated from scratch. Policy evaluation is continuous and covers all resources, regardless of whether they were created before or after the assignment, so recreation is an unnecessary and ineffective workaround.

Change the effect from Modify to Audit to trigger the tag operation.

Why wrong: Changing the effect to Audit is logically incorrect because Audit does not perform any write operation—it only compares the resource's current tags against the policy rule and generates a compliance result. If you switch from Modify to Audit, Azure Policy will report the resources as non-compliant but will never attempt to add the costcenter tag. This would solve the original problem (applying the tag) by removing the mechanism that could apply it, making the situation worse.

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.

Assign a system-assigned managed identity to each VM.

Why wrong: A system-assigned identity is bound to one VM, so it cannot be shared cleanly across multiple machines.

Create a storage account access key and place it in each VM's application settings.

Why wrong: Sharing storage keys increases risk and does not satisfy the requirement to avoid secrets.

Create a separate SAS token for each VM and rotate it manually.

Why wrong: SAS tokens are limited-time secrets and do not provide the shared, identity-based access pattern requested.

A system-assigned managed identity for the container group.

Why wrong: A system-assigned managed identity is tied to the container group's lifecycle: it is created with the resource and permanently deleted when the container group is removed. This means every new deployment gets a brand-new identity, breaking the ability to reuse a single, pre-provisioned identity across multiple container groups or future workloads. Even though it can pull from ACR when assigned AcrPull, the lack of reusability makes it inappropriate when the same identity must be consistent across deployments.

An ACR admin username and password stored in the container image.

Why wrong: Storing the ACR admin username and password inside the container image embeds long-lived secrets directly in the artifact, which is a severe security risk if the image is pushed to a public registry or shared. The admin account is intended for emergency break-glass access, not for routine automation, and it cannot be scoped to a single repository or container group. Rotating these credentials forces you to rebuild and re-push the image, creating operational overhead and violating the principle of avoiding credential management in code.

A shared access signature token passed as an environment variable.

Why wrong: A shared access signature token is still a secret in string form, and passing it as an environment variable exposes it to anyone who can inspect the container group's configuration or logs. SAS tokens are time-bound and require periodic regeneration, which adds management complexity and risks downtime if the token expires mid-deployment. Most importantly, SAS is not the native Azure identity-based authentication method for pulling from ACR, and using it would require additional docker login logic inside the container, defeating the goal of a secret-free, identity-driven pull.

Use a system-assigned managed identity on only one VM and copy its access token to the other two VMs.

Why wrong: A system-assigned managed identity is intrinsically bound to a single VM and is deleted when that VM is deleted, so using it on only one VM and copying its access token to the other two is not a viable shared identity. Access tokens are short-lived (typically under 24 hours) and must be continuously refreshed, which would force the other VMs to depend on the one source VM remaining alive. Furthermore, extracting and replaying tokens outside the intended resource violates Azure's token-handling model and creates a security risk, because the token is not scoped to the other VMs' identities and cannot be renewed without accessing the original VM's identity endpoint.

Store one application password locally on each VM and use it instead of Azure-managed identities.

Why wrong: Storing an application password locally on each VM reintroduces the exact credential-management burden that managed identities eliminate. Passwords must be securely stored, rotated, and protected on every VM, and a leaked or stale password becomes a shared secret that an attacker can reuse across all three systems. Azure-managed identities, by contrast, are backed by Azure Active Directory and require no static secrets on the VM, so this option fundamentally fails the requirement to rely on an Azure identity that persists independently of VM lifecycle.

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.

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 storage account access key

Why wrong: A storage account key is unrelated to Key Vault authentication and would require storing a long-lived secret on the VM. It does not solve the requirement to avoid usernames, passwords, or client secrets. It is also broader than necessary and weakens security because the key can be reused outside the VM if exposed.

A service endpoint on the VM subnet

Why wrong: A service endpoint affects network routing and service access control, not identity authentication. It can help a VM reach certain Azure services securely over the Azure backbone, but it does not provide the VM with a credential-free identity. Key Vault access still needs an authentication method such as managed identity.

A user account in Entra ID with a stored password

Why wrong: A user account with a password still requires the VM or application to store a credential, which violates the requirement. It also creates extra operational work for password management and rotation. Managed identities are the Azure-native way to eliminate this problem for a single VM.

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.

az login with a username and password.

Why wrong: A username and password requires credential storage and is not appropriate for secretless automation.

Connect-AzAccount with device code authentication.

Why wrong: Device code authentication is interactive and not suitable for unattended nightly automation on a VM.

An app registration secret stored in a PowerShell variable.

Why wrong: A secret in a variable is still a secret on the machine and violates the stated security requirement.

A shared local account on the VM

Why wrong: A shared local account resides in the VM's local Security Accounts Manager (SAM) database and grants interactive, RDP, or SSC logon to the operating system. It is not recognized by Azure AD and cannot authenticate to Azure control plane APIs such as resource creation endpoints. While a script running under that local account might have OS-level permissions, every Azure REST call would still require an Azure credential (like a managed identity or service principal). Thus, a local account only addresses OS access, never Azure-level authorization.

An Azure Policy exemption

Why wrong: An Azure Policy exemption is a governance construct that excludes specific resources or scopes from the evaluation of certain policy definitions. It does not create an identity, modify the VM's authentication context, or grant any permissions to the script. The Azure policy engine evaluates resource properties for compliance after resources are deployed; it is never involved in the authentication flow that a script uses to create resources. Therefore, an exemption cannot enable a script to authenticate or provision resources—it only skips compliance checks for existing resources.

A public IP address on the VM

Why wrong: A public IP address is a network resource that enables inbound and outbound internet connectivity for the VM. It does not carry any identity, token, or shared secret, and it cannot be used to authenticate to Azure Resource Manager. Even if the script reaches Azure endpoints over the public IP, it still lacks a security principal to prove its authorization. Therefore, a public IP has no bearing on the script's ability to create resources.

Apply a CanNotDelete lock to the production resource group.

Why wrong: A CanNotDelete lock protects the resource group from accidental deletion, but it does not affect tag assignment or modification. Because the lock only restricts delete operations, users can still create resources without the required CostCenter tag, and existing resources remain untagged. Therefore it fails to enforce any tagging standard and provides no cost-tracking assurance.

Assign Contributor on the subscription and require teams to enter the tag manually.

Why wrong: Assigning Contributor at the subscription grants broad management rights, but it leaves tagging entirely to manual user discipline. This approach cannot prevent missing or incorrectly spelled tags, and there is no automated way to detect or correct drift, so finance teams will see inconsistent cost data. The role is also overly permissive because the task only needs tag enforcement, not full management access.

Set the tag on the management group and expect all resources to inherit it automatically.

Why wrong: Tags placed directly on a management group are metadata for that management group only; they are not inherited by subscriptions or resources. Azure Policy must be explicitly assigned with an appropriate effect to achieve tag propagation, and without such a policy the CostCenter tag will not appear on any newly created resource. Expecting automatic inheritance from a management group tag is a common misconception and will leave resources untagged.

A system-assigned managed identity on one of the VMs

Why wrong: A system-assigned managed identity is permanently tied to the specific VM on which it is enabled, so it cannot be replicated or shared with any other resource. If you attempt to use only one VM's system-assigned identity for both VMs, the second VM is issuing requests with a different principal, not the same identity. Additionally, this identity is deleted automatically when the VM is deleted, making it unsuitable when the identity must outlive a single VM or be used uniformly across several VMs.

A service principal with a client secret stored on each VM

Why wrong: A service principal with a client secret stored on each VM forces you to place and manage secrets on every machine, which conflicts with the requirement to avoid stored credentials. Each VM would need its own copy of the secret, creating distribution, rotation, and protection overhead, and a leaked secret compromises the shared identity. While this approach does technically work for authentication, it reintroduces the exact operational and security risks that managed identities are designed to eliminate.

A certificate uploaded to each VM and used for Azure sign-in

Why wrong: Uploading a certificate to each VM and using it for Azure sign-in still requires you to distribute, renew, and protect private key material on every VM, creating significant lifecycle management overhead. Unlike a managed identity, the certificate-based approach is not automatically integrated with Azure's IMDS endpoint, so you must custom code the authentication flow and handle certificate expiration manually. The certificate also represents a stored credential on each VM, which does not satisfy the no-stored-credentials requirement.

Reassign the policy at the resource group scope only.

Why wrong: Changing the assignment scope to resource group level does not fix the core problem: existing resources are already in scope but were never evaluated for remediation. Azure Policy only applies modify actions during create/update operations or when a remediation task is run; simply moving or reassigning the policy does not retroactively process existing VM tags. The correct action is to keep the current scope and remediate, not to narrow the scope.

Switch the policy effect to AuditIfNotExists.

Why wrong: AuditIfNotExists is a different effect that only reports compliance by checking whether an audit resource exists; it cannot modify tags or any other property of the VM. Switching to AuditIfNotExists would drop the modify operation entirely, making the policy even less capable of adding the missing tag. Since the stated goal is to actually remediate existing VMs, this change would not achieve the desired outcome and would instead only log non-compliance.

Manually tag only the newest virtual machines.

Why wrong: Manually tagging only newly created VMs ignores the bulk of existing non-compliant resources and creates a maintenance burden that is error-prone and inconsistent. More importantly, manual tagging does not leverage Azure Policy's governance enforcement, so there is no assurance that the tag standard is consistently applied across all VMs. A remediation task is the only method that systematically uses the policy assignment's identity to bring existing VMs into compliance without ad hoc human intervention.

Store the storage account key in an environment variable on the VM

Why wrong: Storing the storage account key in an environment variable introduces a long-lived symmetric secret directly onto the VM. The key grants full data-plane access to every container, queue, table, and file in the entire storage account, far exceeding the requirement to upload only to one blob container. Additionally, environment variables are visible to any process or user with access to the VM, making the key vulnerable to exfiltration and requiring manual rotation instead of using Azure AD-backed identity.

Create a service SAS with write permission on the storage account

Why wrong: A service SAS with write permission at the storage account level creates a delegation token scoped to the entire Blob service, meaning the bearer can write to any container in the account, not just the intended one. Even if the SAS is designed for a single service, it is still a shared secret that must be embedded in the app's configuration or URL. Unlike managed identity, a SAS cannot be automatically rotated by Azure AD and is harder to revoke per-resource without invalidating all tokens sharing the same policy.

Assign Contributor on the storage account to the VM's system-assigned identity

Why wrong: Contributor on the storage account is an Azure Resource Manager (ARM) role that governs control-plane operations such as creating, deleting, or updating the storage account itself. It does not include data-plane permissions, so the VM's managed identity would still be unable to upload blobs to a container. Furthermore, even if data access were included, the account-wide scope violates least privilege because it grants management rights to the entire storage resource instead of limiting access to the specific container.

Create an account SAS token and store it in the VM's application settings.

Why wrong: An account SAS is a shared-signature URL that grants delegated access to storage services, but generating it requires the storage account key, which is a shared secret. Storing that SAS token in the VM's application settings keeps a long-lived credential on disk and in configuration files, creating a serious exposure risk if the VM is compromised; the SAS also typically has a far wider scope than the single container unless carefully constrained. Microsoft Entra ID with a managed identity is the recommended secure authentication method because it eliminates long-lived shared secrets and allows fine-grained, revocable data-plane RBAC.

Assign Reader on the storage account so the VM can reach the container securely.

Why wrong: Reader only authorizes 'read' actions against the storage account resource itself—for example, viewing account properties, keys, and configuration—and provides no access to the blob data plane. Uploading an invoice requires data-plane permission, which is granted by a role like Storage Blob Data Contributor on the container, not by the Reader role on the account. Thus, assigning Reader would let the VM inspect the account metadata but still fail to perform the required upload, and it also introduces unnecessary read access to account-level settings.

Grant Storage Account Contributor at the subscription scope so the app can manage all storage resources.

Why wrong: Storage Account Contributor is a management-plane role that lets the principal manage storage account settings, regenerate access keys, and configure networking across every storage account in the subscription. It does not itself grant data-plane permissions to write blobs, since blob operations require an Azure RBAC data-plane role such as Storage Blob Data Contributor. Applying this at subscription scope massively exceeds the required blasting radius and violates least privilege, as the app would be able to alter storage infrastructure far beyond its intended invoice container.

A storage account access key

Why wrong: A storage account access key is a static shared secret that grants full control to the entire storage account, including all blobs, tables, and queues, with no ability to scope privileges to just the required container. The application must securely store the key somewhere (e.g., environment variables, config files, or a vault) and rotation requires modifying the application, increasing operational overhead and exposure risk if leaked.

A shared access signature (SAS) token

Why wrong: A shared access signature (SAS) token limits permissions and validity, but it is still a credential that must be generated, embedded in the connection string or URL, and then stored by the application. It also has an expiry, so the application must handle token renewal, often by requesting a new token from a service that itself possesses the account key—reintroducing secret management that managed identity eliminates.

A local administrator account on the VM

Why wrong: A local administrator account on the VM only authenticates the user to the operating system and has no meaning in Azure Storage's authentication context. Azure Blob Storage does not recognize any VM-local user or group, so this credential cannot be used to request tokens or authorize access to blob resources; it is an entirely unrelated access-control domain.

A user-assigned managed identity

Why wrong: A user-assigned managed identity is a standalone Azure AD identity that can be assigned to multiple Azure resources, including the VM. While it also enables secretless access and works well when you need the same identity across several resources, it is not automatically removed when a single VM is deleted—its lifecycle is independent. For a single VM that needs to read storage without credentials, a system-assigned identity is a better fit because it avoids leaving orphaned identities behind.

A storage account access key

Why wrong: A storage account access key is a shared secret that grants full administrative access to the entire storage account. It must be stored somewhere (in code, config, or Key Vault), manually rotated, and protected as a high-privilege credential. Using it violates the goal of secretless access, since any leak can compromise all data in the account, and it lacks fine-grained, per-application RBAC scoping.

A shared access signature

Why wrong: A shared access signature (SAS) is a delegated URI that grants time-limited and permission-scoped access to specific storage resources. Although it avoids exposing the account key, a SAS token is still a credential that must be generated, securely distributed, and managed—including expiration and revocation. For a VM-based application that should read storage without handling secrets, a SAS introduces unnecessary token lifecycle management and does not provide an automatic, identity-based authentication mechanism.

Stop

Why wrong: Stop (deallocate) releases the compute resources and disassociates the VM from its current host, but it does not guarantee placement on a new host when you start it again. Azure may place the restarted VM on the same original host if that host is still healthy and has capacity, depending on resource availability and placement logic. Therefore, stopping alone provides no deterministic way to force a migration to a different physical host, and it also causes downtime without addressing the root cause of the host failure.

Restart

Why wrong: Restart is insufficient because it only reboots the guest operating system and does not change the underlying physical host. While a restart can clear transient OS or application crashes, it cannot repair a degraded or failed host, network controller, or storage path that Azure might be experiencing. The VM's current placement on the problematic host remains unchanged, so any host-level faults will likely persist after the reboot.

Capture

Why wrong: Capture is inappropriate because it is used to create a reusable VM image from a generalized (sysprepped) VM, not to relocate an existing VM to a new host. Running capture requires you to deallocate the VM first, marks it as generalized, and the original VM is typically deleted after the image is created. This destroys the current VM's operational state and does not preserve its running configuration in place, making it completely unsuitable for resolving host-level issues while keeping the VM live.

Storage account access key, because it is the simplest authentication method.

Why wrong: While using an access key is often described as the simplest authentication method, it introduces significant secret-management overhead and security risk. The storage account key grants full, unrestricted control over the entire storage account—including blob, container, and account-level operations—so a key placed on the VM becomes a high-value stealable secret. To use it, you must securely inject the key into configuration or environment variables and plan for periodic rotation, making it far less secure and more operationally costly than identity-based access.

Shared access signature, because it always removes the need for identity management.

Why wrong: A shared access signature (SAS) is a bearer token that delegates limited access for a specific duration, but it does not remove identity management—it replaces it with token generation, permission scoping, expiry tracking, and often stored access policy administration. More importantly, a SAS is not tied to the VM at all; the URL or token can be copied to any client, so it cannot act as a VM-integrated authentication mechanism. The claim that it 'always' removes identity management is false because you must still design, issue, and manage the SAS lifecycle and its permissions.

User-assigned managed identity, because it is deleted automatically with the VM.

Why wrong: A user-assigned managed identity is a standalone Azure AD identity that exists independently of any VM, so it is not automatically deleted when a particular VM is removed. It can be assigned to multiple VMs or other Azure resources, which makes it reusable but also means its lifecycle must be actively managed as a separate resource. This is the opposite of a system-assigned identity, whose lifecycle is directly coupled to the VM it belongs to, so the statement in this option is incorrect.