CCNA Manage Azure Identities and Governance Questions

Assigning Contributor at the management group scope grants permissions to all subscriptions under that management group, including Prod-Sub, which violates the requirement that the administrator must have no permissions in Prod-Sub.

The Owner role at the resource group scope in Dev-Sub grants full access, including the ability to assign permissions, which exceeds the requirement to only create resource groups. Additionally, it does not prevent the administrator from gaining permissions in Prod-Sub through inheritance if the management group hierarchy includes both subscriptions.

Assigning Reader at Prod-Sub scope grants read-only permissions in Prod-Sub, violating the requirement that the administrator must have no permissions in Prod-Sub. Additionally, assigning Contributor at the tenant root group would grant Contributor access to all subscriptions, including Prod-Sub.

Assigning Contributor at the management group scope grants permissions to all subscriptions within that management group, not just the rg-finance-app resource group, violating the requirement to restrict access to only that resource group.

Assigning the Contributor role at the subscription scope grants permissions to all resource groups in the subscription, not just rg-finance-app, violating the requirement to restrict access to only that resource group.

Assigning the Contributor role at each individual resource would be overly granular and inefficient; it violates the principle of least privilege by requiring separate assignments for every resource, and it does not cover future resources added to the group.

System-assigned managed identity is tied to a specific Azure resource (e.g., a VM) and cannot be used by an on-premises build server, which is outside Azure.

User-assigned managed identities are tied to Azure resources (e.g., VMs, App Services) and cannot be used by an on-premises build server, which is outside Azure. The question requires an identity that works for an on-premises resource, so a service principal (app registration) is needed.

Azure Storage access keys are used to authenticate to Azure Storage services, not to authenticate an on-premises build server to Azure in general. They do not support authentication without a human account password in the context of Azure AD authentication.

The user already has Contributor permissions via group membership on the resource group; changing the scope to subscription would grant broader access but does not address the token refresh issue causing the 'access denied' message.

Deleting and recreating the resource group would remove all resources and is an extreme, unnecessary action. The issue is a stale access token, not a problem with the resource group itself.

Assigning Owner directly to the user bypasses group-based management and violates the principle of least privilege, but more importantly, it does not address the root cause: the user's access token has not yet been refreshed to include the new group membership.

Azure RBAC with a Contributor role grants broad permissions to create and manage resources but does not restrict which regions can be used. It allows resource creation in any region, not just East US and West US.

A resource lock at the subscription level prevents deletion or modification of all resources, but does not restrict resource creation to specific regions; it blocks all changes indiscriminately.

Tag requirements in Azure RBAC cannot restrict resource deployment by region; they only enforce tagging on resources, not control which regions are allowed.

A resource lock prevents deletion or modification of the storage account, but it does not override the policy that denies public network access. The lock cannot exempt the account from the policy effect.

Policy assignments with higher priority do not override existing policy definitions; Azure Policy uses 'deny' effects that cannot be bypassed by priority. A second assignment would still enforce the deny effect on the storage account.

A custom RBAC role controls permissions for users, not policy enforcement. It cannot override a deny policy at the management group scope, so it would not allow the storage account to remain public.

Assigning the Owner role at the tenant root scope grants full administrative access to the entire Azure AD tenant, including all subscriptions, which would allow the user to create resource groups in both Dev-Sub and Prod-Sub, not just Dev-Sub.

The Reader role only allows read access, not the ability to create resource groups. The user needs write permissions to create resource groups.

Assigning Contributor at the management group scope that contains both subscriptions would grant the user Contributor permissions on both Dev-Sub and Prod-Sub, allowing resource group creation in both, which violates the requirement to restrict creation to Dev-Sub only.

Resource locks prevent deletion or modification of resources, but they do not enforce tagging or add default tags to new resources.

Management group locks prevent deletion or modification of resources at the management group scope, but they do not enforce tagging or add default values to new resources.

Custom RBAC roles control permissions (who can do what) but cannot enforce tag values or automatically add missing tags during resource deployment.

Assigning RBAC roles directly to each contractor user account requires manual updates when contractors change, which does not meet the requirement for automatic access updates based on membership changes.

