AZ-305 Exam Map and Design Decision Playbook

AZ-305 tests architectural judgement. Most prompts give several workable Azure services; the correct answer best satisfies the stated constraints with the least unjustified complexity. Read every scenario as a set of decisions about requirements, failure modes, security boundaries, data semantics, operations, and cost.

How to read an architecture question

1. Underline hard constraints. Compliance, protocol, maximum data loss, outage window, region support, compatibility, and operating ownership eliminate options.
2. Name the architecture decision. Is this identity, authorization, governance, storage, integration, recovery, compute, application, migration, or network design?
3. Choose the least complex service that meets every hard constraint. Do not optimize a requirement the scenario never states.
4. Check the whole workload. A redundant web tier does not compensate for one database, one region, one DNS dependency, or a manual recovery path.
5. Explain the trade-off. A strong answer says what the recommendation gains, what it costs, and why the nearest alternative loses.

Text equivalent: classify the decision, extract constraints, compare only viable options, test the complete workload, then state the recommendation and its trade-off.

Blueprint-to-study map

Blueprint-weighted study cycle

• Spend roughly one third of scenario practice on infrastructure, but interleave it with identity, data, and continuity because real designs cross domains.
• Use topic cram sheets for retrieval, then answer architecture items without notes.
• Keep an error log with four fields: missed requirement, wrong service boundary, misleading distractor, and corrected decision rule.
• Revisit a miss after one day, one week, and before the next mock. Recognition is not mastery; require yourself to explain the rejected alternatives.
• Take unit checkpoints after the corresponding roadmap and cram sheets. Use full mocks only after every unit has evidence of recall and design reasoning.

Whole-architecture checklist

• Identity: tenant, principal type, authentication flow, managed identity, privilege lifecycle.
• Governance: management scope, policy, compliance evidence, resource lifecycle, cost ownership.
• Data: model, query/transaction pattern, partitioning, consistency, protection, residency.
• Continuity: component and workload RTO/RPO, zones/regions, backups, failover, failback, tests.
• Application: synchronous versus asynchronous coupling, APIs, messages, events, cache, configuration.
• Network: flows, private/public entry, DNS, routing, inspection, egress, hybrid redundancy.
• Operations: deployment, monitoring, alert response, capacity, patching, ownership, cost.

Source and freshness

Blueprint ranges follow the Microsoft Learn AZ-305 study guide showing skills measured as of April 17, 2026. The attached books provide teaching depth; current Microsoft Learn documentation controls current product behaviour, availability, limits, and naming. Reviewed 2026-08-02.

Unit 1 Capstone — Design identity, governance, and monitoring solutions

The capstone is a synthesis exercise: design one production workload whose architecture crosses every topic in Unit 1. Your submission should read like a lightweight architecture review package, not an exam answer.

Scenario

Contoso is moving a revenue-generating service onto Azure. It operates across two business regions, processes confidential customer data, has a small central platform team, and must demonstrate recoverability to auditors. Traffic and data volume are expected to grow, but finance requires a design that can start economically. The organisation wants a decision package it can use for a proof of concept and production readiness review.

Turn organisational boundaries, duties, and evidence requirements into an operable control model.

Required topic threads

1. Design solutions for logging and monitoring: Design the signal path from collection to retention, query, alert, and automated response.
2. Design authentication and authorization solutions: Separate who signs in, what they may do, how privilege activates, and how workloads obtain tokens.
3. Design governance: Place boundaries, policy, cost ownership, compliance evidence, and privileged access at the right scope.

The client also requires least-privilege workload identity, private administration paths, infrastructure as code, measurable service objectives, cost allocation, and an exit or migration strategy for any service on a retirement path.

Starting comparison

Deliverables

1. Context and requirements: business goals, measurable non-functional requirements, assumptions, exclusions, and five open questions.
2. Architecture: one system-context diagram and one deployment/data-flow diagram, each with a text equivalent.
3. Decision records: at least one ADR per topic, including alternatives and consequences.
4. Security and governance: identities, permissions, network boundaries, policy, secrets, audit evidence, and data residency.
5. Reliability: dependency inventory, availability calculation assumptions, RTO/RPO allocation, backup/failover/failback, and a test schedule.
6. Operations: deployment strategy, telemetry, alerts with owners, capacity signals, patching/upgrades, and runbook entry points.
7. Economics: primary cost drivers, scaling assumptions, commitment risks, and a method for validating current prices.
8. Pilot plan: success criteria, failure injection, security tests, performance evidence, and a stop/go decision.

Text equivalent: requirements drive the architecture; security, continuity, and operations qualify it; pilot evidence determines the production decision.

Review rubric

Score each dimension from 0 to 3: requirements traceability, cross-topic coherence, least privilege, failure coverage, data semantics, network/DNS completeness, deployability, observability, recovery evidence, cost reasoning, current sources, and clarity. A passing capstone has no zero, no unowned critical risk, and at least 28 of 36 points. A high total cannot compensate for a missing recovery owner or an unsupported product assumption.

Learner self-check

• Can another engineer implement the design without inventing its key decisions?
• Does every critical dependency have a health signal and recovery owner?
• Are current limits, availability, and retirement milestones cited from Microsoft primary sources?
• Does the proof of concept test the riskiest assumption rather than the easiest happy path?
• Can I explain how this design changes if scale, recovery, regulation, or team capability changes?

Source and freshness

Aligned to the current AZ-305 blueprint and grounded in both attached course sources. Current product contracts must be cited during the exercise. Reviewed 2026-08-02.

Unit 1 Roadmap — identity, governance, and monitoring solutions

This roadmap turns the unit into a study sequence. The goal is to connect topic decisions, not memorize isolated product facts. The current exam blueprint allocates 25–30% to this domain.

Unit thesis

Turn organisational boundaries, duties, and evidence requirements into an operable control model.

Recommended learning sequence

1. Start with observability requirements: signals, destinations, retention, query, alert, and response.
2. Separate authentication, Azure resource authorization, directory roles, and workload identity.
3. Place management groups, subscriptions, policy, and privileged access around durable business boundaries.

Text equivalent: study each topic cram sheet, complete the unit checkpoint, then prove synthesis in a design studio.

Topic map

How to work this unit

For each topic, read the linked full lessons first when the service boundary is unfamiliar. Use the cram sheet to compress the decision rules. Then close the notes and answer the retrieval prompts. Finish with scenarios that force two or more topics to interact. A correct product name without a constraint-based explanation is not sufficient evidence of readiness.

When reviewing an answer, write a one-sentence recommendation in this form: Choose X because constraints A and B matter; reject Y because it fails C; accept trade-off D. This structure exposes guesses and makes technical review easier.

Pre-checkpoint checklist

• I can state the decision boundary for every service family in this unit.
• I can distinguish high availability, recovery, security, and governance controls when they appear together.
• I can identify the strongest distractor and the requirement it fails.
• I can draw the major dependency or signal flow without copying a diagram.
• I can explain operational ownership and cost consequences, not only features.
• I have corrected every missed retrieval prompt at least once from memory.

Common failure patterns

• Using Azure Policy to grant access instead of govern resource state.
• Sending every signal to one workspace without residency, access, or cost analysis.
• Giving workloads stored credentials when managed identity is supported.

Source and freshness

Aligned to the current AZ-305 study guide and grounded in the two attached corpus sources. Product details and limits must be checked against current Microsoft Learn documentation. Reviewed 2026-08-02.

Cram Sheet — Design authentication and authorization solutions

Separate who signs in, what they may do, how privilege activates, and how workloads obtain tokens. Use this sheet after the linked lessons: it is a retrieval map and decision aid, not a substitute for the worked examples.

Decision matrix

The phrase start with matters. A default is only defensible after checking all hard constraints: region and SKU support, protocols, scale, availability, security, residency, recovery, skills, and operating ownership. When two rows appear in one scenario, compose them rather than forcing one service to solve every concern.

Fast design method

1. Name the workload boundary and the users or systems that cross it.
2. Extract measurable requirements: latency, throughput, volume, RTO/RPO, consistency, outage window, and retention.
3. Mark security and governance constraints: identity, network reachability, encryption, residency, audit, and separation of duties.
4. Select the simplest viable default from the matrix.
5. Test it against failure domains, scale transitions, deployment, monitoring, and cost.
6. State the nearest alternative and the one constraint that makes it weaker.

Text equivalent: derive requirements, choose a default, qualify it against constraints, add operational and failure behaviour, then explain the trade-off.

High-value traps

• Reader does not imply service data access.
• Policy does not grant permissions.
• A managed identity still needs authorization.

Scenario rehearsal

An organisation asks for the capability described by the first matrix row, but also adds a strict recovery target, private connectivity, and a small operations team. Write a recommendation that identifies the core service, the supporting continuity and network controls, and the operating trade-off. Then reject the nearest service alternative using one explicit requirement. If your answer lists products without a traffic, data, identity, or recovery flow, it is incomplete.

Final-minute checklist

• I can distinguish every service in the matrix by requirement, not logo or name.
• I know which controls operate at identity, management, data, and network planes.
• I check regional/SKU support and current limits when a scenario depends on them.
• I include monitoring, health, capacity, recovery, and ownership in the recommendation.
• I can explain why the strongest distractor fails.

Source and freshness

Aligned to the current AZ-305 study guide, the attached Exam Ref, and the attached AZ-305 study guide corpus. Current Microsoft Learn documentation controls product availability, limits, and renamed services. Reviewed 2026-08-02.

Design Authentication and Authorization Solutions — Lesson

This integrated module covers the five learning objectives that form the authentication and authorization pillar of AZ-305 Unit 1. You will learn how to design authentication flows with Microsoft Entra ID, plan hybrid identity synchronisation, assign permissions through RBAC and ABAC, extend access to on-premises applications, and protect secrets with Azure Key Vault. Each sub-section maps to one LO; cross-cutting worked examples show how the pieces connect in real architectural decisions.

Reference: Ch. 1, §1.2, p. 14–28 of the AZ-305 exam book.

Why This Matters

Every Azure architecture begins with a question: who is allowed to do what? A misconfigured Conditional Access policy can lock out an entire workforce; an over-permissioned service principal can expose production databases to a compromised pipeline. The AZ-305 exam tests your ability to make these decisions under realistic constraints — budget, compliance, user experience, and legacy infrastructure. Mastering authentication and authorization design is not just an exam objective; it is the single most consequential skill set for any Azure solutions architect, because security failures in this layer cascade into every other layer of the stack.

