CCNA Manage Azure Identities and Governance Questions

Applying a ReadOnly lock prevents any modifications to resources, including adding or updating tags, which contradicts the requirement to automatically apply tags to new resources and update existing ones.

Assigning the Reader role to the resource group ensures tag visibility but does not automatically apply or enforce the CostCenter tag. The requirement is to automatically add the tag to new resources and update existing ones, which requires a policy with a Modify effect, not a role assignment.

An Audit policy only reports noncompliance but does not automatically add or update tags. The requirement is to automatically apply the CostCenter tag to new and existing resources, which requires a Modify policy with a remediation task, not just auditing.

A ReadOnly lock prevents all modifications, including configuration changes during maintenance windows, which violates the requirement to allow normal configuration changes.

Azure Policy assignments deny or audit actions based on rules, but they do not prevent deletion by default unless a specific deny effect is configured for delete operations. Even then, policy can be overridden by permissions, whereas locks provide a stronger, role-independent restriction.

Applying the lock only to individual VMs does not protect the storage account or other resources in the resource group from accidental deletion, failing to meet the requirement to prevent deletion of all resources.

A role assignment granting Owner on RG-Legacy does not override a deny policy; deny policies take precedence over role assignments. The storage account would still be blocked by the policy.

A management lock prevents accidental deletion or modification of the storage account, but it does not override a deny policy that blocks public network access. The lock cannot exempt the resource from policy enforcement.

A separate initiative assigned only to RG-Legacy with the deny setting disabled would remove the deny effect entirely for that resource group, but the question requires the deny policy to remain in effect for all other resources and only allow the existing storage account to be publicly reachable for 45 days. An initiative with the deny setting disabled would allow new storage accounts with public access to be created in RG-Legacy, which violates the policy intent.

Removing the policy assignment from the management group would disable the policy for all subscriptions and resource groups under it, not just the legacy storage account, violating the requirement to deny public network access for other storage accounts.

Assigning a Contributor role grants permissions to manage resources but does not override a policy that denies public network access. The policy will still block any creation or update that enables public access, and the existing legacy account's public access is not affected by role assignments.

A system-assigned managed identity is tied to the lifecycle of each VM; if a VM is deleted and recreated, it gets a new identity, breaking the requirement that the same identity must persist across deletion and recreation.

A service principal stored in the VM image would be tied to that specific image and would not persist if a VM is deleted and recreated, as the new VM would need to have the same image or the service principal manually re-configured. It also cannot be shared across multiple VMs in different resource groups without additional configuration.

A shared access signature (SAS) is used to delegate access to Azure Storage resources, not to provide an Azure identity for VMs. It cannot be assigned to a resource group and does not persist across VM deletion and recreation.

Azure Policy is used to enforce organizational standards and assess compliance, not to simplify access management. It does not grant or manage permissions for users.

A ReadOnly lock prevents any changes, including updates and deletions, but the requirement is only to prevent accidental deletion during change freezes, not to block all modifications. Additionally, it does not address the CostCenter tag requirement.

Granting Reader permission to the finance team allows them to view resources but does not enforce tagging or prevent deletion. The question requires preventing accidental deletion and ensuring a CostCenter tag on new resources, which Reader cannot achieve.

A private endpoint secures network connectivity to a PaaS service (e.g., Storage, SQL) by giving it a private IP in a VNet, not a resource group. It does not prevent deletion or enforce tagging.

Assigning the custom role at the subscription scope would grant the restart permission to all virtual machines in the subscription, not just those in RG-Prod, violating the requirement to scope the role only to RG-Prod.

The Virtual Machine Contributor role allows creating, deleting, and resizing VMs, which exceeds the required permission to only restart VMs. Assigning it at RG-Prod scope would grant broader permissions than intended.

Assigning the custom role at the management group scope would apply the permission to all subscriptions and resource groups under that management group, not just RG-Prod, violating the requirement to restrict access to only that resource group.

Azure RBAC controls permissions to create resources but cannot enforce that created resources include specific tags like costCenter; that requires Azure Policy's evaluation and enforcement capabilities.

Resource locks prevent deletion or modification of resources but cannot enforce tagging requirements or evaluate resource properties during creation.