Management groups are used for organizing subscriptions and applying governance policies, not for managing user access to resources. They do not support direct role assignments for user access control.

Resource locks prevent accidental deletion or modification of resources, but they do not automate role assignment updates based on group membership changes. The question requires dynamic access updates, which resource locks cannot provide.

Reassigning the policy at the resource group scope does not retroactively apply the policy to existing resources; it only affects new resources in that scope. The issue is that existing VMs are noncompliant, and reassignment does not trigger remediation.

A resource lock prevents accidental deletion or modification of resources, but it does not apply or enforce Azure Policy assignments. It cannot bring existing noncompliant resources into compliance.

Moving VMs to another resource group and back does not trigger policy evaluation or remediation; policies are evaluated on resource creation or update, not on move.

Azure RBAC does not cascade from a resource to other resources in the same subscription; each resource requires its own role assignment unless inherited from a higher scope.

Role assignments at management group scope apply to all subscriptions within that management group, not just the subscription where it was created.

A role assignment at resource group scope is narrower than subscription scope because subscription scope includes all resource groups and resources within that subscription, whereas resource group scope only applies to resources within that specific group.

Azure Policy evaluates existing resources automatically; recreating VMs is unnecessary because the Modify effect with a remediation task can update tags on existing resources without redeployment.

The Modify effect already triggers the tag operation; changing to Audit would only evaluate compliance without applying tags, failing to update existing resources.

The Owner role grants full access to all resources, including the ability to create and modify resources, which violates the requirement that the user should not be able to create or modify resources.

The Contributor role allows creating and modifying resources, which violates the requirement that the user cannot create or modify resources.

The User Access Administrator role grants permissions to manage user access to Azure resources, including the ability to assign roles, which allows creating or modifying resource permissions, not just viewing cost data.

System-assigned managed identities are tied to a specific VM instance and cannot be cloned or reused across rebuilt VMs; each new VM would get a new identity, breaking the requirement for a consistent identity.

Storing a service principal secret in the script configuration violates the requirement of not storing secrets on disk. Managed identities eliminate the need for secrets entirely.

Shared access signatures (SAS) are used for delegated access to Azure Storage resources, not for authenticating to Azure Resource Manager or providing an identity for Azure VMs. They cannot serve as a consistent identity across VM rebuilds.

Management group scope applies permissions to all subscriptions within that group, which would grant the team Contributor access to resources beyond rg-app, violating the requirement to restrict access to only that resource group.

Subscription scope grants Contributor access to all resources in the subscription, not just those in rg-app, violating the requirement to restrict access to only that resource group.

Resource scope would grant Contributor access only to a specific resource, not to all resources in rg-app. The requirement is to manage all resources in the resource group, so resource scope is too narrow.

Assigning Contributor at the subscription scope grants far too many permissions, including the ability to create, delete, and modify VMs, disks, and networking, which violates the requirement to restrict those actions.

Reader role does not allow any write actions, including VM start/stop/restart, and Azure Policy cannot grant permissions—it only enforces compliance. Thus, this combination cannot provide the required power management capabilities.

A resource lock prevents deletion or modification of resources but does not grant permissions to start, stop, or restart VMs; it only blocks changes, so the team would have no ability to perform the required actions.

A single Azure Policy definition can only enforce one rule (e.g., allowed regions, required tags, or disabling public network access), not all three controls simultaneously. The question requires multiple controls, which necessitates an initiative (a collection of definitions).

A management group lock prevents accidental deletion or modification of resources, but it cannot enforce allowed regions, required tags, or disable public network access. Locks do not apply policy controls.

Custom RBAC roles control permissions (who can do what), not enforcement of resource configurations like allowed regions, tags, or network settings. The question asks for enforcing controls, not granting permissions.

RBAC roles control access to Azure resources (who can do what), not which regions are allowed for deployment. A built-in RBAC role cannot enforce region restrictions; Azure Policy is required for such governance.

A CanNotDelete lock prevents deletion of resources but does not restrict deployment regions; it cannot block resource creation in non-allowed regions.