Prerequisites

• Microsoft Entra ID tenant basics — Can you explain what a tenant, directory, and subscription are and how they relate?
• Networking fundamentals (HTTP/S, TLS, DNS) — Can you describe how a browser negotiates a TLS handshake?
• Basic Active Directory concepts (forests, domains, OUs) — Can you sketch the trust relationship between two AD forests?
• Azure portal navigation — Can you locate the Entra ID blade, subscription IAM pane, and Key Vault resource in the portal?
• JSON and ARM template literacy — Can you read a short ARM snippet and identify the resource type?

Learning Objectives

1. Evaluate authentication mechanisms (MFA, passwordless, Conditional Access, B2B/B2C) and recommend the right combination for a given scenario.
2. Design a hybrid identity architecture using Microsoft Entra Connect with the appropriate synchronisation method (PHS, PTA, or federation).
3. Recommend an RBAC/ABAC strategy for Azure resources that satisfies least-privilege and separation-of-duties requirements.
4. Design secure remote access to on-premises applications using Entra ID Application Proxy.
5. Architect a secrets, keys, and certificates management solution using Azure Key Vault with appropriate access policies and networking controls.
6. Analyse cross-cutting scenarios where authentication, authorisation, and secret management decisions interact.

Building Blocks

Microsoft Entra ID (formerly Azure AD) — Analogy: Think of Entra ID as the reception desk of a building — it checks your badge (authentication), looks up which floors you can access (authorisation), and logs your entry (audit). Formal definition: A cloud-based identity and access management service that provides single sign-on, multifactor authentication, and conditional access for users, groups, and service principals. Why it matters: Every Azure resource and most SaaS integrations depend on Entra ID tokens for access decisions.

Conditional Access — Analogy: Like an airport security checkpoint with adaptive rules — frequent flyers with trusted devices go through the fast lane, while first-time travellers get extra screening. Formal definition: A policy engine in Entra ID that evaluates signals (user, device, location, risk level) and enforces access controls (grant, block, require MFA, require compliant device). Why it matters: Conditional Access is the primary enforcement point for Zero Trust in Azure.

Password Hash Synchronisation (PHS) — Analogy: Photocopying a key — the original stays on-premises, but a copy sits in the cloud so either door can recognise you. Formal definition: A sync method where a hash of the on-premises AD password hash is replicated to Entra ID every two minutes. Why it matters: Simplest hybrid identity method; enables cloud-based leaked-credential detection.

Pass-Through Authentication (PTA) — Analogy: A doorbell that rings the on-premises security desk every time someone asks to enter the cloud building. Formal definition: Entra ID forwards the authentication request to an on-premises agent that validates the password against AD in real time. Why it matters: Passwords never leave the on-premises boundary, satisfying certain compliance mandates.

Role-Based Access Control (RBAC) — Analogy: A hotel key card programmed for specific floors — your role determines which resources you can reach. Formal definition: An authorisation system built on role assignments (security principal + role definition + scope) that governs data-plane and control-plane actions on Azure resources. Why it matters: RBAC is the default and recommended authorisation model for Azure; misuse leads to privilege escalation.

Azure Key Vault — Analogy: A bank safety-deposit box — you rent a box (vault), store valuables (secrets, keys, certificates), and only authorised signatories can open it. Formal definition: A managed HSM-backed service for storing and accessing secrets, encryption keys, and X.509 certificates with access governed by RBAC or vault access policies. Why it matters: Eliminates hard-coded credentials; centralises key lifecycle management.

Deep Dive

LO4 — Design an Authentication Solution

The authentication design decision tree starts with who is authenticating: internal workforce, external partners (B2B), or consumers (B2C).

Workforce authentication centres on Entra ID with MFA. The exam tests three MFA methods: Microsoft Authenticator push, FIDO2 security keys, and Windows Hello for Business. Passwordless is the recommended direction — the AZ-305 book emphasises that passwordless authentication reduces phishing surface.

[!TIP] Use named locations in Conditional Access to exempt trusted corporate egress IPs from MFA prompts — this balances security with user experience.

B2B collaboration invites external partners into your tenant as guest users. The guest user authenticates against their home tenant (or a one-time passcode if they have no Entra ID). The key design decision is cross-tenant access settings: you control which external tenants may collaborate and whether their MFA claims are trusted.

B2C creates a separate tenant (*.onmicrosoft.com with the B2C extension) and supports custom user flows (sign-up, sign-in, profile edit) with social identity providers (Google, Facebook, Apple). The exam expects you to choose B2C when the scenario involves consumer-facing apps with self-service registration.

See the LO4-level lesson for a deeper treatment of Conditional Access policy design patterns.

LO5 — Design an Identity Management Solution

Hybrid identity connects on-premises Active Directory to Entra ID through Microsoft Entra Connect (formerly Azure AD Connect). The three synchronisation methods are compared below.

[!WARNING] PTA requires at least 3 authentication agents for production availability. A single-agent deployment is a single point of failure.

Decision rule: Choose PHS unless a regulatory requirement forbids any password derivative in the cloud. Choose PTA if the requirement is real-time on-premises password validation without deploying AD FS. Choose federation only when you need advanced claim rules or a third-party IdP.

Entra Connect also syncs group memberships, device objects (hybrid join), and writeback attributes (password writeback, group writeback). The exam may test which features require Entra ID P1 vs P2 licensing.

See the LO5-level lesson for Entra Connect deployment topologies and staging-server patterns.

LO6 — Design Authorisation for Azure Resources

Azure RBAC uses three elements: security principal (user, group, service principal, managed identity), role definition (set of allowed actions), and scope (management group → subscription → resource group → resource).

Custom roles are defined in JSON when built-in roles are too broad or too narrow.

Attribute-Based Access Control (ABAC) extends RBAC by adding conditions to role assignments — for example, "allow Storage Blob Data Reader only on blobs tagged project=phoenix". ABAC conditions use the @Resource and @Principal attributes.

[!IMPORTANT] ABAC conditions are currently supported on Storage Blob Data * roles only. Don't assume ABAC works on arbitrary resource types — the exam may offer ABAC as a distractor for non-storage scenarios.

See the LO6-level lesson for a complete guide to designing custom roles and ABAC conditions.

LO7 — Design Authorisation for On-Premises Resources

When users are in the cloud but applications are on-premises, Entra ID Application Proxy bridges the gap. A lightweight connector agent installed on an on-premises server creates an outbound HTTPS tunnel to the Application Proxy service — no inbound firewall ports required.

The connector agent authenticates to the cloud service with a certificate; user traffic is:

1. User hits the external URL (e.g., https://expenses.contoso.msappproxy.net).
2. Entra ID authenticates the user and evaluates Conditional Access.
3. Application Proxy routes the request through the connector to the internal URL (e.g., http://expenses.corp.contoso.com).
4. The connector performs Kerberos Constrained Delegation (KCD) if the back-end app uses Windows Integrated Authentication.

[!NOTE] For high availability, deploy at least 2 connectors in the same connector group. Connectors are stateless and auto-update.

See the LO7-level lesson for KCD configuration and connector group design patterns.

LO8 — Design a Solution for Secrets, Keys, and Certificates

Azure Key Vault comes in two tiers: Standard (software-protected keys) and Premium (HSM-backed keys, FIPS 140-2 Level 2). The exam tests when Premium is required — typically for regulatory mandates citing HSM protection.

Access model choice: Key Vault supports two access models — vault access policies (legacy) and RBAC (recommended). With RBAC, you assign Key Vault Secrets User or Key Vault Crypto Officer at the vault scope, unifying authorisation with the rest of Azure.

Networking: Key Vault supports private endpoints and service endpoints. For production, use a private endpoint in the workload VNet so that secret retrieval never traverses the public internet.

Key Vault integrates with several Azure services: App Service and Azure Functions read secrets via Key Vault references (@Microsoft.KeyVault(...)). Azure Disk Encryption uses Key Vault keys. Azure SQL TDE can use a customer-managed key stored in Key Vault.

See the LO8-level lesson for key rotation strategies and certificate auto-renewal patterns.

Worked Examples

Easy — Single-LO: Choose the Right Sync Method

Problem: Contoso has $5{,}000$ users in on-premises AD. Compliance requires that user passwords never leave the corporate network, even as hashes. The IT team has no AD FS infrastructure and wants the simplest possible setup. Which sync method should the architect recommend?

Step-by-step solution:

1. PHS syncs a hash of the password hash to the cloud — eliminated by the "no password derivative in cloud" constraint.
2. Federation requires an AD FS farm — eliminated by the "simplest setup" constraint.
3. PTA validates passwords in real time against on-prem AD via a lightweight agent — satisfies both constraints.
4. Recommend PTA with 3 agents across 2 on-prem servers for availability.

[!NOTE] Key insight: PTA is the middle ground between PHS simplicity and federation flexibility. It keeps passwords on-prem without AD FS overhead.

Medium — Two-LO Crossover: MFA Policy + RBAC Assignment

Problem: Fabrikam's cloud team has 20 engineers. The CISO mandates: (a) all engineers must complete MFA before accessing Azure portal, and (b) engineers may deploy VMs but must not modify IAM role assignments. Design the authentication and authorisation controls.

Step-by-step solution:

1. Authentication (LO4): Create a Conditional Access policy targeting the "Cloud Engineers" security group, scoping to the Azure Management cloud app, requiring MFA grant control.
2. Authorisation (LO6): Assign the Virtual Machine Contributor built-in role to the "Cloud Engineers" group at the relevant subscription scope. This role allows VM lifecycle operations but excludes Microsoft.Authorization/* actions (no IAM changes).
3. Verification: An engineer who passes MFA can create a VM but receives AuthorizationFailed if they attempt New-AzRoleAssignment.

[!NOTE] Key insight: Layering Conditional Access (who can authenticate) on top of RBAC (what they can do) implements defence in depth — neither control alone is sufficient.

Hard — Three-LO Crossover: Hybrid Identity + App Proxy + Key Vault

Problem: Northwind Traders runs a legacy ASP.NET payroll app on-premises using Windows Integrated Authentication. The company is moving to Entra ID for SSO. Requirements: (a) remote workers must access the payroll app without VPN, (b) the app's SQL connection string must not be stored in web.config, and (c) password sync to the cloud is prohibited. Design the end-to-end solution.

Step-by-step solution:

1. Identity (LO5): Deploy Entra Connect with PTA (password stays on-prem). Install 3 PTA agents.
2. Remote access (LO7): Deploy Entra ID Application Proxy with 2 connectors in a connector group. Configure KCD so the connector can obtain Kerberos tickets on behalf of the Entra-authenticated user.
3. Secret management (LO8): Store the SQL connection string in Azure Key Vault. The on-premises app reads the secret at startup via the Key Vault SDK, authenticating with a managed identity registered in Entra ID (or a service principal with certificate-based auth).
4. Conditional Access (LO4): Apply a CA policy to the Application Proxy enterprise app requiring MFA and a compliant device.

[!NOTE] Key insight: Application Proxy + KCD eliminates VPN while preserving Windows Integrated Auth. Key Vault removes the secret from configuration files, and PTA satisfies the no-cloud-password constraint.

Visual Explanations

Conditional Access Policy Evaluation Flow

This diagram shows how Conditional Access collects multiple signals before making a grant/block decision. The policy engine evaluates all matching policies — the most restrictive grant control wins.

Azure RBAC Inheritance Model

Roles assigned at a higher scope propagate downward. A Reader assignment at the management group level grants read access to every resource in every subscription beneath it. Use the narrowest scope that satisfies the requirement.

Hybrid Identity Architecture (TikZ)

This diagram illustrates the full hybrid identity architecture: Entra Connect synchronises identities, PTA agents handle real-time password validation, Application Proxy connectors provide remote access via KCD, and Key Vault is accessed through Entra ID RBAC.

Common Mistakes

❌ Myth: PHS sends user passwords to the cloud, so it fails every compliance audit. ✅ Reality: PHS syncs a SHA-256 hash of the MD4 hash — the original password is never transmitted or stored. Microsoft uses this double-hash to detect leaked credentials (Entra ID Protection). Many compliance frameworks accept PHS when the architecture is documented. Why it's tricky: The word "hash" sounds insecure to non-technical stakeholders, but PHS is actually the most secure sync method because it enables cloud-based threat detection that PTA and federation cannot.

❌ Myth: Assigning Owner at the subscription scope is fine for the lead architect because they need full access. ✅ Reality: Owner includes Microsoft.Authorization/*/Write, meaning the architect can grant anyone any role — including themselves elevated access. Use Contributor for resource deployment and grant User Access Administrator separately with PIM just-in-time activation if IAM changes are needed. Why it's tricky: Owner feels natural for a lead role, but it violates least-privilege and separation-of-duties. The exam specifically tests whether you choose Owner vs. Contributor + PIM.

❌ Myth: Key Vault access policies and RBAC can be used together on the same vault. ✅ Reality: A vault uses either the access-policy model or the RBAC model — not both simultaneously. The property enableRbacAuthorization is a boolean toggle. Microsoft recommends RBAC for new deployments because it unifies authorisation with the rest of Azure. Why it's tricky: Legacy documentation and older exam prep materials show access policies as the primary model, so candidates assume they can layer RBAC on top. They cannot.

❌ Myth: Application Proxy requires opening inbound firewall ports to the on-premises network. ✅ Reality: The connector agent creates outbound HTTPS connections to the Application Proxy cloud service. No inbound ports are needed, which is a key security advantage over traditional reverse proxies and VPNs. Why it's tricky: Candidates familiar with traditional DMZ architectures assume inbound ports are required. The outbound-only model is a distinguishing feature the exam tests.

Practice Exercises

🟢 Easy — Contoso wants to enable self-service password reset (SSPR) for cloud-only users. Which Entra ID licence tier is required?

▶💡 Hint

SSPR for cloud-only users is available at a specific premium tier. Check the licence table in the Deep Dive.

▶✅ Solution

Entra ID P1 is required for SSPR. Entra ID Free supports admin-only password reset, not self-service for all users.

🟢 Easy — Which Key Vault tier must Fabrikam choose if their auditor requires FIPS 140-2 Level 2 HSM-backed keys?

▶💡 Hint

Key Vault has two SKUs. Only one provides HSM backing.

▶✅ Solution

Key Vault Premium. Standard uses software-protected keys only.

🟡 Medium — Woodgrove Bank must ensure that only users on compliant, Intune-managed devices can access their Azure SQL databases via Azure Data Studio. They also need MFA. Design the Conditional Access policy.

▶💡 Hint

You need to combine two grant controls. Think about the operator (AND vs OR).

▶✅ Solution

Create a Conditional Access policy: target all users in the "Database Admins" group, scope to the "Azure SQL Database" cloud app, grant controls = require MFA AND require device to be marked as compliant. The AND operator ensures both conditions must be satisfied.

🟡 Medium — An engineer needs to read secrets from Key Vault kv-prod but should not be able to delete them or manage keys/certificates. Which built-in RBAC role should you assign?

▶💡 Hint

There are separate roles for secrets, keys, and certificates — and "User" vs "Officer" distinctions.

▶✅ Solution

Assign Key Vault Secrets User at the kv-prod resource scope. This role grants Microsoft.KeyVault/vaults/secrets/getSecret/action and list, but not delete or write. It does not grant any key or certificate permissions.

🔴 Hard — Litware Inc. is migrating $12{,}000$ users from three AD forests to a single Entra ID tenant. Forest A uses a .local UPN suffix (non-routable). Forests B and C use routable UPN suffixes. Password sync to the cloud is acceptable. Design the Entra Connect topology and address the UPN issue.

▶💡 Hint

Consider how many Entra Connect servers you need for multiple forests, and what happens when a UPN suffix is non-routable.

▶✅ Solution

Deploy a single Entra Connect server with multi-forest topology (one connector per forest). Use PHS for synchronisation. For Forest A, add an alternative routable UPN suffix (e.g., litware.com) in Active Directory Domains and Trusts, then update user accounts to use the routable suffix before sync. Alternatively, configure Entra Connect to use the mail attribute as the source anchor for sign-in if UPN remediation is infeasible. Deploy a staging-mode Entra Connect server for disaster recovery.

🔴 Hard — Synthetic scenario (AZ-305 style): Adatum Corp runs a legacy Java app on-premises that uses header-based authentication (the app reads X-Remote-User from the HTTP header). Remote workers need SSO via Entra ID without VPN. Which service should the architect recommend, and how does it handle header injection?

▶💡 Hint

Application Proxy supports multiple SSO modes beyond KCD. One of them is specifically designed for header-based apps.

▶✅ Solution

Deploy Entra ID Application Proxy with header-based SSO. Configure the connector to inject the X-Remote-User header with the authenticated user's UPN after Entra ID completes authentication and Conditional Access evaluation. This mode is designed for legacy apps that cannot negotiate Kerberos or SAML. For additional security, apply a Conditional Access policy to the enterprise app requiring MFA.

Summary & Concept Map

• Entra ID is the central identity provider for all Azure workloads; Conditional Access is the enforcement engine for Zero Trust.
• B2B extends your tenant to partners (they authenticate at their home tenant); B2C is a separate tenant for consumer-facing self-service sign-up.
• Entra Connect bridges on-prem AD to the cloud — choose PHS for simplicity and leak detection, PTA for on-prem-only passwords, federation only for advanced claims.
• RBAC + ABAC enforce least-privilege at every scope level; prefer built-in roles, use custom roles sparingly, and always assign to groups, not individuals.
• Application Proxy provides VPN-less access to on-prem web apps through outbound-only connectors with SSO (KCD, header-based, SAML).
• Key Vault centralises secrets, keys, and certificates; use RBAC access model, Premium SKU for HSM, and private endpoints for network isolation.
• Cross-cutting theme: layer authentication (who you are), authorisation (what you can do), and secret management (how credentials are stored) as independent, composable controls.

Connections & Next Steps

This topic integrates five learning objectives into one security design module. For deeper mastery, proceed through the lessons in this order:

1. LO4 — Design an authentication solution — deep dive into Conditional Access policy patterns, B2B cross-tenant settings, and B2C user flow customisation.
2. LO5 — Design identity management — Entra Connect topologies, staging-server failover, and password writeback configuration.
3. LO6 — Design authorisation for Azure resources — custom role JSON authoring, ABAC condition syntax, and PIM activation workflows.
4. LO7 — Design authorisation for on-premises resources — Application Proxy connector groups, KCD setup, and header-based SSO configuration.
5. LO8 — Design secrets, keys, and certificates management — Key Vault networking, key rotation automation, and certificate auto-renewal with App Service.

After completing this topic, move to Topic U1/T3 — Design solutions for logging and monitoring, where you will learn how to audit and monitor the identity decisions made here.

Design Studio — Design authentication and authorization solutions

This studio turns the topic into an architecture exercise. Produce a recommendation that another engineer could challenge, implement, and validate. There is no credit for a list of Azure products without flows, constraints, failure behaviour, and trade-offs.

Client brief

Fabrikam is modernising a production workload in this domain: Separate who signs in, what they may do, how privilege activates, and how workloads obtain tokens. The workload serves internal teams and external customers, carries regulated data, and must remain supportable by a small platform team. The client has supplied incomplete requirements; part of the exercise is to state assumptions and identify questions that would materially change the recommendation.

The initial requirements are:

1. The design must address human sign-in with explicit assumptions and measurable acceptance evidence.
2. The design must address azure resource action with explicit assumptions and measurable acceptance evidence.
3. The design must address workload access with explicit assumptions and measurable acceptance evidence.
4. The design must address privileged administration with explicit assumptions and measurable acceptance evidence.
5. The solution must use Microsoft Entra identities, private connectivity where justified, infrastructure as code, and observable health signals.
6. The design must state a recovery path, operational owner, cost driver, and one deliberate compromise.

Candidate decision anchors

These are starting points, not an answer key. You may select a different service when a stated assumption or constraint justifies it. Every deviation must identify the requirement it serves and the new operational cost it introduces.

Required submission

1. A one-page architecture diagram with a text equivalent.
2. A decision record containing context, decision, alternatives, consequences, and validation evidence.
3. A requirement-to-control matrix that maps every hard constraint to a component or operating process.
4. A failure table covering component, zone, region, identity, network, and operator-error failures where applicable.
5. Three validation tests: one functional, one reliability/security, and one operational or cost test.

Review traps

• Reader does not imply service data access.
• Policy does not grant permissions.
• A managed identity still needs authorization.

Assessment rubric

Reflection

• Which requirement eliminated the most attractive alternative?
• Which assumption creates the greatest residual risk?
• What would you test in a pilot before approving production deployment?
• How would the recommendation change if the operations team doubled in size or the recovery objective tightened?

Source and freshness

Grounded in the current AZ-305 skills outline and both attached course sources. Current service contracts must be verified in Microsoft Learn during the studio. Reviewed 2026-08-02.

Quick Note — Recommend an Authentication Solution

This lesson aligns with AZ-305 Chapter 2, §2.1–2.2, p. 41–65 and covers the architecture and design considerations for authenticating users and applications in Azure. We focus on Microsoft Entra ID (formerly Azure AD) as the identity platform, multi-factor authentication (MFA), Conditional Access policies, passwordless authentication methods, and authentication protocols such as SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC). This is not a lesson on identity governance or lifecycle management (see LO-5), nor on authorization and RBAC (see LO-6/LO-7) — it is about how to verify who someone is when they attempt to access resources.

Decision anchors

Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.

Ninety-second explanation

Without notes, explain:

1. What requirement signals this learning objective rather than a neighbouring one?
2. Which two solution families are most likely to be compared?
3. Which hard constraint eliminates the strongest distractor?
4. What identity, network, data, or failure boundary must appear in the design?
5. Which operational test would prove the recommendation works?

Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.

When to open the full lesson

Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.

Source and freshness

Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.

Recommend an Authentication Solution — Lesson

This lesson aligns with AZ-305 Chapter 2, §2.1–2.2, p. 41–65 and covers the architecture and design considerations for authenticating users and applications in Azure. We focus on Microsoft Entra ID (formerly Azure AD) as the identity platform, multi-factor authentication (MFA), Conditional Access policies, passwordless authentication methods, and authentication protocols such as SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC). This is not a lesson on identity governance or lifecycle management (see LO-5), nor on authorization and RBAC (see LO-6/LO-7) — it is about how to verify who someone is when they attempt to access resources.