Service endpoints restrict network access to Azure services, not enforce resource properties like tags. They cannot prevent storage account creation based on missing tags.

Azure Policy does not manage role-based access control (RBAC) like granting Contributor access. RBAC is handled by Azure role-based access control, not Azure Policy.

Azure Policy does not manage user identities; creating Microsoft Entra ID users is an identity management task handled by Microsoft Entra ID, not Azure Policy.

Placing a CanNotDelete lock on every resource group does not address the requirement to restrict regions or enforce tagging; it prevents deletion of resource groups, which is unrelated to the stated goals.

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

A service principal with a client secret requires storing the secret on disk or in environment variables, which violates the requirement of not storing a password or certificate on disk. Additionally, it does not automatically disappear when the VM is deleted; the service principal persists independently.

A storage account access key is used for authenticating to Azure Storage, not for calling Azure APIs in general, and it does not provide an identity that disappears when the VM is deleted.

The policy is already assigned at the resource group scope (RG-Prod), and moving it to the subscription scope would not trigger remediation for existing resources; it would only apply to new resources in the subscription. The issue is that existing VMs lack the tag, which requires a remediation task, not a scope change.

Changing the effect to Deny would block creation or modification of resources that lack the tag, but it does not apply the tag to existing resources. The question specifically asks how to fix existing VMs that are missing the tag, which requires a remediation task, not a policy change.

Adding a CanNotDelete lock to RG-Prod prevents deletion of resources but does not apply tags to existing virtual machines. The issue is that existing resources are not retroactively updated by the Modify effect, which requires a remediation task.

A ReadOnly lock prevents any updates to the storage account, but the question requires the account to remain available for updates. Thus, it does not meet the requirement of allowing updates while preventing deletion.

A CanNotDelete lock at the subscription scope would prevent deletion of all resources in the subscription, not just the storage account, and is overly broad for the requirement of preventing accidental deletion of a specific storage account during maintenance.

Azure Policy deny assignments block operations based on policy rules, but they do not prevent accidental deletion specifically; they are for enforcing compliance across resources, not for protecting a single resource from deletion during maintenance.

System-assigned managed identities are tied to each resource's lifecycle and cannot be shared across resources; they also cannot be centrally removed without updating each resource individually.

A service principal with a client secret stored in application settings does not survive redeployment because the secret must be manually rotated and stored, and it cannot be centrally removed without updating each resource's configuration.

A resource lock prevents accidental deletion or modification of the Key Vault, but it does not provide any identity for the web app and VM scale set to authenticate to Key Vault. The question asks for an identity type, not a protection mechanism.

Service principals with client secrets require manual secret rotation and storing the secret in an app setting still exposes it as a stored secret, violating the requirement of no stored secrets and no manual rotation.

Shared administrator username and password stored in a Key Vault secret require manual rotation and expose static credentials, violating the requirements of no stored secrets and no manual rotation.

A SAS token is a shared access signature that grants time-limited access to specific resources like storage accounts. It requires manual generation, cannot be reused indefinitely without exposing the account key, and does not provide a reusable identity without stored secrets, failing the requirement of no manual secret rotation.

The Reader role allows read-only access to all resources, but does not permit starting, stopping, or restarting VMs, which require write-level permissions.

Virtual Machine Contributor allows creating and deleting VMs, which violates the requirement that help desk staff must not create or delete VMs.

The Contributor role allows creating and deleting VMs, as well as modifying networking and disks, which exceeds the required permissions of only starting, stopping, and restarting VMs.

Deleting the policy assignment from corp-root would remove compliance enforcement for all resources, not just rg-merger01, and would require recreating it later, causing unnecessary disruption and administrative overhead.

Changing the policy effect to Audit would allow noncompliance but would not provide a temporary exception for a single resource group; it would affect all resources under the policy scope, violating the requirement for a targeted exception.

Assigning the role at the subscription scope would grant the contractor permissions to restart and read properties for all VMs in the subscription, not just vm-pay-01, violating the requirement to restrict access to only that VM.

Role assignments can be applied directly to virtual machines at the resource scope, so the claim that 'resource assignments cannot be applied to virtual machines' is false. Azure RBAC supports assigning roles at the resource level, including individual VMs.