Resource tags are not enforced; they rely on manual compliance and do not prevent deployment in unapproved regions. Azure Policy is required to enforce allowed locations across the management group hierarchy.

The Owner role at RG-Apps includes full management access, including the ability to change resource configurations, which violates the requirement that the support lead must not be able to change resource configurations.

The Contributor role allows managing resources but cannot grant or revoke role assignments to others, which is the primary requirement for the support lead.

Reader role only allows read access to resources, not the ability to manage role assignments. The support lead needs to grant or revoke access for others, which requires role assignment permissions.

Azure Policy cannot grant permissions; it only enforces compliance rules. Granting restart permission is an RBAC function, not a Policy capability.

Resource locks prevent deletion or modification of resources but cannot restrict VM sizes to approved types; they operate at a resource level, not on configuration properties like SKU.

Tags are metadata labels, not security enforcement mechanisms. They cannot enforce approved VM sizes or grant restart permissions; Azure Policy and RBAC are required for those actions.

A CanNotDelete lock prevents deletion but does not enforce secure transfer settings; it cannot remediate policy noncompliance.

Moving storage accounts to a new resource group does not trigger the DeployIfNotExists policy to remediate noncompliant resources; it only changes their location without applying the required policy effect.

Granting administrators a higher RBAC role does not trigger policy remediation; it only changes permissions. The DeployIfNotExists policy requires a remediation task to update noncompliant resources.

System-assigned identity is tied to the VM lifecycle; redeploying the VM creates a new identity, requiring RBAC reassignment. This does not keep the identity stable.

A shared access signature (SAS) is used for delegated access to specific Azure storage resources, not for VM identity. It cannot provide a stable application identity across VM redeployments and does not support RBAC assignments.

Three separate policy assignments at each subscription would require managing each subscription individually, violating the requirement for a single place to assign and track compliance across all subscriptions under the management group.

Custom RBAC roles control permissions to Azure resources, not governance policies like allowed locations, required tags, or permitted VM sizes. These controls require Azure Policy, not role-based access control.

Resource locks prevent accidental deletion or modification of resources but do not enforce governance controls like allowed locations, required tags, or permitted VM sizes. They cannot track compliance across multiple policies.

A role assignment grants permissions to users or groups, but does not enforce resource configuration requirements like tags or location restrictions. It cannot enforce compliance policies.

A resource lock prevents deletion or modification of resources but cannot enforce tagging or location restrictions. The question requires both a cost-center tag and approved locations, which are policy-based controls, not lock-based.

A management group is a container for organizing subscriptions and applying governance, but it cannot directly enforce tags or location restrictions. Policy assignments (via initiatives) are needed to enforce such rules.

Assigning the Reader role at the management group scope grants read access to all resources in all subscriptions under that management group, including the storage account, but also exposes other resources, violating the requirement that the analyst must not see other resources.

Assigning the Reader role at the subscription scope grants read access to all resources in the subscription, including other storage accounts and resources, which violates the requirement that the analyst must not see other resources.

Assigning the Reader role at the resource group scope grants read access to all resources within that resource group, including other storage accounts, virtual networks, or VMs, which violates the requirement that the analyst must not see other resources.

A system-assigned managed identity is tied to the lifecycle of the VM; if the VM is deleted, the identity is also deleted, so it cannot persist across VM recreations.

A service principal with a client secret stored in each VM requires manual secret management and rotation, and the secret would be lost if the VM is deleted, failing the requirement for a persistent identity across VM replacements.

A system-assigned managed identity is tied to the lifecycle of each VM; if a VM is rebuilt, its identity is recreated and loses the previous role assignment, so it cannot be shared across VMs.

A shared VM administrator password provides access to the VM itself, not to Azure resources like a storage account, and does not persist across VM rebuilds because the password would need to be reconfigured.

A SAS token provides time-limited, delegated access to a specific storage account or resource, but it is not tied to an Azure identity and would need to be securely distributed and rotated. If a VM is rebuilt, the SAS token would still work if stored externally, but the requirement is for all VMs to use the same Azure identity, which a SAS token does not provide.