Reference: Ch. 2, §2.1–2.2, p. 41–65 of the AZ-305 exam book.

Why This Matters

Authentication is the foundation of every secure Azure architecture. Microsoft reports that organisations enabling MFA block over 99.9% of account-compromise attacks. As an architect designing infrastructure for financial services, healthcare, or enterprise SaaS, you must choose between basic username-password, multi-factor methods, passwordless approaches, and federation patterns. The wrong choice costs companies millions in downtime and compliance fines — the right choice enables a workforce to be productive, mobile, and secure. The AZ-305 exam tests your ability to match authentication mechanisms to real-world constraints: device fleets, regulatory mandates, user populations, and risk tolerance.

Prerequisites

• Authentication vs. authorisation — Can you explain why verifying who someone is (authentication) is separate from deciding what they can do (authorisation)? Self-check: if a user passes MFA but has no RBAC role, can they read a Storage blob?
• Entra ID tenant basics — Do you know what a tenant is and how it isolates users? Self-check: can a user in Tenant A directly sign in to resources in Tenant B without an invitation?
• Token-based access — Can you describe why APIs accept tokens instead of passwords? Self-check: what happens when a JWT access token expires — does the user re-enter their password?
• Hybrid identity awareness — Do you know the difference between cloud-only and synced (hybrid) identities? Self-check: what tool synchronises on-premises AD users to Entra ID?

Learning Objectives

By the end of this lesson you will be able to:

1. Analyse authentication requirements across on-premises, cloud, and hybrid identity scenarios and recommend the appropriate Entra ID deployment model.
2. Evaluate MFA methods and Conditional Access policies against organisational risk profiles and design a policy framework that balances security with usability.
3. Design passwordless authentication implementations using FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator passwordless sign-in.
4. Recommend the correct authentication protocol (SAML 2.0, OAuth 2.0, OIDC) for federation with third-party identity providers or SaaS applications.
5. Architect managed-identity solutions for Azure workloads that eliminate stored secrets.
6. Assess B2C and external-identity scenarios for customer-facing and partner-facing applications.

Building Blocks

Entra ID (formerly Azure Active Directory) — Analogy: Azure's phone book and security guard rolled into one — the phone book lists all users and apps, and the guard checks ID before letting anyone in. → Formal definition: a cloud-based identity and access management service that authenticates users and apps, manages devices, and enforces policies across Microsoft and third-party cloud applications. → Why it matters: it is the core identity platform for Azure; without it there is no user access, no MFA, no Conditional Access, no federation.

Multi-Factor Authentication (MFA) — Analogy: requiring both a passport and a fingerprint scan to enter a building, rather than just the passport. → Formal definition: a security control that requires two or more independent verification factors — something you know, something you have, something you are — before granting access. → Why it matters: even if passwords are stolen, a second factor is exponentially harder to compromise; MFA reduces breach impact by 99% or more in empirical studies.

Conditional Access — Analogy: a bouncer who lets you in from your home office with just an ID but demands a fingerprint scan if you arrive from airport WiFi because the risk is higher. → Formal definition: a policy-driven authentication mechanism that grants, challenges, or denies access based on real-time signals — location, device health, user risk, application sensitivity. → Why it matters: it enables risk-based authentication, allowing legitimate users seamless access while blocking suspicious logins automatically.

Passwordless Authentication — Analogy: replacing a metal key with a biometric fingerprint reader that is unique to you and impossible to lose or share. → Formal definition: authentication methods that replace or eliminate the password — FIDO2 security keys, Windows Hello for Business (biometric or PIN), certificate-based auth, or Microsoft Authenticator phone sign-in. → Why it matters: passwords are the weakest link; passwordless methods are resistant to phishing and credential stuffing.

Authentication Protocol — Analogy: a standardised handshake between a user, an app, and an identity provider (IdP) so they all know each other and trust the exchange. → Formal definition: a technical specification for exchanging identity information; common ones are SAML 2.0 (XML-based federation), OAuth 2.0 (delegation/authorisation), and OIDC (authentication layer on top of OAuth). → Why it matters: each protocol solves a different problem; choosing the wrong one breaks interoperability or introduces security gaps.

Managed Identity — Analogy: a passport-less identity for an Azure resource (VM, Function, App Service) that Azure automatically manages — the service never stores a secret because Azure vouches for it at runtime. → Formal definition: an identity automatically created and managed by Azure for resources to authenticate to other Azure services without storing credentials. Two types: system-assigned (tied to one resource) and user-assigned (reusable across resources). → Why it matters: it eliminates connection strings and secrets from application code.

Deep Dive

Microsoft Entra ID Authentication Fundamentals

Entra ID is the identity layer for Azure. When a user logs in, Entra ID verifies credentials and issues a token. When an app wants to access another service, it authenticates via Entra ID and receives a token. All Azure resources check tokens from Entra ID to decide who you are.

Tenants and users:

Authentication flows:

[!NOTE] In hybrid scenarios (on-premises Active Directory + Entra ID), you use Microsoft Entra Connect Sync or Microsoft Entra Cloud Sync to synchronise identities. Seamless SSO lets domain-joined users sign in to cloud apps without re-entering credentials.

Multi-Factor Authentication and Conditional Access

MFA is no longer optional for sensitive workloads — it is a best practice and often a compliance requirement.

MFA methods ranked by strength:

Conditional Access policies evaluate signals at sign-in time and make a real-time grant/deny/challenge decision:

[!TIP] Start with a baseline: require MFA for Azure Portal, all admin roles, and sensitive apps. Use "Report-only" mode for 1–2 weeks before enforcing. Review the Entra ID sign-in logs to catch false positives before users are blocked.

Named locations and device compliance:

• A named location is an IP range (e.g., your office CIDR blocks) or country that Entra ID recognises as trusted.
• Device compliance checks whether a device meets Intune security baselines (BitLocker enabled, antivirus active, OS patched).
• Combining named locations + device compliance reduces false positives while maintaining strong security.

Passwordless Authentication

Passwordless eliminates the password entirely — a paradigm shift from "something you know" to "something you have" or "something you are."

FIDO2 security keys:

• A hardware device (USB, NFC, or Bluetooth) storing a private key.
• The key signs a challenge from the server without revealing the private key.
• Phishing-resistant: the key is domain-bound — an attacker cannot redirect it to a fake site.
• Deployment: register keys in the Entra ID portal or via Microsoft Authenticator.

Windows Hello for Business:

• Biometric (face/fingerprint) or PIN on a Windows device.
• Private key stored in the Trusted Platform Module (TPM), a hardware security chip.
• Requires Windows 10+ with TPM 2.0.
• Deploy via Intune or Group Policy.

Microsoft Authenticator passwordless:

• User sees a number-match prompt on their phone, confirms via biometric, done.
• Works cross-platform (iOS, Android) — ideal for BYOD.

Certificate-Based Authentication (CBA):

• Authenticate via X.509 certificate on a smart card or device.
• Common in government (e.g., US federal PIV/CAC) and regulated industries.

[!IMPORTANT] Passwordless does not mean MFA is unnecessary. Defence in depth means layering passwordless + Conditional Access + device compliance. A FIDO2 key satisfies both the "something you have" and "something you are" factors in a single gesture.

Authentication Protocols: SAML, OAuth 2.0, and OIDC

When integrating third-party applications or federating with partners, you must choose a protocol.

When to choose which:

Managed identities for workloads:

When an Azure resource (VM, Function App, Container Instance) needs to authenticate to another Azure service, use a managed identity.

[!WARNING] Never store connection strings or client secrets in application code or config files when a managed identity is available. Secrets in code leak via git history, error logs, and backup files. Use DefaultAzureCredential in your SDK calls — it automatically discovers managed identities at runtime.

B2C and External Identity Scenarios

Microsoft Entra External ID for customers is a separate service from Entra ID, designed for customer-facing consumer identity management.

B2C user flow example (sign-up/sign-in with social providers):

When to use B2C vs. External Identities:

• B2C: you are a SaaS provider or retailer with potentially millions of customer logins; you want full control over the sign-up/sign-in UX.
• External Identities: you are inviting a handful of partner organisations to collaborate inside your Entra ID tenant; they sign in with their home IdP.