Assigning the role at the management group scope would grant the contractor permissions to all virtual machines across all subscriptions under that management group, not just vm-pay-01, violating the requirement to restrict access to only that VM.

Subscription scope would grant read access only to a single subscription, not to all current and future subscriptions under the Corp management group, failing the requirement for cross-subscription governance reporting.

Resource group scope limits access to a single resource group, not all resources across all subscriptions under a management group, so it fails to meet the requirement of reading all resources in current and future subscriptions under Corp.

Resource scope limits the role assignment to a single resource, which cannot cover all resources across multiple subscriptions under a management group, failing the requirement to read all resources in current and future subscriptions.

Using a storage account access key requires storing the key in code or configuration, violating the requirement to avoid storing passwords, keys, or connection strings. It also does not automatically remove the identity when the VM is deleted.

A shared access signature (SAS) requires storing a token (key) in the application or configuration, violating the requirement to avoid storing passwords, keys, or connection strings. Additionally, SAS tokens are not automatically removed when the VM is deleted.

A user-assigned managed identity is not automatically deleted when the VM is deleted; it persists independently until explicitly removed. The question requires automatic removal with the VM, which only a system-assigned managed identity provides.

Audit logs non-compliant resources but does not block deployment; the question requires blocking new resources at deployment time, which only Deny can do.

Append adds a tag or value to a resource but does not block deployment; it modifies the resource after creation, so it cannot prevent untagged resources from being deployed.

The 'Disabled' effect turns off the policy definition, meaning it does not evaluate or enforce any rule. It would not block resources missing the Environment tag at deployment time.

A single Azure Policy definition can only enforce one rule, not three related rules as a unit. The question requires grouping multiple rules, which is the purpose of an initiative.

A management group with no policy assignments does not enforce any rules; it merely organizes subscriptions. The question requires applying and tracking three rules as one unit, which demands policy assignments, not just a container.

An RBAC custom role with deny permissions can block actions but cannot enforce resource properties like tags, locations, or VM SKUs; Azure Policy is required for such compliance rules.

The question requires that no secrets be stored on the VM, and a user-assigned managed identity does not inherently prevent secret storage; however, the key constraint is that the identity must be available during startup without manual configuration. A system-assigned identity is automatically created and tied to the VM's lifecycle, making it the simplest choice for a single VM that needs to access Key Vault at startup without managing secrets.

Storing a client secret in the VM configuration violates the requirement that no passwords, certificates, or client secrets may be stored on the VM. Managed identities eliminate the need for secrets entirely.

A shared access signature (SAS) is used for delegated access to Azure Storage, not for authenticating to Key Vault. Key Vault does not support SAS tokens for authentication.

The Reader role only allows read access to resources, not the ability to grant or remove RBAC roles, which is required by the question.

The Contributor role allows operators to create, modify, and delete resources, which violates the requirement that operators must not perform these actions. It also does not grant permission to manage role assignments.

The Tag Contributor role allows managing tags on resources but does not include the 'Microsoft.Authorization/roleAssignments/write' permission needed to grant or remove RBAC role assignments, which is the core requirement.

Assigning Reader at the Corp management group would grant read access to all subscriptions under Corp, including Sandbox, which violates the requirement that OpsGroup must not have access to Sandbox.

Assigning Reader at a single resource group in AppSub1 would only grant read access to that specific resource group, not to all current and future resources across all three Prod subscriptions as required.

Assigning Reader at each subscription individually would grant access to the three Prod subscriptions, but it would not cover future subscriptions added to the Prod management group, violating the requirement for future resources.

Tags alone cannot enforce separate budgets, subscription administrators, or access controls; they are metadata only and do not provide administrative isolation or separate billing.

Resource groups cannot enforce separate budgets, subscription administrators, or access controls; they share the same subscription-level policies and RBAC. Management groups provide policy inheritance, but this option lacks separate subscriptions for independent administration.

Putting production in a management group and development in a resource group is invalid because management groups and resource groups are hierarchical containers at different levels; you cannot place a resource group inside a management group in this manner, and it does not provide separate subscription-level administration or budgets.

A single policy assignment with separate rules cannot be easily extended with new controls; initiatives (policy sets) are designed to group multiple policies for scalable governance.