Assigning the Virtual Machine Contributor role at the subscription scope grants the contractor access to all virtual machines in the subscription, including those outside RG-Test, violating the requirement to restrict access to only RG-Test.

The Reader role only allows read access, not the ability to manage virtual machines (e.g., create, delete, or modify VMs). The contractor needs to manage VMs, which requires a contributor-level role.

The Owner role grants full access to all resources in the scope, including the ability to manage access and delete resources, which exceeds the requirement to only manage virtual machines and violates the principle of least privilege.

Creating a new member user account with an internal password contradicts the requirement to avoid creating a separate username and password pair. The consultant should use their existing work account via B2B collaboration.

Adding the consultant to the Global Administrator role grants tenant-wide administrative privileges, which is excessive and violates the principle of least privilege. The question requires only access to a specific resource group, not full tenant control.

Sharing only the subscription ID and tenant ID does not grant the consultant any access; they need an identity in the tenant and an RBAC role assignment to access resources.

The question requires creating resources without passwords or client secrets, which is achieved via managed identity. Option B uses a service principal, which requires a password or certificate, violating the constraint.

The command 'az account set --subscription' only changes the active subscription context; it does not authenticate the user or VM. Since the script must authenticate without passwords or secrets, this command cannot establish the required identity.

The question requires a non-interactive, passwordless method for an Azure VM script. Connect-AzAccount -UseDeviceAuthentication uses device authentication, which requires user interaction and a browser, making it unsuitable for an automated script.

The question asks what to create first to group three policy definitions together. A resource lock prevents accidental deletion or modification of resources but does not group policies; it is unrelated to the requirement.

Creating a custom RBAC role that grants permission to edit policy assignments does not group policy definitions together; it only controls who can modify assignments. The question asks for grouping three policy definitions, which is achieved by a policy initiative, not by managing permissions.

An exemption is used to exclude specific scopes from policy enforcement, not to group policies together. The question asks for grouping three policy definitions, which requires an initiative, not an exemption.

Reader at subscription scope grants read access to all resource groups in the subscription, including those outside RG-Finance, violating the requirement that the auditor should not have access to other resource groups.

Contributor role grants write permissions (e.g., create, delete, modify resources), which violates the auditor's requirement to not make any changes. The auditor only needs read access.

Reader at the management group scope grants read access to all resource groups under that management group, including those outside RG-Finance, violating the requirement that the auditor should not have access to other resource groups.

A CanNotDelete lock prevents deletion but does not grant any read permissions; RBAC roles control access, not locks.

Azure Policy assignments do not grant RBAC permissions; they enforce compliance rules. Auditing a VM does not provide read access to the resource.

A private endpoint provides network connectivity to a VM via a private IP, but it does not grant any Azure RBAC permissions. Read access is controlled by role assignments, not by networking components.

The Deny effect prevents resource creation or modification if the tag is missing, which contradicts the requirement to not stop users from creating or changing resources.

Granting Reader permission to the compliance team allows them to view resources but does not identify missing tags or enforce compliance; it only provides read access, not the ability to audit or report on tag requirements.

A ReadOnly lock prevents any changes to resources, but the compliance team only needs to identify missing tags, not block modifications. The question explicitly states they do not want to stop users from creating or changing resources.

A system-assigned managed identity is tied to a single VM and cannot be shared across VMs. If one VM is redeployed, its identity is lost, and the script on the other VM cannot use the same identity.

A service principal stored in a configuration file on the VMs does not provide automatic credential rotation and would break if the file is lost or the VM is redeployed, failing the requirement for a consistent identity across redeployments.

A storage account access key stored in the script is not an identity; it's a static credential that doesn't support the requirement for a single identity usable by both VMs. If one VM is redeployed, the key remains valid, but it doesn't provide a unified identity and poses security risks if exposed in scripts.

The Owner role grants full access to all resources, including the ability to assign roles to other users, which violates the requirement that the engineer must not be able to assign roles.

The User Access Administrator role allows assigning roles to other users, which violates the requirement that the engineer must not be able to assign roles.

The Reader role only allows read-only access to resources; it does not permit creating virtual machines, which is a requirement in the question.

