AZ-305 Design identity, governance, and monitoring solutions: 470 practice questions

12 of the 470 Design identity, governance, and monitoring solutions questions in the Certsqill AZ-305 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-305? Take the free 5-min readiness check →

1. Pass-through Authentication with Seamless SSO: Which hybrid identity method meets all three requirements?

1. Pass-through Authentication (PTA) with Seamless SSO ✓

   PTA validates passwords directly against on-premises AD using a lightweight agent — no password hashes are stored in Azure AD. Authentication is real-time, so disabling an on-premises account immediately prevents sign-in (unlike PHS where stale hashes persist for up to 2 minutes). Seamless SSO provides transparent sign-in from domain-joined machines.
2. Password Hash Synchronization (PHS) with Seamless SSO

   PHS synchronizes hashed password hashes (a hash of the NTLM hash) to Azure AD. While the original password is not stored in plaintext, password hashes ARE stored in the cloud — violating the requirement. Also, PHS has up to a 2-minute delay before a disabled account's hash is updated.
3. Active Directory Federation Services (AD FS) with Azure AD Connect

   AD FS also validates passwords against on-premises AD and doesn't store hashes in the cloud. However, AD FS requires significant infrastructure (AD FS farms, WAP servers, certificates) — more complex and costly than PTA which provides the same security guarantees with just lightweight agents.
4. Azure AD B2B with guest accounts for each employee

   B2B is for external partner/vendor access, not for integrating your own organization's employees. It doesn't synchronize on-premises AD accounts and cannot enforce on-premises account disablement.

PTA validates credentials against on-premises AD in real-time, stores no password data in the cloud, and reflects account disablement immediately.

2. Partner portal: Which Azure AD capabilities should be used for each application respectively?

1. Partner portal: Azure AD B2C with custom user flows; Customer portal: Azure AD B2B guest invitation model

   This reverses the appropriate tools. B2C would force partners to abandon their existing corporate identities and create new consumer accounts, while B2B guest invitations cannot scale to millions of unknown consumers signing in with Google or Facebook.
2. Partner portal: Azure AD B2B (guest invitations); Customer portal: Azure AD B2C (consumer identity platform) ✓

   B2B federation allows external partners to sign in with their existing corporate identities (Azure AD, Google Workspace, etc.) via guest user invitations. B2C is a separate consumer identity management service that supports millions of users, social identity providers (Google, Facebook, Apple), local accounts, and custom user journeys — designed for customer-facing applications.
3. Both applications: Azure AD B2B guest invitations, since each scenario depends on collaboration with external users

   B2B is designed for organization-to-organization collaboration with known partners. It is not built for millions of consumer accounts with social login, and guest accounts do not scale to consumer volume or support Google/Facebook identity providers natively.
4. Both applications: Azure AD B2C tenants, since B2C can federate corporate identities and social logins alike

   Using B2C for the partner portal would lose corporate identity federation — partners would create new B2C local accounts instead of using their existing corporate identity. B2B is the right tool for known organizational partners with existing corporate identities.

B2B is for corporate partner federation using existing organizational identities; B2C is the consumer identity platform supporting social logins at scale.

3. Root MG → Production MG → Prod subscriptions: Which management group hierarchy design best meets these require

1. Separate Azure tenants for Production and Development, each with its own Azure AD, duplicated policy sets, and their own independent subscription owners

   Separate tenants provide strong isolation but add heavy overhead: duplicate identity management, separate Azure AD, duplicated policies, and no easy resource sharing. Management groups within one tenant already deliver policy inheritance that subscription owners cannot bypass, without this complexity.
2. Root MG with a blanket Deny policy for every resource type, where subscription owners raise Azure Blueprints exception requests whenever a workload actually needs to deploy

   A root-level Deny for all resources blocks everything and turns governance into constant exception handling, which is operationally unworkable. The exception-based model inverts good design — allowlists applied at appropriate hierarchy levels are correct.