Role assignments grant permissions to users or services, not enforce governance controls like allowed regions or required tags. They cannot enforce resource configuration or compliance.

Resource locks prevent accidental deletion or modification but cannot enforce allowed regions or required tags. They are not a governance control for compliance rules.

Assigning Reader at the subscription scope grants read-only access to all resource groups in the subscription, which violates the requirement of limiting access to only one application resource group. Additionally, assigning directly to the user account does not leverage group-based access, making immediate removal upon contractor departure less efficient.

Contributor provides write/delete permissions, exceeding the required read-only access. The question explicitly requires read-only access, making Contributor inappropriate.

Assigning Reader at the management group scope grants read-only access to all subscriptions and resource groups under that management group, which is broader than the required single application resource group. It also does not ensure immediate removal when the contractor is removed from the contractor team, as the assignment is at the management group level, not tied to the group.

Assigning Reader at the RG-Finance resource group scope would only grant read access to resources within that specific resource group, not to all current and future resources in every subscription under the Corp management group. The requirement is for all subscriptions under Corp, which is a broader scope.

Assigning Reader separately at each subscription scope would not cover future subscriptions added under the Corp management group, violating the requirement to read all current and future resources.

Assigning Reader at the individual resource scope would require manual assignment for every resource, failing to cover future resources and violating the requirement to read all current and future resources across all subscriptions under Corp.

Relying solely on RBAC does not prevent accidental deletion of the resource group; a user with delete permissions (e.g., Contributor) could still delete it. The question requires a lock to block deletion.

A ReadOnly lock prevents any changes to resources, including updates to settings, which contradicts the requirement that administrators still need to update settings on resources inside the resource group.

A Contributor role assignment allows users to manage resources, including deletion, which does not prevent accidental deletion of the resource group.

Resource locks prevent accidental deletion or modification of resources, but they do not group policy rules into an assignment. The question asks for grouping related policy rules, which is the purpose of an Azure Policy initiative.

Azure RBAC custom roles define permissions for access control (who can do what), not grouping policy rules. The question asks for grouping policy rules into one assignment, which is the purpose of an Azure Policy initiative, not a custom role.

A policy exemption is used to exclude a specific resource or scope from an existing policy assignment, not to group multiple policy rules into a single assignment.

Policy assignments at the management group scope automatically apply to all child subscriptions and resource groups; there is no need to copy the initiative to each resource group.

Azure Policy initiatives do not modify Azure RBAC permissions. They evaluate and enforce compliance rules but never change role assignments or access rights.

Compliance results are visible in Azure Policy's Compliance blade, not only in Activity Log. Activity Log records policy events, but the main compliance view is in Azure Policy.

System-assigned managed identities are tied to a single VM and cannot be shared across multiple VMs. The question requires a single identity reused by all three VMs, which user-assigned managed identities support.

Storage account access keys provide full control over the storage account and must be shared or stored in each VM's application settings, violating the requirement to avoid sharing secrets. They also do not support granular, identity-based access for individual VMs.

SAS tokens must be stored and rotated manually, which violates the requirement to 'reuse the same Azure access without sharing secrets.' They are per-resource tokens that cannot be shared across VMs without exposing secrets.

A ReadOnly lock prevents modifications to a resource but does not record ownership; tags are used for metadata like department and environment.

Tags do not encrypt data; they are metadata key-value pairs used for organizing resources. Encryption is handled by Azure Storage Service Encryption, Azure Disk Encryption, or other dedicated services.

Tags are metadata labels, not enforcement mechanisms; Azure Policy is used for compliance enforcement, not tags.

The VM in RG-Apps does not have a direct Contributor assignment; it inherits Contributor from the resource group scope. The behavior is explained by inheritance, not direct assignment.

In Azure RBAC, roles are additive and inherited; Reader at subscription scope does not override Contributor at resource group scope. The VM in RG-Shared is read-only because it only inherits Reader from the subscription, not because Reader overrides Contributor.

Azure Policy does not grant write access; it enforces rules (e.g., tagging, locations). The developer's ability to change settings in RG-Apps is due to RBAC role inheritance, not policy.