The Owner role grants full access to all resources, including the ability to delegate access to others, which violates the requirement that junior administrators cannot create, modify, or delete resources.

The Contributor role allows creating, modifying, and deleting resources, which violates the requirement that junior administrators cannot perform these actions.

Monitoring Reader provides read-only access to monitoring data (e.g., metrics, logs) but does not grant permission to view all resources in the subscription, such as virtual machines or storage accounts.

This option does not meet the requirement for separate subscriptions per business unit, as it uses a single subscription. It also fails to provide a single policy assignment covering all current and future subscriptions because there is only one subscription.

This option fails because it does not provide separate subscriptions per business unit for billing and admin delegation, and a single subscription cannot have separate policy assignments for each business unit's resources.

A ReadOnly lock allows read operations but prevents modifications. Listing resources is a read operation, so it is not blocked by the lock.

A ReadOnly lock only prevents modifications, not read operations. Reading tag values is a read operation, so it is not blocked by the lock.

A ReadOnly lock prevents any modification or deletion of resources, but viewing the VM power state in the portal is a read operation and is not blocked by the lock.

User-assigned managed identities are not automatically deleted when the associated app is deleted; they persist independently until explicitly removed. The question requires an identity that disappears automatically with the app, which is a property of system-assigned managed identities.

A service principal with a client secret is not automatically deleted when the app is deleted; it must be manually removed. It also requires storing a secret in app settings, which contradicts the requirement to remove the secret.

A shared access signature (SAS) is a token granting limited access to Azure Storage resources, not an identity for an app. It cannot be used to remove secrets from app settings or automatically disappear when the app is deleted.

RBAC roles control permissions to perform actions, not resource configurations. A custom role cannot restrict specific VM sizes because RBAC does not evaluate resource properties like size; it only grants or denies actions such as 'Microsoft.Compute/virtualMachines/write'.

A CanNotDelete lock prevents deletion of resources but does not restrict which VM sizes can be deployed. The question requires blocking deployment of non-approved VM sizes, which is a configuration enforcement, not a deletion prevention.

Reader permissions prevent operators from deploying any resources, and Azure portal validation only warns but does not block unsupported VM sizes. This does not enforce the restriction.

Resource groups organize resources within a single subscription but cannot enforce policies or rules across multiple subscriptions or automatically apply baselines to new subscriptions.

Resource locks prevent accidental deletion or modification but cannot enforce a common baseline of allowed regions, required tags, or approved SKU rules across multiple subscriptions, nor can they automatically inherit rules to new subscriptions.

A single policy exemption at the tenant root would exempt all subscriptions from a policy, not enforce a baseline. The question requires enforcing rules on production subscriptions, not exempting them.

The question explicitly prohibits using a client secret or password, and option D requires storing a client secret in a file, which violates that constraint.

Reader permissions allow viewing resources but not creating or modifying them, so the script would fail to create resources in the target resource group.

A ReadOnly lock prevents all write operations, including update, scale, and restart actions, which are explicitly required in the question.

Applying a CanNotDelete lock only to individual virtual machines leaves other resources in the resource group (e.g., databases, web apps) unprotected from deletion, failing to meet the requirement that administrators must not delete any resource inside the group.

Tags do not enforce access control or prevent deletion; they are metadata only. The question requires a mechanism to block deletion, which tags cannot provide.

Virtual Machine Contributor at subscription scope grants broader permissions than needed, including the ability to manage VMs beyond the RG-Apps resource group, violating the principle of least privilege.

Assigning Reader and Virtual Machine Contributor together at the resource group scope grants more permissions than needed, including the ability to create and manage VMs, which exceeds the required start, stop, deallocate, and read properties actions.

Assigning Owner at the resource group scope grants full control over all resources, including permissions management, which is far broader than the required start, stop, deallocate, and read properties actions.

Role assignments at a single subscription do not inherit to other subscriptions. The question requires a single assignment to cover all current and future subscriptions, which is only possible at the management group level.

Assigning at a resource group only grants access to resources within that group, not to all subscriptions under the management group hierarchy. The requirement is for every current and future subscription to inherit Reader access, which requires assignment at a higher scope like a management group.