3. Root MG → Production MG (PCI policies locked) → Prod subscriptions; Root MG → NonProd MG → Dev MG (contributor access) + Sandbox MG (Owner access, no policies) ✓

   Management Group policies are inherited downward and cannot be overridden by subscription owners. Placing PCI compliance policies at the Production MG level ensures they apply to all production subscriptions regardless of subscription owner actions. Dev and Sandbox are under NonProd with progressively fewer restrictions. Sandbox can be completely permissive.
4. A single management group holding all subscriptions, with the CISO team manually attaching Azure Policy assignments to each individual subscription as it is onboarded to the tenant

   Per-subscription manual assignment requires ongoing maintenance as subscriptions grow and can be inadvertently removed by teams holding subscription management rights. Hierarchy-based inheritance at the MG level is far more scalable and tamper-resistant.

Hierarchical management groups allow policy inheritance that subscription owners cannot override — separate MGs for Prod (strict policies) vs NonProd (permissive) is the correct design.

4. Secure Transfer: Which policy effects implement each requirement respectively?

1. Secure Transfer: Deny; Non-approved regions: Deny; Missing tags: Audit for reporting

   Deny on Secure Transfer blocks new storage account creation without the setting but cannot remediate existing non-compliant accounts. The requirement explicitly states 'auto-remediated,' which requires Modify or DeployIfNotExists.
2. Secure Transfer: AuditIfNotExists; Non-approved regions: Append; Missing CostCenter tag: Disabled

   AuditIfNotExists checks for related resources' absence (like diagnostics settings), not resource properties. Append adds values to properties but cannot block operations — non-approved region VMs would still be created. Disabled turns the policy off entirely.
3. Secure Transfer: Deny; Non-approved regions: Deny; Missing CostCenter tag: Deny on resource groups

   Deny blocks new resource creation but cannot remediate existing storage accounts, and applying Deny to the CostCenter tag would block resource-group operations for a requirement that only needs reporting. This is overly restrictive and misses auto-remediation.
4. Secure Transfer: Modify or DeployIfNotExists; Non-approved regions: Deny; Missing tags: Audit ✓

   Modify (or DeployIfNotExists) auto-remediates existing non-compliant resources. Deny blocks resource creation at deployment time — VMs in non-approved regions never get created. Audit logs compliance violations without blocking, suitable for reporting tags without disrupting operations.

Modify/DeployIfNotExists auto-remediates; Deny blocks at creation time; Audit reports without blocking — match the effect to the remediation requirement.

5. Configure Azure AD PIM: Which solution implements this?

1. Configure Azure AD PIM: assign Global Administrator as 'eligible' (not active), set activation policy requiring MFA + justification, enable access reviews on a monthly schedule ✓

   PIM eligible assignments mean the role is not active — users must activate it on-demand. Activation policies can require MFA verification and a business justification text. Access reviews in PIM assess whether eligible assignments are still needed. All activations are audited in the PIM audit log.
2. Use Azure AD Conditional Access with a named-location policy so Global Admin actions are permitted only from the corporate office network, enforced through an MFA grant control

   Conditional Access restricts where and how authentication occurs but does not remove standing role assignments or provide just-in-time access. The users would remain permanent Global Admins — only their sign-in location would be restricted.
3. Assign Global Administrator permanently but enable an Azure AD sign-in risk policy that forces MFA whenever Identity Protection flags a login as risky, then review the sign-in logs each month

   Permanent active Global Admin assignments violate the first requirement. Sign-in risk MFA protects against compromised accounts but does not prevent standing privileged access. PIM eligible assignments address the least-privilege requirement.
4. Create a dedicated break-glass account holding Global Admin, store its credentials in Azure Key Vault, and log every credential retrieval so all elevated use is captured for the monthly review

   Break-glass emergency accounts are a valid complement to PIM for true emergencies, but they are not a substitute for routine privileged access management. Regular twice-monthly tasks should use PIM eligible assignments, not shared emergency credentials.

PIM eligible assignments + activation policy (MFA + justification) + monthly access reviews implement just-in-time privileged access with audit trail.

6. Create a custom RBAC role with only the required VM: Which approach follows the principle of least privilege?

