CCNA Manage Azure Identities and Governance Questions — Page 4 of 4

226

MCQhard

A finance team wants every resource created in one production resource group to carry CostCenter=PRD automatically. They do not want deployments blocked if a team forgets the tag, but they do want existing resources and future resources in that resource group to converge on the correct tag value. What should the administrator configure?

A.Apply a CanNotDelete lock to the production resource group.

B.Assign a modify policy for CostCenter=PRD at the production resource group scope and create a remediation task.

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

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

AnswerB

A modify policy can add or correct the tag without blocking deployment, which matches the business requirement. Assigning it at the resource-group scope limits the effect to only that production workload, and remediation updates existing resources so both old and new items converge on the same tag value.

Why this answer

Azure Policy with a 'modify' effect can automatically add or correct the CostCenter tag on resources within the specified scope. By assigning the policy at the production resource group scope and creating a remediation task, the policy will audit existing resources and, via a managed identity, apply the tag value to non-compliant resources without blocking deployment. This satisfies the requirement for automatic convergence without preventing creation if the tag is missing.

Exam trap

The trap here is confusing Azure Policy's 'modify' effect (which allows non-blocking correction) with 'deny' or 'append' effects (which block or add without remediation), or assuming that tags on management groups automatically propagate to resources, which they do not.

Why the other options are wrong

A CanNotDelete lock prevents resource deletion but does not enforce or propagate tags. It does not automatically add or correct tags on existing or new resources.

Assigning Contributor at the subscription level does not enforce automatic tagging; it only grants permissions. Teams could still forget to add the tag manually, and there is no mechanism to remediate existing resources or enforce convergence.

Tags set on a management group are not inherited by resources in child resource groups; inheritance only applies to policies and RBAC, not tags. Therefore, this option would not automatically apply the CostCenter tag to resources.

Practice this question →

227

MCQmedium

A shared resource group contains a VPN gateway and several virtual machines used by the finance department. Administrators must still be able to resize the VMs and update NSG rules, but no one should be able to delete the resource group or anything in it during the quarter-end freeze. Which lock should be applied?

A.ReadOnly lock on the resource group

B.CanNotDelete lock on the resource group

C.Management group lock on the subscription

D.Azure Policy deny effect on the resource group

AnswerB

A CanNotDelete lock on the resource group is the correct control because it prevents deletions of the resource group itself and any resources inside it—including the VPN gateway—while still allowing read and update operations. This means administrators can resize the gateway, adjust NSG rules, and apply configuration changes, but no one can accidentally remove the entire shared boundary. It provides a targeted safeguard at the exact scope where the shared resources live.

Why this answer

The CanNotDelete lock (option B) prevents deletion of the resource group and all resources within it, while still allowing read and update operations such as resizing VMs and modifying NSG rules. This meets the requirement to block deletions during the quarter-end freeze without hindering administrative changes. ReadOnly locks would block all write operations, including resizing and NSG rule updates, which is not desired.

Exam trap

The trap here is that candidates often confuse ReadOnly locks with CanNotDelete locks, assuming that blocking all writes is necessary to prevent deletions, but ReadOnly locks also block updates like VM resizing and NSG rule changes, which are explicitly allowed in the requirement.

Why the other options are wrong

A ReadOnly lock prevents all write operations, including resizing VMs and updating NSG rules, which administrators must still be able to perform.

A management group lock on the subscription would apply to all resource groups under that management group, which is too broad for a freeze limited to a single resource group. The question specifies a shared resource group, not the entire subscription or management group.

Azure Policy deny effect can block actions based on conditions, but it is not a lock; it requires a policy definition and assignment, and it does not prevent deletion of the resource group itself unless explicitly configured. The question asks for a lock, and CanNotDelete lock directly prevents deletion.

Practice this question →

228

Multi-Selectmedium

A department has 10 subscriptions and wants the same two governance rules applied to all current and future subscriptions. One rule audits missing tags, and the other denies unapproved locations. Which two actions should the administrator take? Select two.

Select 2 answers

A.Create an Azure Policy initiative that contains both policy definitions.

B.Assign the initiative at the management group scope.

C.Assign each policy only to one resource group.

D.Use Azure RBAC instead of Policy for both requirements.

E.Create a read-only lock on each subscription.

AnswersA, B

An Azure Policy initiative (policySetDefinition) bundles multiple individual policy definitions into a single assignable unit, allowing the department to enforce both tag-auditing and allowed-location rules together. This reduces assignment overhead because one initiative assignment generates a combined compliance state for all 10 subscriptions. It also makes future policy updates easier because you only need to edit the initiative definition rather than modifying separate assignments.