Assigning at an individual resource only grants Reader access to that specific resource, not to the entire subscription or management group hierarchy. The question requires inheritance to all current and future subscriptions, which cannot be achieved at the resource level.

The question requires the VM to authenticate without storing keys or passwords, but a storage account shared key is a secret that must be stored on the VM, violating the requirement.

Azure Storage does not support basic authentication with a storage account name and password; it uses shared keys or tokens. The question requires avoiding stored secrets, and basic authentication would still require embedding a password.

Custom RBAC roles control access permissions, not resource deployment restrictions. They cannot block resource types; Azure Policy is required for that.

A ReadOnly lock prevents modifications to resources but does not block deployment of unapproved resource types; it only prevents deletion or modification of existing resources.

Budget alerts monitor spending and trigger notifications, but they cannot block resource deployments or enforce allowed resource type lists. They are a cost management tool, not a policy enforcement mechanism.

A ReadOnly lock prevents all write operations, including updating subnet settings, which contradicts the requirement that administrators must still be able to update subnet settings.

An Azure Policy deny assignment prevents any updates to the resource, including subnet settings, which contradicts the requirement that administrators must be able to update subnet settings.

A budget alert only notifies about spending thresholds; it does not prevent deletion or allow subnet updates, so it fails to meet the requirement of preventing accidental deletion while permitting subnet configuration.

Assigning the role at the subscription scope would grant the contractor permissions to all resource groups, including RG-Development, violating the requirement to restrict access to RG-Operations only.

Assigning the role at an individual virtual machine scope would only grant access to that specific VM, not to all VMs in RG-Operations as required. The contractor needs to start, stop, and read properties of all VMs in the resource group, which requires a role assignment at the resource group scope.

The User Administrator role grants broad permissions to manage all users and groups in Microsoft Entra ID, including resetting passwords and managing roles, which exceeds the requirement to only manage group membership without granting Azure resource permissions.

Creating separate local administrator accounts for each analyst grants local machine administrative privileges, not the ability to manage group membership in Microsoft Entra ID, and does not address the requirement of managing Azure AD groups without granting Azure resource permissions.

Assigning Contributor on the subscription grants full management access to all resources, including the ability to create, modify, and delete Azure resources, which goes beyond managing group membership and would grant Azure resource permissions.

The question requires the narrowest scope that covers only RG-App. Assigning at the subscription scope (Sub-IT-01) would grant permissions to all resource groups within that subscription, not just RG-App, violating the 'narrowest scope' requirement.

The management group scope is broader than the subscription, so assigning the role there would grant permissions to all subscriptions under that management group, not just Sub-IT-01 and specifically RG-App. The question requires the narrowest scope that covers only RG-App, which is the resource group scope.

The question requires that help desk staff restart VMs only in RG-App, but assigning the role at the individual VM scope would restrict them to only that specific VM, not all VMs in the resource group. The narrowest scope that covers all VMs in RG-App is the resource group scope.

Audit only reports noncompliant resources without taking any automatic remediation action, but the requirement is to automatically correct noncompliant storage accounts.

Disabled policy effect means the policy is not evaluated, so it cannot automatically correct noncompliant storage accounts. The question requires automatic correction, not ignoring the policy.

Append adds configuration to existing resources but cannot deploy new resources like a storage account with network rules; it only modifies existing properties, so it cannot automatically correct noncompliant new storage accounts by deploying the required network rules.

The Owner role grants full access to all resources, including the ability to create, modify, and delete resources, which violates the requirement that the analyst cannot create, modify, or delete any resources.

The Contributor role allows creating, modifying, and deleting resources, which violates the requirement that the analyst cannot perform these actions.

Virtual Machine Contributor allows managing virtual machines but does not grant read access to all resources in the subscription, nor does it allow viewing spending details. It also permits creating, modifying, and deleting VMs, which violates the requirement to prevent resource changes.

Resource locks prevent accidental deletion or modification of resources but do not group subscriptions or support hierarchical governance; they operate at the resource or resource group level, not across subscriptions.