Worked Examples

Easy — Single-Tenant Corporate MFA Rollout

Problem: A medium-sized insurance company (500 employees) uses Entra ID for Microsoft 365 and Azure resources. Currently they enforce passwords with no MFA. They must roll out MFA company-wide for SOC 2 Type II compliance. The workforce is 70% in two corporate offices, 30% remote.

Step-by-step solution:

1. Assess current state: check how many users have Microsoft Authenticator installed; identify any legacy apps that cannot support modern auth.
2. Phase 1 (Weeks 1–2): deploy Authenticator via Intune push or manual download. Provide training videos and helpdesk support.
3. Phase 2 (Week 3): enable MFA registration requirement; users register on next sign-in. Allow Authenticator (push), SMS, and FIDO2.
4. Phase 3 (Week 4): create a Conditional Access policy — Condition: all cloud apps, all users; Control: require MFA; Exclusion: 2 break-glass accounts.
5. Monitor: track adoption via Entra ID Authentication Methods Activity report. Follow up with non-compliant users.

[!NOTE] Most users will choose Authenticator (push notification). FIDO2 is ideal for admins and executives — consider it as a Phase 2 initiative.

Medium — Multi-Location Conditional Access with BYOD

Problem: A financial services firm ($2{,}000$ employees) has offices in New York, London, and Singapore. Employees use both personal laptops (BYOD) and corporate devices. They access Azure Portal, Dynamics 365, and custom banking APIs. They need to allow productivity but block risky logins (e.g., new country at 3 AM).

Step-by-step solution:

1. Define named locations: Corporate Network = IP ranges of the three offices; Allowed Countries = US, UK, Singapore.
2. Enable device compliance in Intune: require BitLocker, antivirus, no jailbreak. Non-compliant devices cannot access banking APIs.
3. Create Conditional Access policies:
   • Policy 1 (Sensitive Apps): Apps = Azure Portal + Dynamics + Banking APIs; Device not compliant → require MFA + compliant device.
   • Policy 2 (High Risk): Sign-in risk = high OR user risk = high → require MFA + password change.
   • Policy 3 (Location Block): Location = outside Allowed Countries → block access entirely.
4. Test: use Report-only mode for 1 week, review sign-in logs, adjust.

[!NOTE] Entra ID's impossible-travel detection is automatic. The key is interpreting the risk signals and mapping them to the right control — block vs. step-up MFA vs. allow.

Hard — Hybrid Identity with Federation, B2C, and Managed Identities

Problem: A healthcare company has $1{,}500$ employees on on-premises AD, a patient-facing mobile app ($100{,}000$+ users needing social login), and a backend microservice in Azure Container Instances that reads patient records from Azure SQL Database without storing secrets.

Step-by-step solution:

1. Hybrid identity: deploy Microsoft Entra Cloud Sync to synchronise on-premises AD users to Entra ID. Enable Seamless SSO so domain-joined users sign in to cloud apps automatically.
2. B2C for patients: create a separate Microsoft Entra External ID for customers tenant. Define a sign-up/sign-in user flow with Google, Facebook, and local email. Integrate the mobile app (iOS/Android) via MSAL. B2C returns an ID token + access token on sign-in.
3. Managed identity for the microservice: enable a system-assigned managed identity on the Container Instance. In Azure SQL Database, create a contained database user mapped to the MI. Grant SELECT on patient tables. In code, use DefaultAzureCredential to obtain a token scoped to https://database.windows.net.
4. Conditional Access for employees: require MFA for Salesforce; block high-risk countries; require compliant devices for Azure Portal.

[!NOTE] Three identity systems coexist: on-premises AD (employees, synced to Entra ID), Entra ID (cloud and hybrid), and B2C (patients). Each is isolated and purpose-built.

Visual Explanations

Entra ID Authentication Flow (Mermaid)

Caption: The basic authentication flow. The user provides credentials and MFA; Entra ID validates, evaluates Conditional Access, and issues a JWT. The resource verifies the token and grants access.

Conditional Access Decision Tree (Mermaid)

Caption: Conditional Access evaluates real-time signals (location, device state, risk level) and makes a dynamic decision: allow, challenge with MFA, or block.

Authentication Protocol Comparison (TikZ)

Caption: Evolution and comparison of authentication protocols. SAML 2.0 handles legacy federation, OAuth 2.0 handles API delegation, and OIDC extends OAuth with an authentication layer for modern apps.

Passwordless Methods Comparison Table

Caption: FIDO2 and Windows Hello are phishing-resistant and recommended for high-value accounts. Authenticator is the easiest cross-platform option. SMS should only be a fallback.

Common Mistakes

❌ Myth: "We require MFA for all users, so we are fully secure." ✅ Reality: MFA adds a second factor but does not adapt to risk. If an attacker compromises a password and tricks the user into approving an MFA push (MFA fatigue), they gain access. Conditional Access adds a third dimension: even if MFA passes, it can block access from high-risk locations or non-compliant devices. Why it's tricky: MFA feels like a complete solution because users see the second prompt. Conditional Access is invisible to legitimate users but invaluable against advanced attacks. Many teams stop after enabling MFA.

❌ Myth: "We use SAML for all cloud integrations because it is the enterprise standard." ✅ Reality: SAML was designed in the 2000s for on-premises federation. OIDC, built on OAuth 2.0, is the modern standard for cloud applications and APIs. Most SaaS apps prefer OIDC. Using SAML for a new cloud-native app is like insisting on fax when email is available — it works, but you lose features and integration capabilities. Why it's tricky: SAML is mature and stable; many architects learned it first. The mental model says "SAML = enterprise." But OIDC is now the enterprise standard for cloud; the switch requires updating app registrations but yields simpler code and better API support.

❌ Myth: "We store the database connection string in our app's config. It is in a private repo, so it is safe." ✅ Reality: Secrets in code leak via git history, error logs, deployment artefacts, and backup files. A junior developer commits a secret; it lives in the repo forever. A managed identity eliminates this risk entirely — Azure vouches for the app at runtime with a short-lived token. Why it's tricky: Managed identities require a mental shift from "here is the key, use it" to "Azure will give you a temporary key at runtime." The first approach feels simpler but is architecturally fragile.

❌ Myth: "All users must comply with our Conditional Access policies — no exceptions." ✅ Reality: If a Conditional Access misconfiguration blocks all users — including admins — you lose access to your tenant. You must maintain 2 break-glass (emergency access) accounts excluded from all policies. These accounts have long complex passwords, no MFA, are monitored by alerts, and are only used in emergencies. Why it's tricky: Excluding accounts feels insecure. But 2 heavily guarded break-glass accounts are far safer than a complete tenant lockout with no recovery path.

Practice Exercises

🟢 Easy — A start-up with 50 employees uses Entra ID for Microsoft 365. They have no MFA today. Which single Conditional Access policy should they deploy first?

▶💡 Hint

Think about the highest-risk access point that is also the easiest to protect.

▶✅ Solution

Require MFA for all users accessing all cloud apps. Exclude 2 break-glass accounts. This is the single highest-impact policy and covers the broadest attack surface. At 50 users, a blanket policy is manageable.

🟢 Easy — An app registration in Entra ID returns both an ID token and an access token after sign-in. Which authentication protocol is being used?

▶💡 Hint

SAML uses XML assertions. OAuth 2.0 returns only an access token. Which protocol adds an ID token on top of OAuth?

▶✅ Solution

OpenID Connect (OIDC). It extends OAuth 2.0 by adding an ID token (JWT with identity claims) alongside the access token.

🟡 Medium — A pharmaceutical company has offices in Boston and Toronto. Remote workers use personal laptops. They access a HIPAA-regulated patient records app on Azure App Service. Design a Conditional Access policy set.

▶💡 Hint

Consider: (1) named locations for offices, (2) device compliance for BYOD, (3) the sensitivity of HIPAA data, (4) break-glass exclusions.

▶✅ Solution

Policy 1: Condition = Patient Records App + location not in "Boston" or "Toronto" named locations → Control = require MFA. Policy 2: Condition = Patient Records App + device not Intune-compliant → Control = require MFA + compliant device. Exclusion on both: break-glass accounts and service accounts. This allows office workers frictionless access on compliant devices while remote/BYOD users must satisfy MFA and device compliance.

🟡 Medium — A web app on Azure App Service needs to read secrets from Azure Key Vault. Currently the connection string is in appsettings.json. Redesign this using a managed identity.

▶💡 Hint

Enable a system-assigned managed identity on the App Service. Grant it an access policy on Key Vault. Update the code to use DefaultAzureCredential.

▶✅ Solution

Enable the system-assigned managed identity on the App Service (Bicep: identity: { type: 'SystemAssigned' }). In Key Vault, create an access policy granting Get and List secrets permissions to the App Service's principal ID. In code, replace the connection string with new SecretClient(vaultUri, new DefaultAzureCredential()). Remove the secret from appsettings.json and git history entirely.

🔴 Hard — A logistics company wants to: (a) allow $10{,}000$+ customers to track shipments via a web portal with social login, and (b) allow 5 partner logistics companies to access a shared shipment database (read-only). Should they use Microsoft Entra External ID for customers, Entra ID External Identities, or a combination? Justify.

▶💡 Hint

Consider scale ($10{,}000$+ vs. 5), governance (self-service vs. admin-provisioned), social login needs, and identity isolation.

▶✅ Solution

Customers: Use Microsoft Entra External ID for customers. Rationale: $10{,}000$+ external, unmanaged identities at consumer scale. B2C supports social login (Google, Facebook), self-service sign-up, and is isolated from the corporate tenant. Partners: Use Entra ID External Identities (B2B guest). Rationale: only 5 known organisations; invite their users as guests. They sign in with their home IdP and inherit your Conditional Access policies. Architecture: two separate identity systems — B2C for customers (public portal) and Entra ID for partners (governed, internal). This ensures compliance (customers never touch the corporate tenant) and appropriate scale.

🔴 Hard — A healthcare company has on-premises AD ($1{,}500$ employees), a patient mobile app ($100{,}000$+ users), and a backend microservice in Azure Container Instances that reads from Azure SQL Database. Design the complete authentication architecture covering all three identity populations.

▶💡 Hint

Think: (1) hybrid identity for employees, (2) B2C for patients, (3) managed identity for the microservice. How do these three coexist?

