Managed Identity practice questions

A shared local account on the VM

Why wrong: A local account helps with operating system access, but it does not securely authenticate to Azure APIs.

An Azure Policy exemption

Why wrong: Policy exemptions affect governance rules, not authentication for scripts or Azure resource creation.

A public IP address on the VM

Why wrong: A public IP affects network reachability, but it does not replace Azure authentication credentials.

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 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.

Stop

Why wrong: Stopping the VM does not guarantee that it will be placed on a new host.

Restart

Why wrong: A restart keeps the VM on the same host in many cases and does not explicitly solve host-level issues.

Capture

Why wrong: Capture creates an image and is not the correct action for moving the current VM to a new host.

A system-assigned managed identity.

Why wrong: This identity is tied to one resource instance and is removed when that resource is deleted.

A service principal with a client secret stored in Key Vault.

Why wrong: This still depends on a credential and introduces secret rotation and operational overhead.

A shared access signature token.

Why wrong: A SAS token is limited to certain data scenarios and is not a general reusable Azure identity.

Service principal with a client secret stored in an app setting.

Why wrong: A client secret is a stored credential and requires ongoing rotation and protection outside Azure identity management.

Shared administrator username and password stored in a Key Vault secret.

Why wrong: This still depends on a password-based credential and is not the preferred secret-free Azure identity approach.

SAS token generated once and reused indefinitely by both resources.

Why wrong: A long-lived SAS token is a secret and is not a robust identity choice for ongoing automation.

Assign a user-assigned managed identity to the VM so it can be shared later.

Why wrong: A user-assigned identity works, but it is not the simplest choice when only one VM needs access. It is designed to be reused across multiple resources and managed independently from the VM lifecycle.

Create a service principal and store its client secret in the VM configuration.

Why wrong: A service principal with a stored secret violates the requirement not to keep credentials on the VM. It also increases operational risk because the secret must be protected and rotated manually.

Use a shared access signature in the startup script to authenticate to Key Vault.

Why wrong: A SAS token is for storage access, not for authenticating to Azure Key Vault. It also introduces time-bound secret handling, which the scenario explicitly wants to avoid.

Storage account access key in an application setting

Why wrong: An access key is a long-lived secret, so it violates the requirement to avoid stored credentials.

Shared access signature token saved on the VM

Why wrong: A SAS token is still a secret and must be stored and rotated, so it does not meet the requirement.

Anonymous public access to the container

Why wrong: Anonymous access removes authentication, but it is not appropriate for a secure upload scenario.

A user-assigned managed identity with Blob Data Reader permissions on the storage account.

Why wrong: A user-assigned identity can be reused, but it does not disappear when the App Service is deleted, and Reader does not allow uploads.

A shared access signature generated from the storage account key.

Why wrong: A SAS derived from the account key still depends on shared key access and introduces a secret that must be managed.

A storage account access key stored in an application setting.

Why wrong: An access key is a long-lived secret and directly violates the no-secrets requirement in the scenario.

Storage account shared key, because it is the preferred credential when you want to avoid passwords.

Why wrong: A shared key is a secret credential, so it does not meet the no-secrets requirement.

Basic authentication with a storage account name and password, because Azure Storage supports that model directly.

Why wrong: Azure Storage does not use basic username and password authentication for blob access.

Anonymous public access, because it lets the VM read blobs without any authentication at all.

Why wrong: Anonymous access is only suitable for public content and is not a secure identity-based approach.

Reassign the policy at the resource group scope only.

Why wrong: Changing scope might not be necessary and does not address the missing remediation action. The issue is that existing resources need to be processed, not merely reassigned.

Switch the policy effect to AuditIfNotExists.

Why wrong: AuditIfNotExists reports compliance status but does not change resources. It would not add the missing tag to the existing VMs.

Manually tag only the newest virtual machines.

Why wrong: Manual tagging is inconsistent and does not scale. It also bypasses the governance objective of using policy to remediate existing noncompliant resources.

A user-assigned managed identity

Why wrong: A user-assigned identity can be shared, but it is not automatically removed with the VM.

A storage account shared access signature

Why wrong: A SAS token is for data-plane access, but it is still a credential that must be managed and protected.

A local administrator account with a strong password

Why wrong: A local password introduces secret management overhead and does not meet the credential-free access requirement.

Assign two separate policies manually to each subscription and skip remediation.

Why wrong: This fragments governance across subscriptions and makes reporting harder. It also does not provide a single consolidated compliance view at the management group level.

Assign Contributor to the management group so administrators can fix any noncompliant resource manually.

Why wrong: Contributor is an authorization role, not a governance control. It neither enforces allowed regions nor automatically identifies or fixes missing tags.

Apply a CanNotDelete lock at the management group scope to prevent drift.

Why wrong: A lock does not enforce tags or allowed locations. It only affects delete or write behavior, depending on the lock type, and is the wrong tool for policy compliance.

Store the storage account access key in both app settings and runbook variables.

Why wrong: Account keys are broad secrets that grant more access than needed and create secret-rotation and exposure risks.

Assign Contributor on the storage account because it automatically includes all blob data permissions.

Why wrong: Contributor manages the resource, but it does not provide the required data-plane permissions for blob access.

Use a shared SAS token without an expiration date for both workloads.

Why wrong: A long-lived SAS token is not least privilege and introduces a credential that can be leaked or reused.

Store the ACR admin account password in a container environment variable.

Why wrong: Embedding a password in configuration violates the requirement to avoid stored credentials.

Use a SAS token for the container image reference.

Why wrong: SAS tokens are not the normal authentication method for pulling private container images from ACR.

Place the registry in the same resource group as the container group.

Why wrong: Resource group placement does not authorize access to a private registry.

Store the storage account access key in a script variable.

Why wrong: Embedding an access key in a script variable still leaves a secret inside automation content. That violates the security requirement and creates a high-risk credential-management problem.

Create a separate local administrator account for the script to use.

Why wrong: A local administrator account does not solve secret storage, and it does not provide a reusable Azure authentication mechanism for Blob Storage. It also increases operational overhead and credential exposure.

Embed a SAS token directly in the Bicep parameters file.

Why wrong: A SAS token is still a secret, and placing it in a parameters file exposes it to anyone who can read the deployment artifact. That conflicts with the requirement to avoid secrets in templates and scripts.

Azure portal manual creation of each VM.

Why wrong: Manual portal steps are difficult to repeat consistently and are not source-controlled.

An Azure Policy assignment at the subscription level.

Why wrong: Policy can enforce compliance, but it does not create a full repeatable deployment from code.

An Azure Monitor alert rule that triggers VM creation.

Why wrong: Alerts notify on conditions; they are not the right mechanism for controlled infrastructure deployment.

Recreate the virtual machines before the policy can evaluate them.

Why wrong: Recreation is unnecessary because remediation can update existing resources in place when permissions and assignment are correct.

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

Why wrong: Audit only reports noncompliance; it does not change resource state.

Use a system-assigned managed identity on one VM and clone it.

Why wrong: Incorrect. System-assigned identities are tied to one VM lifecycle and are not reusable across rebuilds.

Store a service principal secret in the script configuration.

Why wrong: Incorrect. Storing secrets on disk violates the requirement and creates a credential management burden.

Use a shared access signature to authenticate to Azure Resource Manager.

Why wrong: Incorrect. SAS is for storage access scenarios, not for authenticating to Azure management APIs.