Availability sets are used to ensure high availability of virtual machines by distributing them across fault domains, not for grouping applications by department or for governance and reporting purposes.

Private endpoints are used to securely connect to Azure services over a private IP address, not to separate subscriptions or create governance hierarchies. They do not help organize subscriptions or produce resource ownership reports.

Resource group names alone cannot encode ownership metadata like department and environment across multiple subscriptions; they are just naming conventions without enforced queryability or reporting capability.

Management groups organize subscriptions for policy and access management but do not provide metadata about department or environment ownership for individual resources.

Resource locks prevent accidental deletion or modification of resources but do not provide metadata about ownership or environment. They cannot be used to report which department or environment owns a resource.

A custom RBAC role at the tenant root controls permissions (who can do what), not resource creation rules. It cannot enforce tag requirements on resource group creation.

A CanNotDelete lock prevents deletion or modification of resources but does not enforce tagging requirements on new resource groups. It cannot block creation of resource groups based on missing tags.

A subscription budget alert only notifies when spending exceeds a threshold; it does not enforce tagging requirements or block resource group creation.

RBAC role assignments control permissions (who can do what), not governance rules like allowed regions or tags. They cannot enforce resource configurations or provide a compliance view for policies.

A management lock prevents deletion or modification of resources but cannot enforce governance rules like allowed regions, tags, or VM sizes. It does not provide a compliance view or group multiple policies together.

Private endpoints for Azure Resource Manager restrict network access to Azure Resource Manager endpoints, not enforce governance rules like allowed regions, tags, or VM sizes.

Assigning Contributor at the rg-prod resource group scope would grant the contractor access to all resources in that group, including those that must remain untouched, violating the requirement to limit access to only VM1 and VM2.

Assigning Contributor at the subscription scope grants the contractor access to all resources in the subscription, including other resource groups and resources in rg-prod beyond VM1 and VM2, violating the requirement to restrict access to only VM1 and VM2.

A ReadOnly lock prevents all modifications, including creating new VMs, but does not restrict creation to approved regions; it blocks all VM creation regardless of location.

An action group in Azure Monitor is used for sending notifications or executing automated actions based on alerts, not for restricting VM creation to approved regions.

Moving all existing VMs to approved regions does not prevent users from creating new VMs in disallowed regions, and the question explicitly states that existing noncompliant VMs can remain unchanged.

Assigning the role at the subscription scope grants permissions to all virtual machines in the subscription, not just vm-app01, violating the requirement to restrict access to only that VM.

Assigning the role at the resource group scope would grant permissions to all virtual machines within that resource group, not just vm-app01, violating the requirement to limit permissions to a single VM.

User-assigned managed identities are independent Azure resources; they persist independently of any VM lifecycle and are not automatically deleted when a VM is deleted.

User-assigned managed identities do not require a storage account access key; they authenticate via Azure AD using a service principal, not storage keys.

User-assigned managed identities are designed to be independent Azure resources that can be assigned to multiple VMs simultaneously; they are not limited to a single VM.

Managed identities are Azure-resident and cannot be assigned to an on-premises build server; they only work for Azure resources like VMs or App Services.

Managed identities cannot be assigned to on-premises servers; they are only available for Azure resources like VMs or App Services. The build server is outside Azure, so a managed identity cannot be used.

Resource locks prevent accidental deletion or modification of resources but do not provide any authentication or authorization mechanism for deploying ARM templates. They cannot replace a credential for automation.

A shared storage account key is a static secret that must be stored on the VM, violating the requirement to avoid storing passwords or keys. It also persists beyond the VM's lifecycle, so it is not automatically removed when the VM is deleted.

A user account with a local password on the VM would require storing credentials on the VM, which violates the requirement to avoid storing passwords or secrets. Additionally, it is not automatically removed when the VM is deleted.

A service endpoint on the VM subnet secures traffic to Azure Storage but does not provide identity-based access; it still requires a shared key or SAS token for authentication, which violates the requirement to avoid storing secrets on the VM.

Assigning roles to individual contractor accounts requires manual updates each time a contractor leaves or joins, which contradicts the requirement to maintain consistent access without editing role assignments.