System-assigned managed identities are tied to each VM's lifecycle and cannot be shared across multiple VMs in different resource groups. If the VMs are redeployed, each VM would get a new identity, breaking the shared access requirement.

A shared access signature (SAS) stored in a configuration file does not persist across VM redeployments because the file is lost when the VM is deallocated, and it cannot be shared across multiple VMs in different resource groups without manual management.

The local Administrator account is a static credential tied to each VM, not an Azure identity. It cannot be used to authenticate to Azure Storage across multiple VMs, and it does not persist across redeployments if the VM is reimaged or recreated.

Audit only logs non-compliance but does not automatically add the missing tag, so newly created resource groups would not inherit the CostCenter tag.

Deny prevents creation of resources that don't meet a condition, but it cannot automatically add a missing tag; it would block the resource group creation entirely if the tag is missing, which is not the requirement.

The 'Disabled' effect turns off the policy and does not enforce any behavior, so it cannot ensure that the CostCenter tag is automatically inherited on new resource groups.

Assigning Reader at RG-App scope would not grant read access to resources in future resource groups under the Sales subscription, as required by the question.

Assigning Virtual Machine Contributor at the Sales subscription scope grants ServerOps start, stop, and restart permissions on all VMs in the subscription, not just those in RG-App, violating the requirement to limit permissions to RG-App.

Owner grants full control, including permission to assign roles and delete resources, which exceeds the requirement to only start, stop, and restart virtual machines. This violates the principle of least privilege.

System-assigned managed identities are tied to a single VM's lifecycle; deleting and recreating the VM would break the identity, and copying access tokens is insecure and not supported for cross-VM use.

Storing an application password locally on each VM violates the requirement for the identity to keep working if a VM is deleted and recreated, as the password would be lost or require manual reconfiguration. It also introduces security risks and does not use Azure-managed identities.

Assigning Virtual Machine Contributor at subscription scope grants permission to create, delete, and resize VMs across all resource groups, which exceeds the required restriction of preventing these actions.

The Contributor role at RG-App includes write and delete permissions on all resources, which would allow the help desk team to create, delete, or resize VMs, violating the requirement.

Assigning Owner at RG-App grants full control, including the ability to create, delete, and resize VMs, which violates the requirement to prevent those actions. Azure Policy can block some changes but does not restrict RBAC permissions, so the help desk would still have excessive rights.

The Virtual Machine Contributor role allows creating, deleting, and resizing VMs, as well as modifying disks and networking, which exceeds the required permissions of only restarting VMs.

Azure Policy assignments deny or audit resource creation based on rules, but they do not grant or restrict actions for existing resources like restarting VMs. The question requires a role-based solution to allow restarting VMs, not a policy to deny creation.

A ReadOnly lock prevents any changes to resources, including restarting VMs, which requires write access. The operations team needs to restart VMs, so this lock would block their required action.

A ReadOnly lock prevents all modifications, including updates to resources inside the resource group, which contradicts the requirement to allow administrators to update resources.

A deny assignment blocks all actions that are not explicitly allowed, which would prevent administrators from updating resources inside the resource group. The question requires allowing updates while only preventing deletion, so a CanNotDelete lock is appropriate.

A budget alert only sends notifications when spending exceeds thresholds; it does not prevent deletion of the resource group or its resources.

A ReadOnly lock prevents all modifications, including patching and configuration changes, which are still required by administrators. The question explicitly states that administrators need to modify configuration and apply patches, so a ReadOnly lock is too restrictive.

A policy assignment that denies delete operations on the resource group does not prevent deletion of individual resources within the group; it only prevents deletion of the resource group itself. The question requires preventing deletion of the VM and storage account, not the group.

A management group with a deny assignment would apply to multiple subscriptions, not just the single resource group. It is overly broad and does not target the specific resources (VM and storage account) within that resource group.

Creating a separate custom role assignment for each administrator increases administrative effort because each membership change requires updating individual assignments, contradicting the goal of minimizing ongoing effort.

Resource locks prevent accidental deletion or modification of resources but do not grant permissions to manage backups. They are not a mechanism for assigning RBAC roles.

A policy exemption is used to exclude resources from Azure Policy evaluation, not to assign RBAC roles. It does not grant permissions to manage backups.

