AZ-305 Practice Question: Design identity, governance, and monitoring solutions
Which THREE conditions should be met to implement a successful Azure landing zone for a new enterprise subscription? (Choose three.)
⚠ Common exam trap
Many candidates confuse optional security tools like Microsoft Sentinel or dedicated tenants as mandatory prerequisites, when the Azure landing zone's success hinges on governance structure (management groups), network connectivity (hub-spoke topology), and automation (subscription vending).
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
✓
A management group hierarchy that separates environments.
A management group hierarchy that separates environments (e.g., production, non-production, and management) is a core design principle of an Azure landing zone. It enables policy inheritance, role-based access control (RBAC) isolation, and cost tracking across different workloads, aligning with the Cloud Adoption Framework's governance best practices.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
A dedicated Microsoft Entra ID tenant.
Why it's wrong here
A dedicated Entra ID tenant would fragment identity management and break the trust boundary that already exists in the organization. The Azure landing zone reference architecture deliberately reuses an existing tenant to centralize conditional access, RBAC, and policy across all subscriptions. Standing up a new tenant forces cross-tenant governance and increases administrative overhead without any architectural benefit.
- ✓
A management group hierarchy that separates environments.
Why this is correct
Management groups form the backbone of governance in a landing zone by enabling role assignments and Azure Policy to be inherited down to the subscription level. Separating environments (such as production, non-production, and shared) into distinct hierarchy branches allows cloud admins to enforce different compliance and cost controls per environment. This hierarchy is a prerequisite in the Azure landing zone accelerator because it provides the structural placement point for policy and RBAC.
- ✗
Microsoft Sentinel enabled for security monitoring.
Why it's wrong here
Microsoft Sentinel is an optional SIEM service that can be enabled after deployment for security event correlation and threat hunting, but it is not a conditional requirement for the landing zone itself. The accelerator includes native capabilities like Azure Policy and Defender for Cloud to establish a security baseline without Sentinel. Requiring Sentinel would force high cost and complexity even for environments that only need basic monitoring, so its absence doesn't block a successful implementation.
- ✓
A defined network topology with connectivity to on-premises.
Why this is correct
A defined network topology, typically hub-and-spoke, is fundamental for the landing zone because it provides predictable egress, inspection, and identity-aware routing to on-premises resources. Connectivity to on-premises via ExpressRoute or site-to-site VPN is necessary when workloads must integrate with existing infrastructure, DNS, or Active Directory. This design ensures that firewall rules, network security groups, and routing tables are consistently applied across all landing zone subscriptions.
- ✓
A subscription vending process to automate creation.
Why this is correct
Subscription vending is the automated workflow that provisions a new subscription and attaches the correct management group, policy, RBAC, and network connection as part of the landing zone self-service model. This process removes the manual creation step that often leads to policy drift or subscriptions that are omitted from governance. It also enables workload teams to request subscriptions quickly while the platform team retains control over guardrails, making this a core architectural requirement in enterprise-scale landing zones.
Quick reference
Access Control Model Comparison
| Model | Acronym | Who Controls Access? | Best For |
|---|---|---|---|
| Discretionary Access Control | DAC | Resource owner | Small teams, file shares |
| Mandatory Access Control | MAC | System / security labels | Classified govt / military |
| Role-Based Access Control | RBAC | Administrator (via roles) | Enterprise environments |
| Attribute-Based Access Control | ABAC | Policy engine (user + resource attributes) | Fine-grained, dynamic policies |
| Rule-Based Access Control | RuBAC | System rules / ACLs | Firewall rules, network ACLs |
Go deeper
Related to this question
Learn chapter
Key Vault Architecture for Secrets Management
Key term
Subscription Design
Subscription Design is the structured approach to organizing and managing Azure subscriptions to align with business requirements, governance policies, and cost management.
Key term
Management Group Design
A logical hierarchy of Azure management groups that organizes subscriptions and applies governance policies consistently across an organization.
About these practice questions
This AZ-305 question is part of Courseiva's 795-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
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.