Device groups are used for managing device compliance and configuration policies, not for assigning Azure role-based access control (RBAC) permissions to users. They cannot grant Azure resource access to contractors.

Assigning an Azure role to an Azure subscription would grant access to all resources in that subscription, not just the contractor team, and does not address the need to manage access for a dynamic group of contractors without editing role assignments.

The Virtual Machine Contributor role includes permissions to create, delete, and resize VMs, which violates the requirement to restrict those actions.

The Contributor role at the subscription scope grants full management access to all resources in the subscription, including the ability to create, delete, and resize virtual machines, which violates the requirement to restrict the engineer from performing those actions.

The Reader role only allows read-only access to resources, so it does not include permissions to restart virtual machines, which is a write operation.

Adding Contractor01 as a member of AppOps-Admins grants them only group membership, not the ability to manage team membership. To manage membership, they need owner permissions on the group, not member permissions.

The User Administrator role at tenant scope grants permissions to manage user accounts and groups across the entire Azure AD tenant, which includes Azure resource permissions indirectly through group management. The question requires managing team membership without receiving Azure resource permissions, and this role provides broader administrative access than needed.

The Contributor role grants full management access to Azure resources, including permissions to create, modify, and delete resources, which contradicts the requirement to avoid giving Contractor01 Azure resource permissions.

A system-assigned managed identity is tied to the lifecycle of a specific VM instance. When the VM is reimaged or redeployed with a different name, the identity is lost, and the new VM would get a new identity, breaking the application's access.

A shared storage account key placed in a custom script exposes a static secret that must be managed and rotated, violating the requirement for secretless access and not preserving identity across VM reimages or redeployments.

A policy exemption does not provide authentication; it only bypasses Azure Policy effects. The VM still needs a managed identity or other credential to authenticate to Key Vault, and a policy exemption does not grant access to secrets.

A user-assigned managed identity is not automatically tied to the VM's lifecycle; it persists independently and must be manually deleted, whereas the question requires the identity to be removed when the VM is deleted.

A storage account shared access signature (SAS) is a token for delegated access to a storage account, not for accessing Key Vault. It does not provide an identity tied to a VM and would require storing the SAS token on the VM, violating the requirement to avoid credential storage.

A local administrator account with a strong password stores credentials on the VM, violating the requirement to avoid storing credentials. It also does not provide an identity tied to the VM that is automatically removed when the VM is deleted.

A user-assigned managed identity persists independently of the VM lifecycle; it is not automatically deleted when the VM is deleted, failing the requirement for automatic removal.

A storage account SAS token provides time-limited access but is not tied to the VM's lifecycle; it does not automatically revoke access when the VM is deleted.

NSG service tags are used to define network access rules based on Azure services, not to provide identity for VM access to storage. They do not support automatic removal upon VM deletion.

Azure RBAC controls permissions to perform actions on resources, but it does not have the capability to restrict which Azure regions can be used for deployments. Region restriction is a governance requirement, not an access control one.

Network security groups (NSGs) filter traffic at the subnet or NIC level, not control which Azure regions can be used for resource deployments. They cannot restrict region selection during deployment.

A read-only lock prevents modifications to resources but does not restrict which Azure regions can be used for deployments; region restrictions require Azure Policy.

Reassigning the policy at a lower scope does not trigger remediation for existing resources; it only applies to new resources. The modify effect requires a remediation task to update existing non-compliant resources.

Changing the policy effect from modify to audit would only report compliance without automatically adding the tag; it does not update existing resources.

Adding a CanNotDelete lock prevents deletion but does not apply tags to existing resources. The question requires updating older VMs with a CostCenter tag, which is a policy remediation task, not a lock.

Global Administrator has full access to all Microsoft Entra ID features, including modifying group memberships and deleting users, which exceeds the required permissions for resetting passwords only.

User Administrator can reset passwords but also has permissions to modify group memberships and delete users, which exceeds the required scope of only resetting passwords for cloud-only users.

Security Administrator role manages security features like conditional access and identity protection, but does not include permissions to reset passwords for cloud-only users.