A ReadOnly lock prevents all write operations, including updating VM sizes and tag values, which the question requires administrators to be able to do.

Applying a lock to the subscription would prevent deletion of all resource groups in the subscription, including non-production ones, which is too restrictive and not required by the scenario that only targets the production resource group.

Azure Policy with a deny effect can block delete operations, but it is not a lock and does not prevent deletion of the resource group itself; it only enforces rules on resources within the group. The question specifically requires a lock that prevents deletion while allowing updates to VM sizes and tags, which is exactly what a CanNotDelete lock does.

A custom RBAC role with resource permissions for policy management does not bundle policy definitions or allow assigning them together to a management group; RBAC controls access to resources, not policy assignment.

A resource lock prevents deletion or modification of a subscription, but it does not bundle or assign policy definitions, nor does it allow exempting a subscription from policies for a specific duration.

Creating separate management groups for each policy definition does not bundle them into a single assignable unit; the compliance team needs to assign all three together, which requires an initiative (policy set), not separate management groups.

CanNotDelete lock blocks deletion but allows all other write operations, including updating tags, resizing VMs, and changing NSGs. The question states these updates fail, so a ReadOnly lock is required.

A Reader role assignment removes edit permissions but also blocks read access to resource details, which contradicts the scenario where users can still read resource details.

Azure Policy audit assignment only reports compliance of existing resources without blocking any actions, so it would not prevent updates to tags, VM resizing, or NSG changes.

Assigning the Contributor role on the application resource group grants the service desk permissions to manage Azure resources, violating the requirement that they must not receive any Azure subscription or resource permissions.

The User Administrator role grants permissions to manage all users in the directory, including resetting passwords and managing licenses, which exceeds the requirement that the service desk must not receive any Azure subscription or resource permissions. The question specifically asks for granting/revoking access to an internal application, not managing user accounts.

Creating individual user assignments for every employee is inefficient for a changing group; it requires manual updates for each user addition or removal, contradicting the need for a scalable, group-based approach.

A subscription is a billing and management boundary, not a container for applying access control, tags, and deletion protection to a group of resources that are deployed together. Resource groups are designed for that purpose.

A management group is used to manage multiple subscriptions, not to group resources within a single subscription for access control, tagging, and deletion protection.

A tag value alone cannot enforce access control, apply deletion protection, or serve as a container for resources; tags are metadata labels, not management boundaries.

A member user account is for users within the company's own tenant, not for external consultants who need to sign in with their own work account. Guest user accounts (B2B collaboration) are designed for external users.

A Microsoft 365 group is used for collaboration and granting permissions to multiple users, not for providing external individual access. It cannot be used to give a specific external consultant read-only access to a resource group.

A service principal is an identity for applications or automated tools, not for individual users. The question requires a user account for an external consultant to sign in with their own work account, which is a B2B collaboration scenario, not an application identity.

The Reader role provides read-only access and does not include restart actions, so assigning it at RG-App would not allow the automation account to restart VMs.

Assigning Virtual Machine Contributor at the subscription scope grants broader permissions than needed, including actions like creating and deleting VMs, which violates the requirement to restrict actions to only restart and read network interfaces.

Creating a management group and moving RG-App into it does not restrict permissions; management groups are containers for organizing subscriptions and applying governance, not for scoping custom actions. The automation account still needs a role assignment with specific actions, which management groups do not provide.

Assigning Contributor to each user individually does not allow centralized management of access as team members change; each new member would require a separate assignment, and removals would need manual updates.

A managed identity is an Azure AD identity used by Azure resources to authenticate to services without storing credentials, not for assigning roles to human team members. It cannot be used for central access management as team members change.

Assigning Contributor to the management group that contains rg-app would grant the role to all subscriptions and resource groups under that management group, not just to the specific team members. The question requires central management as team members change, which is best achieved via a security group, not a management group.

A resource lock prevents deletion or modification of resources but cannot group and assign multiple policy definitions across subscriptions for compliance reporting.

A role assignment grants permissions to an identity, not a collection of policy definitions. The question requires grouping policies into a single compliance package, which is achieved by an initiative, not a role assignment.

A managed identity is an Azure Active Directory identity for authenticating to Azure services, not for grouping policy definitions. It cannot bundle multiple policies into a single compliance package.

