Courseiva

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Your company is designing a governance strategy for Azure. You need to ensure that all resource groups in a subscription are created with a specific naming convention and mandatory tags. Which THREE services or features should you use together? (Choose three.)

⚠ Common exam trap

A common mix-up: candidates confuse Azure RBAC (which controls permissions) with Azure Policy (which enforces rules on resource properties), or they overlook that Blueprints is the orchestration layer that bundles Policy, RBAC, and templates together to enforce governance at scale.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Azure Blueprints

Azure Blueprints is correct because it enables the orchestrated deployment of Azure Policy, RBAC, and resource templates as a single composable artifact. By defining a blueprint that includes a policy for naming conventions and mandatory tags, you can enforce these requirements consistently across all resource groups within a subscription or management group hierarchy.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Azure RBAC

    Why it's wrong here

    Azure RBAC governs identity-based access to Azure resources via role assignments, defining who can perform actions against a resource's control plane. It does not inspect or enforce resource attributes such as naming conventions or tag compliance; those are metadata and configuration concerns. RBAC can delegate permission to apply policies or tags, but it cannot itself mandate a naming pattern or require tags on resource groups. Thus, while RBAC is essential for security, it is not a governance mechanism for enforcing naming/tagging rules.

  • ✓

    Azure Blueprints

    Why this is correct

    Azure Blueprints packages Role Assignments, Policy Assignments, Azure Resource Manager templates, and resource groups into a single, versionable, assignable artifact. When assigned to a subscription, the included policy assignments automatically enforce naming patterns and tag requirements, while bundled ARM templates can deploy resources with consistent tags. Blueprints maintain a tracking record of assignments and allow a governance team to orchestrate compliance across many subscriptions, making it a holistic governance solution. Because it can directly embed Azure Policy definitions, it is a correct answer for enforcing naming and tag governance.

  • ✓

    Management Groups

    Why this is correct

    Management Groups sit above subscriptions in the Azure hierarchy, enabling enterprise-wide governance by applying Azure Policy and RBAC assignments at a high level so they are inherited by every subscription and resource group underneath. A policy assigned to a management group that requires specific naming patterns or tag keys will be enforced across all child scopes. Management Groups also support multiple hierarchy levels, letting governance teams segment production and non-production environments while maintaining baseline rules. This hierarchical inheritance makes Management Groups a correct mechanism for enforcing naming and tagging governance.

  • ✓

    Azure Policy

    Why this is correct

    Azure Policy is the native service for creating, assigning, and managing rules over Azure resources, evaluating compliance against resource properties. It includes predefined definitions for requiring tags, appending tag values, and using the pattern constraint to validate resource names, with custom definitions available for unique organizational needs. Policies apply at the management group, subscription, or resource group scope and can be bundled into initiatives to group related rules. Azure Policy is the core enforcement engine for naming conventions and tag governance, either standalone or through Blueprints.

  • ✗

    Resource Locks

    Why it's wrong here

    Resource locks (CanNotDelete and ReadOnly) protect resources from accidental deletion or modification by denying lifecycle operations such as delete and write at the management group, subscription, resource group, or resource scope. They do not validate or enforce naming or tagging rules; a lock only blocks operations and does not inspect resource metadata like tag existence or naming patterns. In fact, a ReadOnly lock can prevent Azure Policy's modify effect from adding required tags if remediation runs, because the resource cannot be changed. Therefore, Resource Locks are not a governance tool for naming/tagging requirements.

Quick reference

Access Control Model Comparison

ModelAcronymWho Controls Access?Best For
Discretionary Access ControlDACResource ownerSmall teams, file shares
Mandatory Access ControlMACSystem / security labelsClassified govt / military
Role-Based Access ControlRBACAdministrator (via roles)Enterprise environments
Attribute-Based Access ControlABACPolicy engine (user + resource attributes)Fine-grained, dynamic policies
Rule-Based Access ControlRuBACSystem rules / ACLsFirewall rules, network ACLs

About these practice questions

Courseiva writes every AZ-305 question from scratch — 795 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.