1. Assign the built-in 'Owner' role at the resource group scope and rely on the developers to self-govern the permissions they actually use

   Owner grants full control including the ability to assign roles to others — far beyond what's needed. Trusting self-governance is not a security control. Least privilege requires granting the minimum permissions for the task.
2. Create a custom RBAC role with only the required VM actions (Microsoft.Compute/virtualMachines/*) and assign it at the resource group scope ✓

   Custom roles allow defining exactly the required permissions. Using Microsoft.Compute/virtualMachines/*/action covers deploy, size management, start/stop/restart. Assigning at resource group scope limits the role to only that resource group. This grants the minimum permissions needed — no network or storage actions included.
3. Assign the built-in 'Contributor' role at the resource group scope and layer Azure Policy Deny rules to block all network and storage operations by the team

   Contributor at resource group scope grants full access to create any resource type. Azure Policy can restrict what's deployed but is designed for governance, not fine-grained RBAC enforcement. Deny policies don't cleanly substitute for proper role scoping.
4. Assign the built-in 'Virtual Machine Contributor' role at the subscription scope so the team can manage every virtual machine they deploy across the environment

   Virtual Machine Contributor includes permissions to manage networks and storage accounts (since VMs depend on them). Assigning at subscription scope also grants access to all resource groups in the subscription, violating least-privilege.

Custom RBAC role with only VM actions assigned at the resource group scope implements least-privilege — no network or storage permissions, limited to the specific resource group.

7. Policy 1: Require MFA when device compliance state is 'not: Which Conditional Access design implements all thr

1. A single Conditional Access policy combining all three conditions, relying on OR logic between the device-compliance, join-state, and location checks so one rule toggles MFA, grant, or block for each incoming sign-in as appropriate

   Conditional Access conditions within a single policy use AND logic (all conditions must match for the policy to apply), not OR. One policy cannot express three different scenarios — separate policies targeting different conditions are required.
2. Require every user to enroll in the Microsoft Authenticator app, which performs on-device compliance evaluation and geographic checks during each sign-in to decide when MFA or an outright block should apply to a given sign-in

   Microsoft Authenticator provides passwordless and MFA authentication but does not enforce device compliance state or geographic blocking. Those are Conditional Access policy functions, not authenticator app capabilities.
3. Policy 1: Require MFA when device compliance state is 'not compliant or not registered'; Policy 2: Grant access when device is Hybrid Azure AD Joined AND compliant; Policy 3: Block access when sign-in location is outside company countries named location ✓

   CA Policy 1 targets unmanaged devices (not compliant/not hybrid-joined) → require MFA. Policy 2 grants without MFA to Hybrid Azure AD Joined + compliant devices. Policy 3 blocks all sign-ins from non-operational countries using a named location excluding company countries. All three operate independently and combine correctly.
4. Enable Azure AD Identity Protection with medium- and high-risk sign-in and user risk policies to cover the managed-device, unmanaged-device, and out-of-country requirements through risk scoring rather than through explicit device compliance or named-location conditions

   Identity Protection addresses sign-in and user risk (anomalous authentication behavior), not device compliance state or geographic location. Conditional Access with named locations and device compliance conditions is required for these specific requirements.

Three separate Conditional Access policies — device-based MFA, compliant device grant without MFA, and named location block — implement all three requirements independently.

8. Azure Blueprints: Which tool best implements repeatable landing zone deployments?

1. Azure Resource Manager deployment scripts that run PowerShell to create every resource group, RBAC assignment, policy, and network baseline programmatically

   Deployment scripts (running PowerShell/CLI inside ARM deployments) can create resources but require custom code for versioning, assignment tracking, and compliance reporting. Blueprints provide these capabilities natively as one auditable unit.
2. ARM templates in Bicep with nested templates per component, deployed through an Azure DevOps pipeline that assembles each new landing zone

   ARM/Bicep templates can deploy resources and policies, but they cannot natively assign RBAC roles and track compliance as a unified, versioned blueprint. Pipeline-based deployment works but lacks Blueprints-native versioning, assignment tracking, and subscription-level RBAC with policy linkage.
3. Azure Policy initiatives using DeployIfNotExists effects that automatically provision any missing landing-zone components whenever a subscription has drifted out of compliance

   Policy initiatives can enforce and remediate resource configurations but cannot deploy resource group structures or RBAC assignments. Policies respond reactively to non-compliance rather than proactively provisioning a full landing zone.
4. Azure Blueprints, which packages resource templates, policy assignments, and RBAC assignments into a single versioned artifact deployable as one unit ✓

   Azure Blueprints orchestrate the deployment of resource groups, ARM templates (for network config), RBAC role assignments, and Azure Policy assignments in a single assignment. Blueprints track which subscriptions were assigned which blueprint version, enabling auditable drift detection. Assignments can be locked to prevent modification.

Azure Blueprints package RGs, ARM templates, RBAC assignments, and Policy assignments into a single versioned, auditable unit — ideal for repeatable landing zone deployment.

9. Central Log Analytics workspace with RBAC table-level: Which monitoring architecture supports all three requir

1. Central Log Analytics workspace with RBAC table-level access per business unit; Diagnostic Settings on all resources pointing to the central workspace; 2-year data retention configured at workspace level ✓

   A central Log Analytics workspace aggregates all logs from all subscriptions. Table-level RBAC (or resource-based access) limits BU teams to their own resources' logs. Diagnostic Settings are configured per resource (or via Azure Policy DeployIfNotExists) to forward to the central workspace. Retention can be set to 2 years at the workspace level.
2. Deploy per-application Azure Application Insights instances and surface them through one central Azure Dashboard that gives every business unit cross-subscription visibility, with 2-year retention set on each instance

   Application Insights is for application telemetry, not infrastructure resource monitoring. Azure Dashboards aggregate metric views but don't provide audit log retention or fine-grained RBAC over the underlying log data per business unit.
3. Adopt Microsoft Defender for Cloud as the single monitoring platform, using its built-in 2-year log retention and per-subscription access to serve both the business units and the security team's audit needs

   Defender for Cloud provides security posture and recommendations but is not a general-purpose observability platform. It doesn't provide custom metric monitoring or business unit-specific log access, and long-term log retention requires Log Analytics.
4. Provision one Log Analytics workspace per subscription and rely on Azure Monitor cross-workspace KQL queries to assemble the operations team's single-pane view across all fifty subscriptions

   50 separate workspaces create management overhead and split data that must be queried together. Cross-workspace queries work but are complex and slower. A centralized workspace is simpler and more cost-effective for the described requirements.

Centralized Log Analytics with resource-based RBAC, diagnostic settings for all subscriptions, and 2-year retention provides single-pane visibility with access control.

10. Enable Defender CSPM: Which Defender for Cloud configuration achieves all three?

1. Enable the Microsoft Defender for Cloud free tier with every feature switched on across the storage, SQL, and Kubernetes resource types, relying on its Secure Score

   The free tier (Foundational CSPM) provides basic security recommendations and Secure Score but does NOT include threat detection for databases, containers, or runtime protection. These require specific paid Defender plans.
2. Enable Defender CSPM (for Secure Score/posture); Enable Defender for Databases (SQL threat detection); Enable Defender for Containers (AKS image scanning and runtime protection) ✓

   Defender CSPM provides continuous security assessment and Secure Score across all resources. Defender for Databases enables threat detection for SQL injection, anomalous queries, and brute-force attacks on Azure SQL. Defender for Containers provides AKS image vulnerability assessment and runtime threat detection.
3. Enable Defender for Servers on all virtual machines and Defender for App Service on the web apps, expecting those plans to cover posture, SQL threat detection, and container runtime protection together

   Defender for Servers and App Service protect VMs and web applications respectively. They don't provide SQL threat detection or Kubernetes runtime protection. The correct plans must match the resource types being protected.
4. Deploy Microsoft Sentinel as the single security solution, ingesting SQL, container, and posture signals so its analytics rules deliver both the Secure Score and the required threat detection alike

   Microsoft Sentinel is a SIEM/SOAR for log aggregation and threat correlation. It can ingest Defender for Cloud alerts but doesn't perform the real-time threat detection itself for SQL or container workloads. Defender plans are required as detection sources.

Defender CSPM for posture/Secure Score; Defender for Databases for SQL threat detection; Defender for Containers for AKS image scanning and runtime protection.

11. Enforce a mandatory 'TeamName' tag on all resources via: Which tagging and cost management approach enables ac

1. Create one Azure subscription per application team so each team's spend lands on its own billing boundary, then migrate all existing shared resources into the matching subscription for clean isolation

   Per-team subscriptions would provide clean cost isolation but require migrating all existing resources and creating new subscriptions — contradicting the question's single shared subscription context. Tags are the appropriate mechanism for shared environments.
2. Rely on Azure Advisor recommendations to identify each team's underutilized resources and distribute the monthly bill proportionally to those utilization findings across the twenty application teams

   Azure Advisor identifies optimization opportunities (right-sizing, unused resources) but does not allocate costs to teams. Cost allocation requires resource tags and Azure Cost Management, not Advisor's utilization findings.
3. Enforce a mandatory 'TeamName' tag on all resources via Azure Policy (Deny effect), then use Azure Cost Management cost allocation with tag-based grouping for chargeback reports ✓

   A Deny policy ensures every resource is tagged with TeamName at creation time — no untagged resources exist. Azure Cost Management can then group and filter costs by the TeamName tag to produce per-team reports. This enables accurate chargeback even when multiple teams share resource groups or subscriptions.
4. Create one resource group per team and drive chargeback from each resource group's cost breakdown in Azure Cost Management for the twenty teams that share the subscription

   The question states resources from different teams are often in shared resource groups — this approach assumes dedicated resource groups, which contradicts the scenario. Shared resource groups cannot be split by team using RG-level cost reports.

Mandatory tags via Deny policy + Azure Cost Management tag-based grouping enables per-team chargeback within a shared subscription.

12. A single Azure AD Connect instance with multi-forest: Which Azure AD Connect topology is supported?

1. Azure AD Connect Cloud Sync (lightweight agents) can sync multiple forests to one tenant, replacing AAD Connect entirely

   Azure AD Connect Cloud Sync (now Microsoft Entra Connect Cloud Sync) does support multi-forest scenarios, but it has feature limitations compared to full AAD Connect — notably, it doesn't support all writeback scenarios, Password Hash Sync from all forests simultaneously, or complex attribute filtering. For Hybrid Azure AD Join requirements, full AAD Connect is more mature.
2. Multiple Azure AD Connect instances each syncing one forest, with both pointing to the same Azure AD tenant (mesh topology) — only one instance can be active at a time for the same tenant

   Multiple Azure AD Connect instances syncing to the same Azure AD tenant IS supported, but only if each instance manages distinct, non-overlapping sets of objects. Both forests can sync to one tenant using separate AAD Connect instances with proper object filtering to avoid conflicts. The 'only one active at a time' limitation applies to staging mode, not multi-forest with distinct objects.
3. Create separate Azure AD tenants for each forest and use Azure AD B2B to provide cross-tenant access

   Separate tenants would break the requirement for a single Azure AD tenant for device management and Hybrid Azure AD Join. Device compliance and Conditional Access work within a single tenant boundary — cross-tenant B2B doesn't support device management.
4. A single Azure AD Connect instance with multi-forest support, connecting to both Forest A and Forest B and syncing all objects to one Azure AD tenant ✓

   Azure AD Connect natively supports multi-forest synchronization. A single AAD Connect instance can connect to multiple forests simultaneously using the 'Users exist across multiple directories' or 'Users are represented only once across all directories' configuration. One sync engine handles matching and deduplication across forests.

A single Azure AD Connect instance natively supports multi-forest synchronization, connecting to both forests and deduplicating objects when syncing to one Azure AD tenant.

Other AZ-305 domains

• Design infrastructure solutions — 572 questions →
• Design data storage solutions — 340 questions →
• Design business continuity solutions — 270 questions →
• All 1652 AZ-305 questions →