Assigning policies separately to each existing subscription only fails to cover future subscriptions and does not enforce governance at the management group scope, which is required by the question.

RBAC roles control access permissions, not governance rules like allowed locations or required tags. To enforce such rules, Azure Policy is required, not RBAC.

Manual tagging does not reduce manual entry or ensure consistency; it relies on users to remember and correctly apply the tag every time, which contradicts the requirement for automation and consistency.

Assigning a Reader role to the finance team allows them to view resources but does not automatically apply or enforce tags on resources. It does not reduce manual entry or ensure tag consistency.

Applying a CanNotDelete lock prevents deletion of the resource group or its resources but does not automatically apply or enforce tags, so it does not meet the requirement to inherit the CostCenter tag.

Assigning Reader separately on each subscription violates the requirement for only one role assignment to maintain, as it requires multiple assignments and ongoing management for new subscriptions.

Assigning Reader at the tenant root grants access to all subscriptions in the tenant, but the requirement is to maintain only one role assignment under the Corp management group. Removing the management group contradicts the goal of using management groups for governance and would affect other management groups or subscriptions not under Corp.

Assigning Reader at a resource group scope does not grant access to the subscription itself or future subscriptions, and it requires one assignment per resource group, violating the requirement for a single role assignment.

A custom RBAC role assigned at each subscription cannot enforce a list of allowed Azure regions because RBAC controls access to resources, not the configuration or compliance of resource deployments. It would require assigning the role to every subscription individually, lacking centralized inheritance.

A CanNotDelete lock prevents resource deletion but does not restrict which Azure regions can be used for new deployments. It cannot enforce a list of allowed regions.

Budget alerts only notify about spending thresholds; they do not enforce or restrict which Azure regions can be used for resource deployments.

The Virtual Machine Contributor role at subscription scope grants permission to manage VMs but also allows deleting VMs and managing networking resources, which violates the requirement to prevent deletion and networking management.

The Reader role allows reading VM settings but does not permit starting or deallocating VMs, which is required by the operations team.

The Owner role grants full access to all resources, including the ability to delete VMs and manage networking resources, which violates the requirement to prevent deletion and networking management.

A ReadOnly lock prevents all modifications, including reading and modifying data, which contradicts the requirement that administrators must still be able to read and modify data.

An NSG rule controls network traffic, not deletion prevention. The question is about preventing accidental deletion of a storage account, which is a management-plane operation, not a data-plane network issue.

System-assigned managed identities are tied to the lifecycle of the VM; if the VM is deleted, the identity is also deleted. The requirement is for a single identity that persists even when VMs are replaced, which user-assigned managed identities provide.

An Azure AD guest user account is for external collaboration, not for providing an identity to Azure resources like VMs. It cannot be assigned to a VM for authentication to Azure services, and it does not support the scenario of being reused across VMs for automation scripts.

A shared storage account key provides access to Azure Storage, not an identity for VMs to authenticate to Azure resources. It cannot be used as an identity for VMs to access other Azure services like Key Vault or Azure SQL, and it does not support role-based access control (RBAC) assignments for the VMs themselves.

Assigning Reader directly to the contractor's user account at the resource group scope does not allow for immediate removal of access when the contract ends; you would need to manually remove the assignment, which can be delayed or overlooked.

Assigning Reader at the subscription scope grants access to all resource groups in the subscription, violating the requirement to limit access to only one resource group.

A CanNotDelete lock prevents resource deletion but does not control access; the contractor would still have access after the contract ends, and removing the lock does not remove access.

RBAC roles cannot force users to enter tags; they control permissions, not resource properties. The requirement is to automatically add a tag without failing deployments, which RBAC cannot enforce.

A ReadOnly lock prevents modifications to resources but does not enforce tagging. The requirement is to automatically add a tag without failing deployments, which a lock cannot achieve.

The Deny effect would block resource creation if the tag is missing, causing deployments to fail, which contradicts the requirement that deployments should not fail if the tag is omitted.

A CanNotDelete lock prevents deletion of any resource within the resource group, including storage accounts. Therefore, deleting an unused storage account is blocked.

