Study guide
3.1 Authentication Solution Design
Exam AZ-305: Designing Microsoft Azure Infrastructure Solutions Exam
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Orientation
1.1 AZ-305 Current Exam Facts & Format 1.2 Candidate Profile, Prerequisites & the AZ-104 Requirement 1.3 Skills Outline, Domain Weights & How to Use This Guide
2 Chapter 2: Logging, Monitoring & Diagnostics Design
2.1 Logging Solution Design 2.2 Log Routing Design 2.3 Azure Monitor Metrics & Alerting Design 2.4 Application Insights & Diagnostic Monitoring Design
3 Chapter 3: Authentication & Authorization Design
3.1 Authentication Solution Design 3.2 Identity Management Design 3.3 Authorization for Azure Resources 3.4 Authorization for On-Premises Resources 3.5 Secrets, Certificates & Key Management Design
4 Chapter 4: Governance, Compliance & Identity Governance Design
4.1 Management Group & Subscription Hierarchy Design 4.2 Resource Group Organization & Tagging Strategy Design 4.3 Compliance Management Design 4.4 Identity Governance Design
5 Chapter 5: Relational Data Storage Design
5.1 Relational Data Storage Selection 5.2 Database Service & Compute Tier Design 5.3 Database Scalability Design 5.4 Relational Data Protection Design
6 Chapter 6: Semi-Structured & Unstructured Data Storage Design
6.1 Semi-Structured Data Storage Design 6.2 Unstructured Data Storage Design 6.3 Storage Tier & Cost-Performance Trade-off Design 6.4 Unstructured Data Protection & Durability Design
7 Chapter 7: Data Integration & Analytics Design
7.1 Data Integration Pipeline Design 7.2 Event-Based & Real-Time Data Integration Design 7.3 Data Analytics Platform Design
8 Chapter 8: Backup & Disaster Recovery Design
8.1 Recovery Objectives Design: Calculating and Meeting RTO/RPO 8.2 Azure Site Recovery Architecture for Hybrid Workloads 8.3 Compute Backup & Recovery Design 8.4 Database Backup & Recovery Design 8.5 Unstructured Data Backup & Recovery Design
9 Chapter 9: High Availability Design
9.1 Compute High Availability: Availability Sets & Availability Zones 9.2 Compute High Availability: Load Balancing & VM Scale Set Design 9.3 Relational Data High Availability Design 9.4 Semi-Structured & Unstructured Data High Availability Design
10 Chapter 10: Compute Solution Design
10.1 Compute Requirements Analysis & Virtual Machine-Based Solution Design 10.2 Container-Based Solution Design (AKS, Container Apps, Azure Container Instances) 10.3 Serverless-Based Solution Design (Azure Functions, Logic Apps) 10.4 Batch Processing Solution Design (Azure Batch, HPC Workloads)
11 Chapter 11: Application Architecture Design
11.1 Messaging Architecture Design (Service Bus, Queue Storage) 11.2 Event-Driven Architecture Design (Event Grid, Event Hub) 11.3 API Integration & Application Caching Design (API Management, Azure Cache for Redis, CDN) 11.4 Application Configuration Management & Automated Deployment Design (App Configuration, DevOps Pipelines, Deployment Slots)
12 Chapter 12: Migration Design
12.1 Migration Assessment: Cloud Adoption Framework & On-Premises Evaluation 12.2 IaaS & PaaS Workload Migration Design 12.3 Database Migration Design (Data Migration Service, Database Migration Assistant) 12.4 Unstructured Data Migration Design (AzCopy, Data Box, Storage Migration Service)
13 Chapter 13: Network Solution Design
13.1 Internet Connectivity Design 13.2 Hybrid Connectivity Design 13.3 Network Security Optimization Design 13.4 Network Performance Optimization & Load-Balancing/Routing Design
14 Chapter 14: Final Review, Exam Strategy & Career Path
14.1 Cross-Domain Scenario Practice: Combining Identity, Data, Continuity & Infrastructure Decisions 14.2 Common AZ-305 Decision Traps 14.3 Final Study Plan & Practice Assessment Strategy 14.4 After AZ-305: Retake Policy, Renewal & Career Path
3.1 Authentication Solution Design
Key Takeaways Explain This Topic AI
Microsoft enforces MFA in two phases: Phase 1 (Oct 2024) covers portal/admin-center CRUD operations, Phase 2 (Oct 2025) covers CLI/PowerShell/REST write operations, with extensions expiring July 1, 2026.
Entra ID offers five passwordless methods; Windows Hello for Business, FIDO2 security keys, certificate-based authentication, and passkeys all satisfy phishing-resistant MFA, but Microsoft Authenticator phone sign-in does not.
A tenant must choose either Security Defaults (free, all-or-nothing MFA) or Conditional Access (granular, requires Entra ID P1/P2) — the two cannot run together.
Conditional Access policies combine assignments (who/what/conditions), grant controls (MFA, compliant device, block), and session controls (sign-in frequency, persistent browser).
Authentication strengths (Multifactor, Passwordless MFA, Phishing-resistant MFA) let a single Conditional Access policy demand a specific class of credential, not just "any MFA."
Last updated: July 2026
Why Authentication Design Matters on AZ-305
Authentication design is one of three functional subgroups inside "Design identity, governance, and monitoring solutions" (25-30% of the exam), and it is the subgroup that touches nearly every other AZ-305 scenario. A question about a data storage design or a network design will still assume a working authentication story underneath it. Microsoft also tests this subgroup against a live, dated policy: its own mandatory multifactor authentication (MFA) rollout for Azure administration. An architect who treats MFA and Conditional Access as optional add-ons rather than baseline requirements will miss the "recommend an authentication solution" bullet on exam day.
Authentication answers "who are you?" — it proves an identity's claim through one or more credentials. Authorization (covered in the next three sections) answers "what can you do?" once that identity is verified. AZ-305 scenarios frequently combine both in a single question, so keep the distinction sharp: a Conditional Access policy that requires MFA is an authentication control; a role assignment that lets a verified user delete a resource group is an authorization control.
Microsoft Entra ID as the Identity Platform
Microsoft Entra ID (the identity platform formerly branded Azure Active Directory) is the tenant-based identity provider behind every Azure sign-in, whether the user is a cloud-only account, a synchronized on-premises account, or an external guest. A tenant is a dedicated, isolated instance of Entra ID that represents an organization; every Azure subscription trusts exactly one Entra ID tenant for authentication, even though a tenant can be associated with multiple subscriptions. When a design calls for "a solution to authenticate users," the default answer on this exam is Entra ID plus whichever authentication method and Conditional Access controls fit the stated requirement — not a third-party identity provider unless the scenario explicitly requires federation with an existing system.
Microsoft's Mandatory MFA Enforcement Timeline
Microsoft has moved MFA from "recommended" to "required" for Azure administrative access, and AZ-305 expects you to know the shape of that rollout because it changes what "meets the requirement" means for a design:
Phase Effective What it covers
Phase 1 October 2024 MFA required for any sign-in performing a create/read/update/delete (CRUD) operation in the Azure portal, Microsoft Entra admin center, or Intune admin center
Phase 1 (M365) February 2025 onward Gradual enforcement for Microsoft 365 admin center sign-ins, reaching full enforcement by February 2026
Phase 2 October 1, 2025 onward MFA required for create/update/delete operations through Azure CLI, Azure PowerShell, the Azure mobile app, infrastructure-as-code tools, and REST API calls (read-only calls are exempt)
Extension deadline July 1, 2026 Final date organizations with documented technical blockers can delay Phase 2 enforcement
The exam implication: a design that assumes automation accounts or CI/CD pipelines can make write calls with only a password is no longer a valid recommendation. Service principals and managed identities (not interactive MFA) are the correct pattern for unattended automation against Azure Resource Manager.
Passwordless and Phishing-Resistant Methods
Beyond password + MFA, Entra ID supports five passwordless authentication methods, each removing the password as an attack surface:
Method How it works Phishing-resistant?
Microsoft Authenticator phone sign-in Number-matching push approval from a registered device No (resistant to some attacks, not certificate-grade)
- Windows Hello for Business Biometric or PIN bound to a TPM-backed key on the device Yes
- FIDO2 security keys Hardware key using public-key cryptography, no shared secret Yes
- Certificate-based authentication Smart card or PIV certificate presented at sign-in Yes
- Passkeys (FIDO2) Cross-device credential stored in Authenticator or a platform passkey provider Yes
All five passwordless methods satisfy phishing-resistant MFA when enforced through Conditional Access. This matters for exam scenarios that specify "administrators must use phishing-resistant credentials" — the correct answer is one of these five methods, not SMS or voice call (both are being phased out precisely because they are phishable).
Conditional Access Policy Design
Conditional Access is the "if this, then that" engine that ties sign-in conditions to authentication requirements. Every policy has three parts:
Assignments — who (users, groups, or workload identities), what (cloud apps, actions, or authentication context), and conditions (sign-in risk level, device platform, network location, client app type).
Grant controls — require MFA, require a compliant device (via Intune), require a Microsoft Entra hybrid-joined device, require an approved client app, require an app protection policy, or simply block access.
Session controls — sign-in frequency, persistent browser session, and app-enforced restrictions (e.g., read-only in SharePoint on unmanaged devices).
Conditional Access requires Microsoft Entra ID P1 for standard conditions and P2 for risk-based conditions (sign-in risk, user risk) that depend on Identity Protection. A tenant cannot run Security Defaults (Microsoft's free, one-size-fits-all MFA baseline) at the same time as custom Conditional Access policies — a design that needs anything more granular than "everyone does MFA" must recommend disabling Security Defaults in favor of Conditional Access.
Authentication strengths let a Conditional Access grant control demand a specific class of credential rather than just "any MFA." Entra ID ships three built-in strengths: Multifactor authentication strength (any two factors), Passwordless MFA strength (the five methods above), and Phishing-resistant MFA strength (FIDO2, certificate-based, Windows Hello for Business, or passkeys only).
Exam Scenario
A company wants all Global Administrators to sign in only with phishing-resistant credentials from any network, while general staff need standard MFA but can use any registered method. The correct design layers two Conditional Access policies: one scoped to the Global Administrator directory role (ideally activated through Privileged Identity Management, covered in Chapter 4) requiring the Phishing-resistant MFA authentication strength, and a second, broader policy scoped to "All users" requiring the Multifactor authentication strength. A single blanket policy cannot express both requirements at once — recognizing that you need two scoped policies, not one, is the design skill being tested.
Common Traps
Recommending Security Defaults and Conditional Access together — the tenant must pick one model.
Forgetting that legacy authentication protocols (POP, IMAP, older Exchange/SharePoint clients) cannot enforce MFA at all; a secure design blocks legacy auth via Conditional Access rather than trying to layer MFA on top of it.
Assuming SMS/voice call MFA satisfies a "phishing-resistant" requirement — it does not.
Forgetting that Conditional Access itself requires Entra ID P1/P2 licensing; a Free-tier tenant can only use Security Defaults.