Why this answer

Azure Policy Initiative allows grouping multiple policy definitions (like audit for missing tags and deny for unapproved locations) into a single set for coordinated enforcement. Assigning the initiative at the management group scope ensures it applies to all current and future subscriptions under that management group, meeting the requirement for consistent governance across all 10 subscriptions and any new ones added later.

Exam trap

The trap here is that candidates often confuse Azure Policy with Azure RBAC or resource locks, thinking they can enforce governance rules through permissions or protection mechanisms, when Policy is the only service that audits and denies resource configurations based on rules.

Why the other options are wrong

Assigning each policy only to one resource group would not apply the governance rules to all 10 subscriptions or future subscriptions, as required. The question specifies that the rules must apply to all current and future subscriptions, which requires assignment at a management group scope.

Azure RBAC controls who can access resources (authorization), not what configurations or locations are allowed. The requirements are about auditing tags and denying unapproved locations, which are governance rules enforced by Azure Policy, not RBAC.

Read-only locks prevent modifications to resources but do not enforce governance rules like tag auditing or location restrictions. The question requires policy enforcement, not resource locking.

Practice this question →

229

MCQeasy

A central audit team needs Reader access on every current and future subscription under the company hierarchy. Which scope should you use for the role assignment?

A.Management group scope

B.Subscription scope

C.Resource group scope

D.Resource scope

AnswerA

Management groups are hierarchical containers that aggregate Azure subscriptions. Assigning the Reader role at a management group scope applies that permission to every subscription within that management group, including any subscriptions added in the future. This makes it the only option here that provides centralized, inheritance-based read access across the entire environment without requiring per-subscription or per-resource assignments. It also supports governance by enabling the audit team's access to be managed in a single place.

Why this answer

A management group scope allows role assignments to be inherited by all subscriptions and resource groups within that management group hierarchy. By assigning the Reader role at the management group level, the central audit team automatically gains read access to every current subscription and any future subscription added under that management group, ensuring consistent governance without manual updates.

Exam trap

The trap here is that candidates often default to subscription scope because they think of subscriptions as the primary boundary for access control, overlooking that management groups provide a broader, hierarchical inheritance that automatically covers future subscriptions.

Why the other options are wrong

Subscription scope only grants Reader access to the selected subscription, not to future subscriptions or other subscriptions under the management group hierarchy.

Resource group scope limits access to a single resource group, not all current and future subscriptions under the company hierarchy.

Resource scope applies to a single resource, not to all current and future subscriptions, so it cannot provide Reader access across multiple subscriptions.

Practice this question →

230

Multi-Selectmedium

An administrator wants to let a help desk group start, stop, and restart virtual machines in one resource group, but the group must not be able to delete the VMs or any other resource in the group. Which two actions should the administrator take? Select two.

Select 2 answers

A.Create a custom RBAC role with only VM start, stop, restart, and read actions.

B.Assign the custom role to the help desk group at the resource group scope.

C.Assign Virtual Machine Contributor to the help desk group.

D.Apply a CanNotDelete lock to the resource group.

E.Use Azure Policy to block VM deletion and leave RBAC unchanged.

AnswersA, B

A custom role is required because the built-in roles are broader than the help desk's task. Limiting the actions keeps the permission set aligned with the actual operational need.

Why this answer

Creating a custom RBAC role with only VM start, stop, restart, and read actions ensures the help desk group can perform only those specific operations without any delete permissions. This role must be assigned at the resource group scope (Option B) to limit its effect to that resource group, preventing the group from modifying or deleting resources in other scopes. Together, these two actions fulfill the requirement precisely.

Exam trap

The trap here is that candidates often choose Virtual Machine Contributor (Option C) thinking it provides only VM management, but it actually includes delete permissions and broader resource control, or they incorrectly combine a CanNotDelete lock (Option D) with an existing role, not realizing the lock does not grant the required start/stop/restart actions.

Practice this question →

231

MCQeasy

You want to group subscriptions for Finance, HR, and Engineering so you can apply governance consistently at a higher level. What should you create?

A.Resource groups

B.Management groups

C.Tags

D.Resource locks

AnswerB

Management groups are the correct construct because they sit above subscriptions in the Azure hierarchy, enabling you to organize multiple subscriptions (finance, HR, engineering) into logical containers. Through management groups, you can enforce governance consistently across those subscriptions by applying Azure Policy, Azure RBAC roles, and cost-management settings that inherit down to all contained subscriptions. Unlike resource groups or tags, management groups create a true parent-child structure for subscriptions, not just a grouping of resources or metadata.

