Domain 1: Practice Q&A — Identities & Governance

Answer each question before expanding the solution. Aim for under 2 minutes per question.

Q1

Your organization requires that all Azure resources have a CostCenter tag. You want to automatically add the tag (value: Unassigned) to any resource deployed without it — without blocking the deployment.

Which Azure Policy effect should you use?

  • A. Deny
  • B. Audit
  • C. Append
  • D. DeployIfNotExists
Answer + Explanation

Correct: C — Append

Why C: Append adds properties (including tags) to a resource request during creation or update, without blocking it. The deployment goes through; the tag is automatically included.

Why not A: Deny would block any deployment missing the tag — that contradicts the "without blocking" requirement.

Why not B: Audit only logs non-compliance. It doesn't add the tag.

Why not D: DeployIfNotExists deploys a separate related resource if it doesn't exist — it's for things like deploying a diagnostic settings resource alongside a VM, not for adding properties to the resource being created.

Exam tip: "Add a tag automatically without blocking" = Append. If the requirement is to block deployments without the tag, use Deny (possibly combined with Modify for remediation of existing resources).

Q2

A user has the Contributor role assigned at the subscription level. They attempt to delete a resource lock on a resource group. The operation fails with a 403 error. What is the reason?

  • A. The lock was created by a Policy, which cannot be deleted via RBAC
  • B. The Contributor role does not include Microsoft.Authorization/locks/*
  • C. Subscription-level RBAC does not inherit to resource groups
  • D. The user must have the Global Administrator role in Entra ID to delete locks
Answer + Explanation

Correct: B — Contributor lacks Microsoft.Authorization/locks/*

Why B: The Contributor role explicitly excludes any Microsoft.Authorization/* actions. Deleting a lock requires Microsoft.Authorization/locks/delete, which belongs to Owner and User Access Administrator only.

Why not A: Locks are not created or managed by Policy — they are a separate feature (Microsoft.Authorization/locks). Policy manages Microsoft.Authorization/policyAssignments.

Why not C: Subscription-level RBAC absolutely inherits downward to RGs and resources. That's how RBAC scope hierarchy works.

Why not D: Global Administrator is an Entra ID role, not an Azure RBAC role. It doesn't grant any Azure resource permissions unless explicitly elevated.

Q3

A VM is regularly deleted and recreated as part of a blue-green deployment pipeline. The VM needs to access Azure Key Vault using a managed identity, and its Key Vault access policy must remain intact across recreations.

Which identity type should you configure?

  • A. System-assigned managed identity
  • B. User-assigned managed identity
  • C. Service principal with a client certificate
  • D. Service principal with a client secret
Answer + Explanation

Correct: B — User-assigned managed identity

Why B: A user-assigned managed identity has its own lifecycle, independent of any VM. When the VM is deleted and recreated, you attach the same user-assigned identity — its Object ID never changes, so Key Vault access policies referencing it remain valid.

Why not A: System-assigned identity is tied to the VM's lifecycle. When the VM is deleted, the identity is deleted, and a new Object ID is created on recreation. All Key Vault access policies referencing the old Object ID must be manually re-added.

Why not C/D: Service principals require credential management (certificate expiry, secret rotation). Managed identities are Azure-managed — no credentials to handle.

Exam tip: "Survives resource recreation" or "shared across multiple VMs/services" = user-assigned managed identity.

Q4

Your company has three Azure subscriptions: Dev, Staging, and Production. You must enforce a policy preventing creation of any VM with more than 4 vCPUs in all three subscriptions with minimum administrative effort.

What is the most efficient approach?

  • A. Create a policy assignment in each of the three subscriptions
  • B. Move all subscriptions into a management group and assign the policy once to the management group
  • C. Create a custom RBAC role that prevents VM creation and assign it to all subscriptions
  • D. Use Azure Blueprints to create one blueprint per subscription
Answer + Explanation

Correct: B — Management group with a single policy assignment

Why B: Policy assignments at a management group scope inherit to all subscriptions underneath. One assignment covers all three — and any future subscriptions added to the group automatically inherit it.

Why not A: Technically correct but inefficient — three separate assignments to maintain. Adding a fourth subscription requires another manual assignment.

Why not C: RBAC is not the tool for enforcing resource properties like VM size. Custom RBAC roles cannot filter on resource attributes (size, SKU, etc.) — that's what Policy does.

Why not D: Blueprints can assign policies but are designed for full environment setup (RBAC + Policy + ARM templates together). Using Blueprints just to assign one policy to three subscriptions is over-engineering.

Exam tip: "Enforce across multiple subscriptions with minimum effort" = management group + policy assignment.

Q5

A developer has the Contributor role on a resource group. They need to grant a new contractor the Reader role on the same resource group. What is the minimum additional permission required?

  • A. Owner at the subscription level
  • B. User Access Administrator at the resource group level
  • C. Security Administrator in Entra ID
  • D. The Contributor role is sufficient — they can assign any role within their scope
Answer + Explanation

Correct: B — User Access Administrator at the resource group level

Why B: Assigning roles requires Microsoft.Authorization/roleAssignments/write. The minimum role that includes this is User Access Administrator — and since the assignment only needs to happen at the RG level, the RG scope is sufficient (least privilege).

Why not A: Owner at the subscription level would work, but it grants far more than necessary (Owner access to the entire subscription, not just the RG). The question asks for minimum permission.

Why not C: Security Administrator is an Entra ID role — it has no Azure RBAC assignment rights.

Why not D: Contributor explicitly excludes Microsoft.Authorization/* actions — it cannot assign roles. This is the most common wrong answer chosen by candidates.

Q6

A ReadOnly lock is applied to a storage account. A user with the Owner RBAC role attempts to list the storage account's access keys. The operation fails. Why?

  • A. Owners cannot list access keys — they need the Storage Account Key Operator Service Role
  • B. Listing access keys is classified as a write operation, which ReadOnly locks block
  • C. Access keys are managed by Entra ID, not by Azure RBAC
  • D. The ReadOnly lock was applied at a higher scope and cascades down
Answer + Explanation

Correct: B — listKeys is classified as a write operation on the management plane

Why B: The listKeys action (Microsoft.Storage/storageAccounts/listKeys/action) is classified as a write operation because it retrieves credentials that grant full data-plane access. A ReadOnly lock blocks all write actions on the management plane — including listKeys, even for Owners.

Why not A: Owners can list access keys under normal circumstances (no lock). The Storage Account Key Operator Service Role is a real role but is not relevant here.

Why not C: Access keys are Azure resource management objects, not Entra ID objects.

Why not D: The question says the lock is applied directly on the storage account — no cascade needed. But even if inherited, the result is the same.

Exam tip: ReadOnly lock on storage = cannot list keys. ReadOnly lock on VM = cannot start/stop the VM. ReadOnly is more restrictive than it sounds.

Q7

Which of the following statements about the relationship between Azure Policy and Azure RBAC is TRUE?

  • A. A Deny Policy is overridden by an Owner RBAC role assignment
  • B. RBAC controls what a principal can attempt; Policy controls whether the attempt succeeds
  • C. Azure Policy and Azure RBAC are the same underlying system with different UIs
  • D. You must be a Global Administrator in Entra ID to create Policy assignments
Answer + Explanation

Correct: B — RBAC and Policy are complementary, sequential systems

Why B: The request flow is:

  1. RBAC check — does the principal have permission to attempt this action? If not → denied.
  2. Policy check — does the resource configuration comply with policies? If a Deny policy matches → denied.

Both must pass. Policy can block even an Owner.

Why not A: Policy Deny effect is not overridden by any RBAC role — not even Owner. They are separate systems; RBAC cannot bypass Policy.

Why not C: They are completely different systems with different APIs, resources, and scope models.

Why not D: Creating Policy assignments requires the Resource Policy Contributor Azure RBAC role (or Owner) — not Entra Global Admin.

Q8

You have an Entra ID user with the User Administrator role. This user has no Azure RBAC assignments. They attempt to create a new virtual machine in a subscription. What happens?

  • A. They succeed — User Administrator is a high-privilege Entra role
  • B. They fail — Entra ID roles do not grant any Azure resource permissions
  • C. They succeed — Entra roles automatically grant Contributor to all subscriptions
  • D. They fail — they need to be a Subscription Owner, which requires Global Admin approval
Answer + Explanation

Correct: B — Entra ID roles have no Azure resource permissions

Why B: User Administrator is an Entra ID role — it grants permission to manage directory objects (users, groups, passwords). It has zero Azure resource permissions. Creating a VM requires at minimum the Contributor Azure RBAC role on the target subscription or resource group.

Why not A/C: Entra roles and Azure RBAC roles are completely separate. No Entra role automatically grants any Azure RBAC permission (unless the Global Admin uses the Entra elevation toggle, which gives User Access Administrator on Azure subscriptions).

Why not D: There is no "Global Admin approval" process for subscription ownership — it's just an Azure RBAC assignment.

This is the #1 exam trap in Domain 1. Whenever a question presents an Entra ID role and asks about Azure resource access, the Entra role provides nothing unless an Azure RBAC role is also assigned.

Q9 — Scenario

Your organization is acquiring a company. You need to give their IT team read-only access to all resources in your three production subscriptions with minimum effort. You also want any new production subscriptions created in the future to automatically have this access.

Which combination of steps achieves this?

  • A. Assign Reader role to the IT team group in each of the three subscriptions; manually repeat for future subscriptions
  • B. Create a management group containing all production subscriptions; assign the Reader role to the IT team group at the management group scope
  • C. Add the IT team users as Guest users and assign them Subscription Reader in Entra ID
  • D. Create an Azure Blueprint that assigns the Reader role and assign it to each subscription
Answer + Explanation

Correct: B — Management group + Reader at management group scope

Why B: Management group RBAC inherits to all current and future subscriptions placed under it. One assignment covers all three subscriptions today and any new production subscriptions added tomorrow.

Why not A: Works but requires manual re-assignment for every new subscription. Doesn't satisfy "automatically included future subscriptions."

Why not C: "Subscription Reader in Entra ID" doesn't exist — Entra roles don't map to Azure subscription access. Guest users still need Azure RBAC assignments.

Why not D: Blueprints work but are heavier than needed for a single RBAC assignment. Also, Blueprint assignments are per-subscription, not inherited automatically for future subscriptions added later.

Q10 — Tricky

You assign a Deny policy at the subscription level that blocks creation of public IP addresses. A user with Owner role on a resource group tries to create a VM with a public IP. What is the result?

  • A. The VM and public IP are both created — Owner overrides Policy
  • B. Both the VM and public IP creation fail
  • C. The public IP creation is blocked, but the VM is created without a public IP
  • D. The VM creation fails; the public IP creation succeeds
Answer + Explanation

Correct: C — Public IP is blocked; VM creation succeeds without it

Why C: The Deny policy targets Microsoft.Network/publicIPAddresses — only that resource type is blocked. The VM itself is Microsoft.Compute/virtualMachines, which is not covered by this policy. Azure Resource Manager evaluates each resource deployment separately — the VM succeeds; the public IP fails.

Why not A: Owner does not override Policy. Policy and RBAC are independent systems; RBAC allows the attempt, Policy evaluates the resource.

Why not B: The VM itself is not a public IP — it's a separate resource type. The policy only blocks publicIPAddresses.

Why not D: The VM deployment succeeds (it's not covered by the policy). The IP fails because it is directly targeted.

Exam tip: Azure Policy targets specific "type" values. A policy targeting publicIPAddresses doesn't block the VM — it only blocks the public IP resource itself. The VM just won't have a public IP attached.