3.1 Authentication Solution Design

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:

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:

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.