Why this answer

Management groups are the correct choice because they allow you to organize Azure subscriptions into a hierarchy for applying governance policies, role-based access control (RBAC), and cost management consistently across multiple subscriptions. By creating a management group hierarchy (e.g., Finance, HR, Engineering), you can assign Azure Policy initiatives or RBAC roles at the management group level, which are inherited by all subscriptions within that group. This provides a scalable and centralized governance model without needing to configure each subscription individually.

Exam trap

The trap here is that candidates often confuse resource groups (which group resources within a subscription) with management groups (which group subscriptions themselves), leading them to select resource groups as the answer for cross-subscription governance.

Why the other options are wrong

Resource groups are containers for resources within a single subscription, not for grouping multiple subscriptions. They cannot apply governance across subscriptions.

Tags are metadata applied to Azure resources for categorization, not a grouping mechanism for subscriptions. They cannot enforce governance policies across multiple subscriptions.

Resource locks prevent accidental deletion or modification of resources but do not group subscriptions for governance. Management groups are the correct construct for hierarchical subscription grouping and policy application.

Practice this question →

232

MCQeasy

Based on the exhibit, what should the administrator use to temporarily allow the legacy storage account to remain noncompliant without changing the policy for everyone?

A.Modify the policy definition so all storage accounts can use public network access.

B.Create a policy exemption for the legacy storage account or its resource group.

C.Apply a ReadOnly lock to the storage account.

D.Move the storage account to another subscription so the policy no longer applies.

AnswerB

A policy exemption is designed for approved exceptions to an existing assignment. It lets the legacy storage account remain temporarily outside the deny effect while preserving the policy for everything else. This keeps governance intact and documents the exception clearly.

Why this answer

A policy exemption allows the administrator to exclude a specific resource (the legacy storage account) or its resource group from the Azure Policy evaluation without modifying the underlying policy definition. This is the correct approach because it temporarily grants noncompliance for that resource while the policy remains enforced for all other resources, aligning with the requirement to avoid changing the policy for everyone.

Exam trap

The trap here is that candidates often confuse policy exemptions with resource locks or policy definition modifications, mistakenly thinking a ReadOnly lock or moving the resource will bypass policy evaluation, when in fact only an exemption explicitly excludes a resource from policy compliance checks.

Why the other options are wrong

Modifying the policy definition to allow public network access for all storage accounts would affect everyone, not just the legacy account. The requirement is to temporarily allow only the legacy account to be noncompliant without changing the policy for others.

Applying a ReadOnly lock prevents any changes to the storage account, but it does not exempt the account from policy compliance. The policy would still evaluate the account as noncompliant because public network access remains enabled.

Moving the storage account to another subscription would remove it from the policy's scope, but the question asks for a temporary solution without changing the policy for everyone. This approach is not temporary and could cause other compliance or management issues.

Practice this question →

233

MCQmedium

A team can already deploy virtual machines, but they want to prevent users from creating VMs unless the deployment includes an approved tag. They also want to see which existing resources do not meet the rule. What should the administrator use?

A.A custom RBAC role that removes the create action for virtual machines.

B.An Azure Policy assignment with a deny or audit effect for the tag requirement.

C.A resource lock on the resource group.

D.An Entra ID dynamic group for the VM creators.

AnswerB

Azure Policy is the correct control because the requirement is about resource compliance, not user authorization. A policy can deny deployments that do not include the approved tag and can also audit existing resources to show which ones are noncompliant. That separates governance enforcement from RBAC, which only decides who is allowed to perform actions in Azure.

Why this answer

Azure Policy with a 'deny' effect prevents creation of VMs that lack the required tag, while the 'audit' effect identifies non-compliant existing resources without blocking them. This directly addresses both requirements: enforcing the tag on new deployments and discovering which existing resources violate the rule.

Exam trap

The trap here is confusing Azure Policy (which enforces rules on resource properties like tags) with RBAC (which controls who can perform actions), leading candidates to mistakenly choose a custom role instead of the policy-based solution.

Why the other options are wrong

A custom RBAC role that removes the create action for VMs would prevent all VM creation, not enforce a tag requirement. It cannot audit existing resources for compliance, only block future actions.

A resource lock prevents deletion or modification of resources but does not enforce tagging requirements during deployment or audit existing resources for compliance.

Entra ID dynamic groups manage user membership based on attributes, not resource compliance. They cannot enforce tagging rules on VM deployments or audit existing resources for missing tags.

Practice this question →