▶✅ Solution

Employees: deploy Microsoft Entra Cloud Sync to synchronise on-prem AD to Entra ID. Enable Seamless SSO for domain-joined devices. Apply Conditional Access policies (MFA for sensitive apps, compliant devices for Azure Portal). Patients: create a separate Microsoft Entra External ID for customers tenant. Define a sign-up/sign-in user flow with Google, Facebook, and local email. The mobile app uses MSAL to authenticate and receives ID + access tokens. Microservice: enable a system-assigned managed identity on the Container Instance. Create a contained database user in Azure SQL mapped to the MI. Grant db_datareader. In code, use DefaultAzureCredential for token-based SQL auth. Result: three isolated identity systems, zero stored secrets, strong MFA for employees, frictionless social login for patients.

Summary & Concept Map

• Entra ID is the foundational identity platform for every Azure authentication scenario — employees, apps, and services all authenticate through it.
• MFA + Conditional Access together form the modern security baseline: MFA alone is insufficient; Conditional Access adds risk-adaptive, context-aware enforcement.
• Passwordless methods (FIDO2, Windows Hello for Business, Microsoft Authenticator) eliminate the weakest link — the password — and should be the target state for all organisations.
• OIDC is the modern standard for SaaS and cloud app integration; use SAML 2.0 only for legacy federation scenarios that do not support OIDC.
• Managed identities eliminate stored secrets for Azure workloads — always prefer them over connection strings or client secrets.
• Use B2C for consumer-scale external identity (social login, self-service) and External Identities for governed B2B partner collaboration.
• Always maintain 2 break-glass accounts excluded from all Conditional Access policies to prevent tenant lockout.

Quick Note — Recommend an Identity Management Solution

This lesson covers the identity lifecycle—how on-premises and cloud-based identities are synchronized, provisioned, and managed in hybrid and cloud-native Azure environments. Based on AZ-305 exam guidance (Ch. 2, §2.2, p. 47–65), the focus is on synchronization strategy, Seamless SSO, group sync, B2B/B2C, and managed identities. Identity management is distinct from authentication (LO4) and authorization (LO6/7) — we emphasize the lifecycle: how identities are created, synced, and deprovisioned.

Decision anchors

Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.

Ninety-second explanation

Without notes, explain:

1. What requirement signals this learning objective rather than a neighbouring one?
2. Which two solution families are most likely to be compared?
3. Which hard constraint eliminates the strongest distractor?
4. What identity, network, data, or failure boundary must appear in the design?
5. Which operational test would prove the recommendation works?

Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.

When to open the full lesson

Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.

Source and freshness

Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.

Recommend an Identity Management Solution — Lesson

This lesson covers the identity lifecycle—how on-premises and cloud-based identities are synchronized, provisioned, and managed in hybrid and cloud-native Azure environments. Based on AZ-305 exam guidance (Ch. 2, §2.2, p. 47–65), the focus is on synchronization strategy, Seamless SSO, group sync, B2B/B2C, and managed identities. Identity management is distinct from authentication (LO4) and authorization (LO6/7) — we emphasize the lifecycle: how identities are created, synced, and deprovisioned.

Why This Matters

Identity management underpins security architecture. In hybrid organizations, on-premises directories contain thousands of user accounts; moving to Azure requires a synchronization strategy that is secure, low-latency, and maintainable. Wrong choices lead to:

• Orphaned accounts in the cloud with no on-premises counterpart (manual cleanup cost).
• Sync failures that break productivity (users cannot sign in).
• Security gaps (e.g., federation without proper token validation).
• B2B/B2C confusion (guest collaboration vs. customer identity, different policies).
• Managed identity misuse (resource-to-resource auth becomes fragile if you pick system-assigned when user-assigned is better).

AZ-305 expects you to recommend the right identity solution given a scenario: a multi-site enterprise, a startup going cloud-first, a partner ecosystem requiring B2B access, or a customer-facing app needing B2C. This lesson equips you to make that call.

Prerequisites

• Active Directory basics — domain controller, OU, group policy, trust relationships. Self-check: what is the role of a domain controller in Kerberos authentication?
• Microsoft Entra ID (Entra ID) fundamentals — tenants, users, groups, app registrations, role assignments. Self-check: what is the difference between a security group and a Microsoft 365 group in Entra ID?
• Azure networking — VNets, on-premises connectivity (ExpressRoute, VPN). Self-check: which connectivity method does Entra Connect use to reach Entra ID — internet HTTPS or private endpoint?
• PKI and certificates — SSL/TLS, token signing, federation metadata. Self-check: why does AD FS require a token-signing certificate?
• Authentication concepts — passwords, MFA, SSO, SAML, OAuth 2.0, OpenID Connect. Self-check: what is the difference between SAML and OpenID Connect?

Learning Objectives

After completing this lesson, you will be able to:

1. Evaluate synchronization methods (PHS, PTA, Federation) and recommend the right one for a given scenario (latency, security, complexity).
2. Configure Seamless SSO and explain how it interacts with PHS/PTA to reduce password prompts.
3. Design group synchronization (scoping filters, group writeback) for role-based access control in hybrid deployments.
4. Distinguish B2B from B2C identities and recommend collaboration tools (guest users, B2B cross-tenant access) vs. customer identity platforms (custom policies, external identity providers).
5. Choose between system-assigned and user-assigned managed identities for workloads and explain when to avoid managed identities entirely (switch to service principals).
6. Architect an end-to-end identity solution combining Entra Connect sync, Seamless SSO, managed identities, and B2B/B2C policies.

Building Blocks

Entra Connect — Analogy: think of a postal sorting office that takes letters from your local mailboxes (on-prem AD) and delivers copies to a central hub (cloud Entra ID) on a regular schedule. → Formal definition: an on-premises synchronisation engine (formerly Azure AD Connect) that replicates user, group, and contact objects from Active Directory to Microsoft Entra ID. It supports three authentication methods: PHS, PTA, and Federation. → Why it matters: Entra Connect is the bridge between your on-prem identity store and the cloud — getting its sync method and scoping right determines sign-in latency, disaster recovery posture, and compliance stance.

Password Hash Sync (PHS): Entra Connect hashes the user's on-prem password and syncs the hash to the cloud. The user types their on-prem password at cloud sign-in; Azure computes the hash and matches it. No password exposure over the internet.

Pass-Through Authentication (PTA): User enters password at cloud sign-in; Azure forwards it to an on-prem agent, which validates it against Active Directory. The password never leaves the organization.

Federation (AD FS) — Analogy: a trusted notary who vouches for your identity — the cloud never sees your password; it only sees the notary's signed stamp. → Formal definition: AD FS (or a third-party STS) acts as a trust broker; the user is redirected on-prem for authentication, and AD FS issues a SAML token back to Entra ID. → Why it matters: Federation gives full control over authentication logic (custom MFA, hardware tokens, biometrics) but carries the highest infrastructure and maintenance cost.

Seamless SSO — Analogy: an automatic badge swipe — your domain-joined laptop silently proves your identity via Kerberos, so you never type a password for cloud apps. → Formal definition: an optional add-on for PHS or PTA that uses the AZUREADSSOACC computer account in on-prem AD to issue Kerberos tickets accepted by Entra ID. → Why it matters: eliminates password fatigue for corporate network users without requiring Federation infrastructure.

Group Synchronization: Entra Connect syncs on-prem security groups and distribution groups to the cloud. Writeback allows cloud-created groups to sync back on-prem (requires Enterprise licensing).

Managed Identities: Azure resources (VMs, App Services, Functions, Logic Apps, Data Factory, Synapse, Kubernetes) get an identity from Entra ID without managing secrets. System-assigned = 1:1 with resource. User-assigned = many resources share one identity.

Service Principals: The Azure object backing an app registration or managed identity. Used for resource-to-resource authentication.

B2B (Business-to-Business): Invite external users (partners, vendors, contractors) as guests into your Entra ID tenant. They retain their home org identity. Useful for collaboration, not customer identity.

B2C (Business-to-Customer): A separate Entra ID B2C tenant for customer-facing apps. Customers sign up, reset passwords, and authenticate without an internal user account. Supports external identity providers (Google, Facebook, SAML, OpenID Connect).

Deep Dive

1. Synchronization Methods: PHS vs. PTA vs. Federation

Password Hash Sync (PHS)

• How it works: Every two minutes, Entra Connect hashes on-prem passwords (one-way, salted) and syncs them to the cloud. User signs into Azure with the same password.
• Pros: Low latency (no on-prem call required), simple to deploy, built-in disaster recovery (if on-prem AD is down, users can still sign in with cached credentials).
• Cons: Requires trust in Microsoft's hashing; not suitable if compliance mandates passwords never leave the office.
• Use when: You want simplicity, resilience, and cloud-first migration; you have reliable Entra Connect health monitoring.
• Infrastructure: One Entra Connect server (or two in staging for HA), no extra agents required.

[!TIP] Always enable Entra Connect Health monitoring alongside PHS — it surfaces sync failures, hash-mismatch events, and agent-health issues before users notice broken sign-ins.

Pass-Through Authentication (PTA)

• How it works: User enters password at cloud sign-in; Entra ID forwards the credential to an on-prem agent (running on a server or VM), which validates it against Active Directory. Password is never stored in the cloud.
• Pros: Passwords never sync or hash; passwords never stored in cloud; tight on-prem control (if you disable on-prem account, cloud access stops immediately); works with Seamless SSO.
• Cons: Extra on-prem infrastructure (agents); latency (on-prem call per sign-in); if agents fail, sign-in fails (need HA).
• Use when: Compliance requires passwords to never leave on-premises; you have reliable on-prem network connectivity and agent infrastructure.
• Infrastructure: 2–3 PTA agents on-prem (HA), each running the PTA agent service; ensure redundancy.

[!WARNING] If all PTA agents go offline simultaneously, users cannot sign in — there is no cached-credential fallback as with PHS. Deploy agents in at least 2 separate data centres or availability zones.

Federation (AD FS / Custom STS)