A CanNotDelete lock prevents deletion of the resource group and all resources within it. Deleting the entire resource group would violate the lock, so this action cannot be completed while the lock is in place.

A ReadOnly lock prevents all modifications, including creating and modifying resources inside the resource group, which contradicts the requirement to allow administrators to create and modify resources.

Azure does not have a 'Delete lock'; the correct lock type to prevent deletion is 'CanNotDelete'. 'Delete lock' is not a valid Azure lock type.

A budget alert does not prevent deletion; it only notifies about spending. The question requires a lock that blocks deletion, which budget alerts cannot do.

The build server is not running in Azure, so it cannot use a system-assigned managed identity, which is only available for Azure resources like VMs or App Services.

A personal user account with MFA cannot be used for automated, non-interactive deployments from a build server because MFA requires interactive user login, and the scenario explicitly prohibits storing a user password.

A shared access signature (SAS) is used to delegate access to Azure Storage resources, not to authorize ARM template deployments. It does not support RBAC or authentication for Azure Resource Manager operations.

Assigning roles directly to each contractor requires updating role assignments every time contractors change, which does not meet the requirement to follow membership changes without updating role assignments.

Microsoft 365 groups do not support Azure role assignments; only Microsoft Entra ID security groups and Microsoft Entra ID role-assignable groups can be used for Azure RBAC.

Management groups are used to organize subscriptions and apply governance at scale, not to manage access for individual users or groups. Assigning a role to a management group would grant access to all subscriptions under it, which is too broad and does not solve the need to dynamically add/remove contractors without updating role assignments.

Assigning policies individually at each resource group is inefficient and does not enforce the rules across all 12 subscriptions under the Corp management group. It also fails to provide a single point of management for the policy assignment.

The Owner role at the management-group scope grants full access to manage resources and assign roles, but it does not enforce policies or tags. The question requires enforcing deployment locations and tags, which is done via Azure Policy, not RBAC roles.

Resource locks prevent deletion or modification of resources but do not enforce deployment location or tagging requirements, which are the specific constraints in this question.

Assigning Network Contributor at the management group scope would grant permissions to manage all virtual networks and subnets across all subscriptions under that management group, not just VNet-vm in rg-platform.

Assigning Network Contributor at the subscription scope would grant the engineer permissions to manage all virtual networks and subnets across all resource groups in the subscription, including resources outside rg-platform, which violates the requirement to restrict management to only VNet-vm and its subnets.

Assigning Network Contributor at the resource group scope for rg-platform would grant the engineer permissions to manage all networking resources within rg-platform, not just VNet-vm and its subnets, violating the requirement to restrict access to only VNet-vm.

No lock would allow engineers to delete the resource group, which violates the requirement to prevent deletion.

ReadOnly lock prevents any modifications, including starting/stopping VMs and changing network rules, which are required during maintenance.

Azure Policy deny assignment is used to enforce compliance rules across resources, not to prevent deletion while allowing modifications. It would block all actions that violate the policy, including starting/stopping VMs or changing network rules, which contradicts the requirement for engineers to perform maintenance.

Assigning the Azure role directly to each contractor account requires manual updates when contractors join or leave, which contradicts the requirement to keep role access unchanged without editing assignments.

Creating a Microsoft 365 group does not help manage Azure role assignments for a contractor pool; it is designed for collaboration features like shared mailboxes and calendars, not for assigning Azure roles to users.

User-assigned managed identities are for Azure resources (e.g., VMs, apps) to authenticate to Azure services, not for assigning Azure RBAC roles to human users. They cannot replace role assignments for a changing contractor pool.

Management groups provide hierarchical organization and policy inheritance across subscriptions, but they do not persist metadata like ownership or chargeback information when resources are moved between resource groups.

Role assignments control access permissions but do not persist ownership or chargeback information when resources are moved between resource groups; they are tied to the resource scope and can change with moves.

Resource groups are containers for resources within a single subscription, not for grouping multiple subscriptions to apply governance settings above the subscription level.

Tags are metadata applied to Azure resources for categorization and cost tracking, not for grouping subscriptions or applying governance settings above the subscription level.

Resource locks prevent accidental deletion or modification of resources but do not provide governance settings above the subscription level. They operate at the resource or resource group level, not across multiple subscriptions.