AZ-305 - Design Identity, Governance, and Monitoring Solutions (27% of the exam) - Section 1.3

Design governance solutions including management groups, Azure Policy, and landing zones.

Organise subscriptions into a management group hierarchy and enforce consistent rules through Azure Policy initiatives. Design landing zones to provide a governed, repeatable foundation and distinguish when Azure Blueprints adds value over Policy alone.

management groupsAzure Policyinitiativeslanding zonesAzure Blueprints

Practice question for this objective

Free sampleDesign Identity, Governance, and Monitoring Solutionsmedium

A platform team writes Azure Policy definitions and needs the narrowest built-in role that lets a designated identity assign those policies at a management group scope. The role must NOT grant the ability to create, rename, move, or delete management groups, and must NOT grant the ability to assign access (other RBAC roles). Which built-in role is the documented best fit?

AOwner role on the parent management group
BManagement Group Contributor
CUser Access Administrator
DResource Policy Contributor Correct

To delegate only policy assignment at a management group, Resource Policy Contributor is the documented narrowest fit. The management groups documented roles table grants Resource Policy Contributor the Assign Policy action and nothing else: no Create, Rename, Move, Delete, Assign Access, or Read of the management group itself. That is the exact intersection of capabilities the scenario requires. The other built-in roles either over-grant by including hierarchy-management or access-assignment rights, or under-grant by giving no policy authority.

Why A is wrong: Owner is the broadest role - it grants Create, Rename, Move, Delete, Assign Access, Assign Policy, and Read - which violates the requirement to NOT grant access assignment or hierarchy management.

Why B is wrong: Management Group Contributor grants Create, Rename, Move, and Delete on management groups, which the scenario explicitly forbids; it also does not include Assign Policy.

Why C is wrong: User Access Administrator grants Assign Access plus Assign Policy, which over-grants access management beyond what the scenario allows.

Why D is correct: Correct. The management groups documented roles table grants Resource Policy Contributor the Assign Policy action and nothing else: no Create, Rename, Move, Delete, Assign Access, or Read of the management group itself.

See more AZ-305 practice questions, answers explained.

Exam traps in Design Identity, Governance, and Monitoring Solutions

Answers that look right on this material and are not. Each one is a distractor from a different question in the AZ-305 bank for this domain.

Tenant, management group, subscription, and resource group only.
Why it is wrong: Tenant is not an RBAC scope; tenant-wide controls belong to the root management group, and resource-level scope is missing here.
Assign the permissive policy at the subscription scope; the more specific scope wins automatically over parent denies.
Why it is wrong: Azure Policy is an explicit deny system; a permissive child assignment cannot override a parent deny.
Agent identities are exempt from Conditional Access policy because they run autonomously without users.
Why it is wrong: Agent identity blueprints apply Conditional Access rules; agents are not exempt.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.