• How it works: User is redirected to an on-prem identity provider (AD FS, Okta, Ping Identity, etc.). The provider authenticates the user and issues a SAML 2.0 token; the user's browser posts the token to Entra ID, which trusts it and issues a cloud token.
• Pros: Full control over authentication (custom MFA, device checks, hardware tokens); integrates with third-party identity solutions; existing AD FS investment.
• Cons: Highest complexity; requires PKI, token signing certs, and federation metadata; single point of failure if on-prem STS is down; latency (user is redirected on-prem).
• Use when: You need custom authentication logic; you have an existing AD FS or third-party STS; you require on-prem MFA device integration.
• Infrastructure: AD FS farm (2+ servers for HA), WAP (Web Application Proxy) for external access, certificate management.

Decision Matrix

2. Seamless SSO and Group Synchronization

Seamless SSO

Enables silent, password-less sign-in when the user is on a domain-joined computer and within the corporate network.

• How: Browser sends an HTTP request with Kerberos ticket (created via Windows NTLM) to a special Azure endpoint. No password prompt.
• Works with: PHS and PTA (not Federation; Federation already handles on-prem auth).
• Setup: Entra Connect wizard, relies on the AZUREADSSOACC computer account in on-prem AD.
• Deployment: Requires group policy or registry to set Azure endpoints as trusted sites in Internet Explorer / Edge.
• Benefit: Reduces password fatigue; users expect seamless experience on corporate networks.

Group Synchronization

• Default: On-prem security groups and distribution groups sync to Entra ID (read-only unless writeback enabled).
• Scoping: Use Entra Connect filtering to sync only certain OUs, groups, or user cohorts (e.g., sales only, not finance). Reduces Entra ID object count and blast radius if sync misconfigures.
• Writeback: Cloud-created security groups can be synced back to on-prem AD (Enterprise P1 license required). Useful for role-based groups created in the cloud that need on-prem permissions.

[!NOTE] Dynamic membership groups created in Entra ID do not support writeback to on-premises AD. If your access model relies on dynamic groups, keep those assignments cloud-only and use static security groups for any on-prem permission grants.

• Group types: Mail-enabled security groups, distribution groups. Dynamic groups in the cloud do not sync back.
• Use case: Grant on-prem file share access based on cloud role membership, or cloud-based conditional access policies based on on-prem group membership.

3. B2B vs. B2C Identities

B2B (Business-to-Business) — Guest Users in Your Tenant

• Scenario: Partner company employees, external consultants, vendors need access to your Azure resources, Microsoft 365, or apps.
• Mechanism: Invite them as "Guest" users into your Entra ID. They authenticate to their home organization; you trust their home org's authentication.
• Identity: Guest user has a UPN like partner@partner.onmicrosoft.com#EXT#@yourtenant.onmicrosoft.onmicrosoft.com; their directory lives in their home tenant.
• Licensing: Guest users don't consume your Entra ID licenses; they consume licenses in their home org. You pay only if they access resources you own (Microsoft 365, Azure apps).
• Conditional access: You can enforce conditional access policies on guests (require MFA, device compliance).
• B2B Cross-Tenant Access: Advanced feature — configure mutual trust with partner tenants to simplify guest invitation and resource sharing.

• Use case: Allowing partners to collaborate on a project SharePoint site, granting a contractor access to a Web App, or giving vendors read access to a Power BI dashboard.

B2C (Business-to-Customer) — Customer Identity

• Scenario: Your app serves external customers. You need a way for customers to sign up, sign in, reset passwords, and authenticate without having them as internal users.
• Tenant: Separate Entra ID B2C tenant (different domain, different management).
• User journeys: Customizable flows—sign-up, sign-in, password reset, profile edit. You control UI, validation, and post-auth redirects.
• Identity providers: Customers can authenticate via their own credentials (email/password), or via external providers (Google, Facebook, Twitter, SAML, OpenID Connect).
• Custom policies: SAML and OpenID Connect support. Build complex auth flows (e.g., "sign in with LinkedIn, then MFA, then consent screen").

[!IMPORTANT] A B2C tenant is a separate Entra ID tenant — it does not share users, groups, or policies with your primary (workforce) tenant. Treat it as an independent boundary for licensing, compliance, and data residency.

• Licensing: B2C billing is per-authentication (monthly active users). Significantly cheaper than internal licensing for large customer bases.
• Use case: E-commerce site with millions of customers, SaaS platform with free tier sign-ups, mobile app with social login.

B2B vs. B2C Comparison Table

4. Managed Identities: System-Assigned vs. User-Assigned

Why Managed Identities?

When an Azure resource (VM, App Service, Function, etc.) needs to authenticate to another resource (Key Vault, storage account, SQL database), it needs credentials. Managed identities provide credentials automatically without you managing secrets.

System-Assigned Managed Identity

• Lifecycle: Created when the resource is created; deleted when the resource is deleted. 1:1 relationship.
• Identity: A service principal in Entra ID with the same name/ID as the resource.
• Scope: Can be accessed only by that one resource.
• Use when: Resource accesses a single backend (e.g., App Service → Key Vault). Tight coupling is acceptable.
• Cons: If you scale the resource (e.g., multiple App Service instances), they all share the same identity (no fine-grain audit trail per instance).

User-Assigned Managed Identity

• Lifecycle: Created separately, can be assigned to multiple resources. Many-to-one relationship.

• Identity: A standalone Entra ID service principal; you control its lifecycle.
• Scope: Can be shared across resources in the same or different resource groups/subscriptions.
• Use when: Multiple resources share the same backend identity, or you want to reuse an identity across deployments (Terraform, ARM templates).
• Pros: Better for Infrastructure-as-Code (lifecycle matches app tier, not individual resource). Easier to rotate (one change, all consumers updated).

System-Assigned vs. User-Assigned Decision

When NOT to Use Managed Identities

• Legacy app requires hardcoded connection strings or keys (use Key Vault reference or app settings instead).
• Cross-tenant authentication (managed identity works within one tenant; use service principal with certificate).
• Third-party service without Entra ID support (store secret in Key Vault, reference in app).

Worked Examples

Example 1: Easy — Single-Site Hybrid Sync

Scenario

A mid-size bank (500 users) has on-premises Active Directory and is piloting Azure cloud services. Users should sign into Azure apps with their current on-prem password. There are no special compliance mandates about password location. You need high availability and minimal on-prem infrastructure changes.

Solution

1. Deploy Entra Connect on a server (or VM) in the on-prem data center, with a staging replica for HA.
2. Choose PHS: Users sync to the cloud with password hashes. Setup is fast, and if on-prem AD goes down temporarily, users can still access cloud apps (cached login). Cost is minimal.
3. Enable Seamless SSO for domain-joined workstations: users on corporate network won't be prompted for password when accessing cloud apps.
4. Sync on-prem groups to govern access: Finance group in on-prem AD → Finance group in Entra ID → assign Azure RBAC roles or app access.
5. Monitor: Set up Entra Connect Health monitoring; alert on sync failures.

Example 2: Medium — Partner Collaboration with B2B

Scenario

A software vendor partners with an outsourced QA firm (20 employees) who need access to your Azure DevOps project, a shared SharePoint site, and a test environment. Grant access without creating internal accounts; restrict to test only.

Solution

