14.1 Cross-Domain Scenario Practice: Combining Identity, Data, Continuity & Infrastructure Decisions

Why cross-domain scenarios are the real AZ-305 test

Every earlier chapter in this guide isolated one design skill at a time: how to design authentication, how to pick a storage redundancy tier, how to size a recovery objective. The real AZ-305 exam does not test skills in isolation. A single scenario stem routinely bundles an identity requirement, a data requirement, a continuity requirement, and an infrastructure requirement into one company profile, then asks for one architecture decision that has to satisfy all of them at once. Microsoft's own guidance for this exam states that questions "present complex scenarios requiring trade-off analysis" rather than single-fact recall — that is the whole difference between AZ-305 and an implementation exam like AZ-104.

This matters because the domain weights (25-30% Identity/Governance/Monitoring, 20-25% Data Storage, 15-20% Business Continuity, 30-35% Infrastructure) describe how often a domain is the primary subject of a question, not how often it appears as a supporting constraint. A question whose primary subject is Infrastructure (network topology) can still fail you if you ignore an embedded Identity constraint ("subsidiary must keep its own on-premises AD DS as the identity source") or a Continuity constraint ("the design must support a 15-minute RTO"). Practicing scenarios that cross domains — rather than only drilling isolated flashcard-style facts — is what closes the gap between "I know the services" and "I can pass AZ-305."

A four-step method for decomposing a multi-domain stem

1. List every requirement as its own line. Do not read the paragraph once and jump to the options. Physically (or mentally) break the scenario into bullet points — one bullet per stated requirement or constraint.
2. Tag each requirement to a domain. Identity/Governance/Monitoring, Data Storage, Business Continuity, or Infrastructure. Some bullets touch two domains (for example, "quarterly access review for the subsidiary's admins" is Identity and Governance).
3. Find the requirement with a hard number or hard word. Numbers (RTO, RPO, latency, percentage, region count) and hard words ("must," "cannot," "no additional hardware," "minimal application changes") eliminate the most wrong answers fastest. Start there, not with the domain you personally find easiest.
4. Re-check the surviving option against every OTHER domain's requirement. The most common trap is an option that satisfies the domain the question looks like it is about while quietly violating a requirement from a different domain buried earlier in the stem.

Worked scenario 1: acquisition with conflicting constraints

Scenario: Contoso Ltd. runs a three-tier order-processing application in a single Azure region. Contoso has just acquired a subsidiary that operates its own on-premises Active Directory Domain Services (AD DS) forest and a large SQL Server database. The architecture must: (1) give subsidiary users single sign-on to the existing application without creating duplicate cloud identities; (2) migrate the subsidiary's SQL Server database to Azure with minimal changes to existing stored procedures, SQL Agent jobs, and linked-server references; (3) guarantee the application can fail over to a secondary Azure region with a Recovery Time Objective (RTO) of 15 minutes and a Recovery Point Objective (RPO) of 5 minutes; (4) keep all new diagnostic data flowing into the existing Log Analytics workspace rather than a new one.

Notice that three of the four correct answers are the "less exciting" option (auto-failover group over disaster recovery scripting, existing workspace over a new one). AZ-305 consistently rewards the option that satisfies every stated constraint over the option that showcases the newest or most powerful service.

Worked scenario 2: global retail data residency

A second pattern worth practicing: a global retailer needs (a) per-region data sovereignty because of local regulation, (b) low-latency writes from IoT point-of-sale devices in multiple regions, and (c) delegated administration so each region's IT team can manage only its own resources. The cross-domain answer combines Cosmos DB with multi-region writes (data, low-latency writes per region), Azure Policy scoped per management group to enforce data-residency rules (governance), and RBAC role assignments scoped to each region's resource group (identity) — three different domains, one coherent design. A wrong-but-plausible answer might recommend a single global SQL Database with read replicas; that satisfies "low latency reads" but not "low-latency writes" in every region, which is the differentiating word in the stem.

Practice questions

Key takeaways for cross-domain practice

• Break every scenario into individually tagged requirement bullets before touching the answer options — do not read once and jump.
• Numbers (RTO, RPO, latency, region counts) and absolute words ("minimal," "no additional hardware," "must not") are usually the fastest requirement to resolve first, regardless of which domain they belong to.
• The correct answer typically satisfies every stated constraint at once, even if it looks like the "boring" or less powerful service compared to a competing option.
• Re-check any surviving answer against requirements from other domains in the stem — that is where AZ-305's hardest traps live.
• Practice full-length, mixed-domain runs (not domain-filtered drilling) in your final weeks so the cross-domain reflex is automatic on exam day.