1. Invite B2B guests: Use "Invite external user" in Entra ID. Guests authenticate to their home org (the QA firm's Entra ID or Microsoft account).
2. Azure RBAC assignment: Assign the QA team a custom role (Contributor on test RG, Reader on DevOps) at the test resource group scope.
3. Conditional access: Require MFA for guests accessing your environment (corporate policy). Guest must authenticate to their home org first; then Azure validates the token.
4. Application integration: If you have a custom web app, add the guest's home org tenant as an external identity provider (federated); they can sign in with their corporate credentials.
5. Monitor guest activity: Use Entra ID sign-in logs to audit guest access; revoke access by deleting the guest user (no cleanup in their home org).

Example 3: Hard — Multi-Tenant SaaS with Managed Identities and B2C

Scenario

You are building a SaaS analytics platform. Customers (enterprises) want to sign their end-users (employees) into your app using their own Entra ID (i.e., your app is a multi-tenant app in their Entra IDs). You also have a B2C tier for small business customers who sign up directly. Your backend consists of a Node.js App Service that calls a SQL database and reads/writes to a storage account. You need least-privilege access and audit trails per customer.

Solution

1. Multi-tenant app registration: Register your app in your tenant with "Accounts in any Entra ID tenant" (multi-tenant). Customers add your app to their Entra ID; their users sign in via Entra ID.
2. B2C for self-serve customers: Create a separate B2C tenant for direct sign-ups (email/password, Google login). B2C users are redirected to your multi-tenant app after signing in.
3. User-assigned managed identity for the App Service: Create one identity scoped to serve the app tier. It has:
   • db_datareader, db_datawriter roles in SQL Database.
   • Storage Blob Data Contributor on the storage account.
   • Key Vault Secrets User on the key vault (to fetch database connection string, API keys).
4. Token refresh logic: App Service code fetches a managed identity token at startup and caches it (with 1-minute refresh buffer). Call Key Vault and SQL via token.
5. Per-customer data isolation: App code filters data by customer_id (from the signed-in user's token claim). SQL row-level security (RLS) enforces this at the database layer.
6. Audit: Enable SQL audit and storage account logging. Managed identity sign-in attempts appear in Entra ID logs (track which tenant's users hit your app).

Visual Explanations

Diagram 1: Sync Methods at a Glance

Diagram 2: B2B Guest Collaboration Flow

Diagram 3: Managed Identity Lifecycle

Diagram 4: Group Sync with Writeback

Comparison Table: Identity Management Patterns

Example TikZ Figure: Seamless SSO Handshake

Managed Identity Costs and Coverage

Common Mistakes

❌ Myth: "We chose PTA, so passwords are more secure than PHS." ✅ Reality: PTA validates passwords on-prem, but the password transmission from client to cloud is over HTTPS — equally secure for both PHS and PTA. The real benefit of PTA is policy control: if you disable a user on-prem, cloud access stops immediately. Choose PTA for enforcement latency, not transport security. Why it's tricky: The name "Pass-Through" implies the password travels somewhere unsafe, but HTTPS protects the wire in both models.

❌ Myth: "Seamless SSO requires Federation (AD FS)." ✅ Reality: Seamless SSO works with PHS and PTA only — it does not work with Federation, because Federation already handles on-prem authentication via SAML token redirect. If you want silent Kerberos-based sign-in for domain-joined users, pair PHS or PTA with Seamless SSO. Why it's tricky: Federation also provides "single sign-on," but through a completely different mechanism (SAML redirect, not Kerberos ticket). The exam uses both terms and expects you to distinguish them.

❌ Myth: "We should sync all on-prem groups to the cloud; Entra ID will auto-manage them." ✅ Reality: Over-syncing groups clutters Entra ID and creates orphaned permissions. Use scoping filters in Entra Connect to sync only groups relevant to cloud workloads (e.g., functional teams, not legacy distribution lists). Entra ID does not auto-delete or auto-disable stale synced groups — you must audit and prune regularly. Why it's tricky: The default Entra Connect configuration syncs all groups, which feels like the safe choice. In practice it creates noise that makes RBAC auditing harder.

❌ Myth: "B2B guests can just use a personal Microsoft account — it works fine." ✅ Reality: B2B guests can authenticate with personal MSAs, but you cannot enforce conditional access policies (MFA, device compliance) on personal accounts. Best practice: require guests to authenticate to their organizational Entra ID. For freelancers without one, invite as personal MSA but layer stricter conditional access (always require MFA, restrict to managed devices). Why it's tricky: The invitation flow accepts any email, and personal MSAs "just work" — the security gap only surfaces when you try to enforce compliance policies.

❌ Myth: "System-assigned managed identity is always simpler — just use it everywhere." ✅ Reality: System-assigned is simpler per resource, but at scale (10 App Services each needing Key Vault access = 10 separate RBAC role assignments). User-assigned lets you manage one identity for all 10, with a single set of permissions. For Infrastructure-as-Code and production workloads, user-assigned is often the better choice. Why it's tricky: Tutorials and quickstarts default to system-assigned because it is one toggle in the portal. The operational cost only becomes visible when you manage dozens of resources.

❌ Myth: "Our company uses B2B for partners, so we don't need B2C." ✅ Reality: B2B is for partner/vendor collaboration (business-to-business); B2C is for customer-facing apps (business-to-customer). A company often needs both: B2B for vendor portal access, B2C for customer app logins. Conflating them leads to poor licensing (customers consuming workforce Entra ID seats) and poor UX (customers seeing internal org branding). Why it's tricky: Both involve "external users," and the Azure portal surfaces them in similar-looking blades — but their tenants, licensing, and policy models are completely different.

Practice Exercises

Exercise 1: Sync Method Decision 🟢 Easy

Scenario: A healthcare provider has $5,000 users in on-prem AD. Compliance (HIPAA) mandates that passwords never leave the organization's network. The organization has reliable fiber connectivity and a 99.9% uptime SLA on-prem. Cloud apps should be available even if on-prem AD is temporarily down. Which sync method do you recommend, and why?

▶💡 Hint

Which sync methods keep passwords entirely on-premises? Consider the compliance requirement first, then availability.

▶✅ Solution

PTA + Seamless SSO. HIPAA rules out PHS (password hashes are sent to the cloud, even though hashed). Federation is overly complex here (no custom auth logic mentioned). PTA validates passwords on-prem and pairs with Seamless SSO for silent sign-in on domain-joined workstations. Deploy 2–3 PTA agents across separate sites for HA — if one AD server is down, users authenticate via another agent.

Exercise 2: B2B Guest Conditional Access 🟡 Medium

Scenario: Your company (Acme Corp) invites a guest user from PartnerCorp. The guest should access Acme's Azure SQL Database via Azure Data Studio, but only from Acme's corporate network or from a company-issued laptop with Intune compliance. What conditional access policy would you create?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a conditional access policy with the following conditions:

• Users: Guest user (or "External users" if templated).
• Apps: Target the SQL Database or the Azure portal (depending on access method).
• Conditions:
  • Location: Allow only known corporate IP ranges or trusted locations.
  • Device: Require device compliance (Intune enrollment, or trusted device from partner org).
  • Sign-in risk: Low (do not allow risky sign-ins).
• Grant: Require MFA and compliant device.
• Session: Apply app-enforced restrictions (IP pinning, session timeout).

Why this works: Guests authenticate to their home org (PartnerCorp); Entra ID in Acme's tenant trusts that auth and layers on additional checks (MFA, device compliance, location). If the guest's device is not managed or they sign in from an unexpected location, access is blocked.

Exercise 3: Managed Identity for Multi-Database App 🟡 Medium

Scenario: You have an App Service that reads from a SQL Database (read-only query), writes to another SQL Database (operational data), and uploads files to a storage account. You want to minimize secrets in your app config. Should you use one system-assigned identity or create a user-assigned identity? Explain your choice.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a user-assigned managed identity (not system-assigned).

Rationale:

• A single user-assigned identity can be assigned to the App Service and given granular RBAC roles: db_datareader on DB1, db_datawriter on DB2, Storage Blob Data Contributor on the storage account.
• If you scale the App Service (add multiple instances), all instances share the same identity, making audit trails cleaner (one identity per app tier, not per instance).
• User-assigned identity is portable: if you redeploy the app (IaC/Terraform), the identity persists independently, so you don't lose permissions.
• Although system-assigned would also work functionally, user-assigned is operationally superior for multi-resource scenarios and Infrastructure-as-Code patterns.

Exercise 4: B2C Custom Policy Flow 🟡 Medium

Scenario: Your B2C tenant serves two types of customers: "Premium" (must authenticate via corporate SAML) and "Free" (can sign up with email/password). Design a user journey that branches on sign-up based on customer tier.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Create a B2C custom policy with the following elements:

1. Sign-up form: Collect email, password, and a "Tier" selection (radio: Premium/Free).
2. Conditional orchestration:
   • If Tier = "Premium": Redirect to SAML federated identity provider (customer's corporate SAML).
   • If Tier = "Free": Proceed with email/password validation and account creation.
3. Token claim: Add a tier claim to the final token, so your app can enforce tier-based permissions.
4. Redemption: Issue an ID token with the tier claim to your app; app uses it to apply tier-specific UI (e.g., premium features disabled for free tier).

Exercise 5: PHS to PTA Migration 🔴 Hard

Scenario: Your company used PHS for $2,000 users. A new compliance requirement mandates password hashes never leave on-prem. You must migrate to PTA without downtime. Outline the steps.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Deploy 2–3 PTA agents on separate on-prem servers; set up a staging Entra Connect instance. Enable PTA in the Entra Connect wizard while keeping PHS temporarily active. Pilot with 50 test users, then roll out department-by-department over 1–2 weeks. Monitor sign-in failures in Entra ID logs. Once all users are on PTA, disable PHS to remove password hashes from the cloud. Keep PHS as a documented rollback plan.

Exercise 6: Choosing System-Assigned vs. User-Assigned at Scale 🟡 Medium

Scenario: You manage a microservices platform with 20 stateless services deployed on AKS, App Services, and Functions. Each service accesses a central SQL Database, a shared Key Vault, and a logging storage account. You're using Terraform to manage all infra. Would you use system-assigned or user-assigned managed identities, and why?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer: Use user-assigned managed identities, one per service tier (not per instance/pod).

Rationale:

• Scale: With 20 services, system-assigned would create 20 separate identities, each with its own RBAC bindings. User-assigned lets you group them logically: one identity per service tier (web, api, worker), reducing management overhead.
• IaC lifecycle: Terraform manages the app deployment; if you redeploy a service, a new system-assigned identity is created, losing RBAC permissions. User-assigned identity persists across redeployments (you define it as a separate Terraform resource).
• Audit trails: One identity per service tier is cleaner in audit logs; you see "api-service-identity accessed Key Vault" rather than "app-service-instance-12 accessed Key Vault."
• Migration: If you later move a service from App Service to AKS, the identity is reusable (just re-assign it to the new workload).

Exercise 7: Disaster Recovery Scenario 🔴 Hard

Scenario: A company uses PTA for sign-in. During a data-center outage, all on-prem PTA agents become unreachable for 2 hours. Users cannot sign into Azure apps. What could have mitigated this, and what actions do you take during/after?

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer:

Mitigation: Deploy PTA agents across 2+ data centres/availability zones, co-located with AD replicas. Enable PHS as a warm standby — if all agents fail, cached hashes provide sign-in continuity. During outage: Monitor Entra ID sign-in logs; alert on-prem IT; consider temporary PHS enablement. After: Verify agent health via Entra Connect Health; review locked-out accounts; implement PTA agent availability alerts.

Exercise 8: B2B + B2C Architecture 🔴 Hard

Scenario: Your organization runs both a B2B SaaS product (partners collaborate on projects) and a B2C product (customers subscribe and use features). Describe how you would architecture identities for this scenario to keep B2B and B2C separate and secure.

▶💡 Hint

Consider the key decision factors for this scenario.

▶✅ Solution

Answer:

Tenant A (Production): Internal users via Entra Connect (PHS + Seamless SSO); B2B guests from partner orgs. Tenant B (B2C): Separate B2C tenant for customer sign-ups (email/password, social IdPs). Backend: Single API deployment accepts tokens from both tenants; shared database uses row-level security (RLS) filtered by tenant_id. RBAC: Tenant A uses Azure RBAC for partners; Tenant B uses app-level tier logic for customers. Why separate: Isolation prevents cross-tier access, simplifies compliance (B2C may have different data residency), and avoids customers consuming workforce Entra ID licenses.

Summary & Concept Map

Key Takeaways

1. Sync method choice (PHS, PTA, Federation) depends on latency tolerance, on-prem infrastructure capacity, and compliance policy. PHS is simplest; PTA is most secure; Federation is most flexible but complex.

2. Seamless SSO layers atop PHS or PTA to give domain-joined users silent sign-in (no password prompt). Requires Kerberos delegation and special setup (AZUREADSSOACC account).

3. Group synchronization bridges on-prem and cloud: on-prem groups sync to cloud (read-only by default); cloud-created groups sync back with writeback (Enterprise license required). Use scoping to avoid sync bloat.

4. B2B is for partner/vendor collaboration (guests in your tenant, home org identity). B2C is for customers (separate tenant, customer-managed identity). Both serve different use cases and licensing models.

5. System-assigned managed identities are 1:1 with a resource; user-assigned are reusable. User-assigned is better for scale and IaC; system-assigned is simpler per-resource. Choose based on lifecycle alignment.

6. Avoid managed identities if your resource doesn't support them (use service principals instead) or if you need cross-tenant auth (use certificates, not tokens).

Concept Map