How to pass Designing Microsoft Azure Infrastructure Solutions (AZ-305)
19 min read4 domains coveredFree practice, no sign-up
AZ-305 (Designing Microsoft Azure Infrastructure Solutions) is Microsoft's expert-level architecture exam. It tests one skill above feature recall: turning a set of business and technical requirements into the right Azure design. You are handed a scenario with constraints on identity, governance, cost, recovery objectives, compliance, and operational overhead, then asked which service, tier, topology, or policy meets all of them at once. The hard part is rarely knowing what a service does. It is knowing which option wins when three of them would plausibly work and only one satisfies every constraint in the stem.
It suits practising architects and senior engineers who already build on Azure: solution architects, infrastructure leads, and platform engineers who design identity, governance, monitoring, storage, continuity, and infrastructure across an organisation. The four domains map to those design areas, and the questions assume you have lived with management groups, RBAC, landing zones, failover groups, recovery objectives, and hub-and-spoke networks, not just read about them. Expect multiple choice, multiple response, and case studies where several screens of requirements feed a cluster of design decisions.
The exam rewards requirement-driven design rules, not datasheets. Most items are short scenarios where two or three answers are technically capable and only one fits once you weigh the named constraint: the strictest recovery objective, the lowest operational overhead, the tier that actually supports the feature, or the documented platform limit. That is why practising on scenario questions with a worked explanation, and a reason every wrong option is wrong, beats memorising service comparison tables. AZ-305 sits one level above AZ-104: you are no longer configuring resources, you are choosing and justifying the architecture.
AZ-305 is a requirement-to-design exam: almost every question is a scenario with constraints on identity, governance, recovery objectives, cost, and operations, and the right answer is the Azure service, tier, or topology that satisfies every constraint, usually the managed option that meets the requirement at the least overhead.
Difficulty
Advanced
Best for
Practising Azure solution architects and senior infrastructure engineers who already design identity, governance, monitoring, storage, business continuity, and infrastructure on Azure, and need to prove they can choose and justify the right design under real organisational constraints.
Prerequisites
None enforced, but this is an expert-level exam built for people with real architecture experience. Microsoft expects strong working knowledge of Azure administration (the AZ-104 skill set) plus hands-on exposure to identity, governance, networking, data platforms, and business continuity. Without that grounding the case studies are very hard.
Typically 40 to 60 questions
Questions
120 min
Time allowed
700 / 1000
Pass mark
$165
Exam cost (USD)
258
Practice questions
How this exam thinks
One habit decides this exam: read the scenario for every constraint, then pick the design that satisfies all of them rather than the one that satisfies the most obvious one. Almost every question is a short business situation with stated limits on identity model, governance scope, recovery objective, cost, compliance, or operational overhead, and the answer is the Azure service, tier, topology, or policy that meets each limit at once. Several options will be technically capable. Only one fits once you weigh what the scenario actually asked for, and case studies stack several of these decisions on one shared set of requirements.
The default tie-breaker is the managed, requirement-fit option at the least operational overhead. Microsoft designs the exam around its own well-architected guidance, so when two answers both work, prefer the one that is more managed and aligned to the documented pattern: a user-assigned managed identity to share an identity across resources, customer-managed failover so the business keeps control of timing, synchronous replication across availability zones and asynchronous across regions, CQRS when reads and writes must scale apart. Reach for the heavier or less obvious option only when the scenario names a reason, such as near-100 percent SQL Server compatibility forcing Managed Instance, an existing Kubernetes ecosystem forcing AKS, or multi-region API Management forcing the Classic Premium tier.
The rest is a set of discriminations the exam leans on, each driven by a constraint. Match the tier to the feature (multi-region API Management is Classic Premium only; Hyperscale is Azure SQL Database only). Match the control to the requirement (Azure Policy and management groups for guardrails, RBAC for who can act, diagnostic settings for where logs go). Match the recovery design to the objective (availability zones for zone resilience, multi-region for regional resilience, the right replication mode for the RPO). And respect the documented platform limit: 500 Recovery Services vaults per subscription, ASR crash-consistent points fixed at five minutes, one of each destination type per diagnostic setting. Name the constraints, then choose the design built for them.
What each domain tests and how to study it
The AZ-305 blueprint is split across 4 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Given an organisation's identity, governance, and observability requirements, design the authentication and authorisation model, the management-group and policy hierarchy, and the monitoring and diagnostic topology that enforce least privilege and meet the stated residency, retention, and visibility constraints.
In one sentenceThe control-plane domain: designing who can do what, what is allowed at all, and how you see everything, using Entra and RBAC, management groups and Azure Policy, and Azure Monitor with Log Analytics.
Recall check: answer these from memory first
When must you use a user-assigned managed identity instead of a system-assigned one, and why does sharing across resources force that choice?
Which requirements justify creating an additional Log Analytics workspace rather than consolidating into one, and which tempting reason does not?
What does Azure Policy plus management groups give you that an RBAC role assignment does not, and how far down does each reach?
How many destinations of one type can a single diagnostic setting target, and how do you fan logs to two Log Analytics workspaces?
What it tests. Designing the governance and observability backbone before workloads land. Authentication and authorisation with Microsoft Entra ID and Azure RBAC (least privilege, system-assigned versus user-assigned managed identities, scoping role assignments); governance with management groups, Azure Policy, and landing zones for guardrails that apply across subscriptions; and logging and monitoring with Azure Monitor, Log Analytics workspace design (when to add a workspace for residency, retention, or billing separation), diagnostic settings, and Application Insights for application and AI-agent observability.
How to study it. Learn each control by the requirement it answers, because the exam tests the choice, not the click path. For identity, fix the managed-identity rule: system-assigned is one-per-resource and shares that resource's life cycle, so a shared identity across resources forces user-assigned. For governance, separate the two layers: RBAC grants a principal permission to act, Azure Policy plus management groups set guardrails on what is allowed at all and inherit down the hierarchy. For monitoring, drill Log Analytics workspace design as a decision (add a workspace for per-tenant residency, divergent retention in the same table, or split billing, not for cost arbitrage) and learn the diagnostic-settings constraint that one setting allows one of each destination type. Practise reading a requirement and naming the single control that fits.
Easy to confuse
System-assigned versus user-assigned managed identity. A system-assigned identity is tied to exactly one resource and shares its life cycle, so it cannot be reused across resources; a user-assigned identity is a standalone resource you attach to many. If the scenario wants several resources to share one identity or one set of RBAC assignments, it is user-assigned.
Azure RBAC versus Azure Policy. RBAC controls who can perform actions on a resource (grant a principal a role at a scope); Azure Policy controls what configurations are allowed at all and can deny or remediate regardless of who acts. RBAC is about permission, Policy is about compliance guardrails, and both inherit down management groups.
Worked example from the AZ-305 bank
lock_openFree sampleDesign Identity, Governance, and Monitoring Solutionsmedium
A platform team plans to attach one system-assigned managed identity to two virtual machines to consolidate RBAC assignments. A system-assigned managed identity can be associated with more than one Azure resource so multiple VMs can share a single identity. Is this statement correct?
AYes
BNocheck_circle Correct
System-assigned managed identities are one per resource; sharing requires user-assigned. System-assigned managed identities can only be associated with a single Azure resource and share its life cycle. To share an identity across multiple Azure resources, the documented pattern is a user-assigned managed identity.
Why A is wrong: Treating system-assigned as shareable is a common shortcut that fails at deployment time; the assignment is bound to a single parent resource and cannot be attached to a second.
Why B is correct: Correct. System-assigned managed identities can only be associated with a single Azure resource and share its life cycle.
What you must be able to do. Given an access pattern with stated consistency, compatibility, latency, and continuity requirements, select the relational, NoSQL, or unstructured store and its configuration, and choose the right integration tool, rather than the service you know best.
In one sentenceThe data-platform domain: reading the access and compatibility requirement and choosing the right store and consistency model, from Azure SQL and Managed Instance to Cosmos DB and Storage, plus the integration tooling.
Recall check: answer these from memory first
Which three traits distinguish Azure SQL Managed Instance from Azure SQL Database, and which capability is exclusive to SQL Database?
Why can a Cosmos DB account with multiple write regions not use Strong consistency, and what does that tell you about the trade-off?
Which Cosmos DB API lets a team lift and shift an existing Azure Table Storage workload without rewriting client code?
Customer-managed or Microsoft-managed failover policy when business owners must control when failover happens, and why?
What it tests. Matching storage to requirement and configuring it correctly. Relational data with Azure SQL Database and SQL Managed Instance (compatibility, private endpoints, Hyperscale, failover-group policy); semi-structured and unstructured data with Azure Cosmos DB (API selection for migration, consistency levels and their interaction with multi-region writes) and Azure Storage; and data integration with Azure Data Factory, Synapse Analytics, and Databricks for moving and transforming data at scale.
How to study it. Build a storage-selection decision tree and drill it, because this domain is largely selection plus a few configuration traps. Start from the requirement: near-100 percent SQL Server compatibility for a lift-and-shift points to SQL Managed Instance (private endpoint by default, Agent, Service Broker, cross-database queries), while Hyperscale and the cheapest single-database PaaS point to Azure SQL Database. For Cosmos DB, learn API-by-migration (Table Storage maps to API for Table, MongoDB to API for MongoDB) and the hard rule that Strong consistency is incompatible with multiple write regions. For continuity inside the data tier, know that customer-managed (manual) failover is the recommended default so the business keeps control of timing. Practise naming the one store and one setting that satisfy every named constraint.
Easy to confuse
Azure SQL Database versus SQL Managed Instance. SQL Database is the per-database PaaS with the broadest scale features including Hyperscale up to very large databases; Managed Instance gives near-100 percent SQL Server compatibility, a private VNet endpoint by default, and instance-scoped features like SQL Agent, Service Broker, and cross-database queries. Choose MI when compatibility for a lift-and-shift is the constraint, SQL Database otherwise.
Microsoft-managed versus customer-managed failover policy. Customer-managed (manual) failover keeps the decision and timing with the business and is the documented recommended default; Microsoft-managed (automatic) fires only on a widespread regional outage after a grace period and removes that control. If a runbook needs humans to make the call, it is customer-managed.
Worked example from the AZ-305 bank
lock_openFree sampleDesign Data Storage Solutionsmedium
Which characteristics correctly describe Azure SQL Managed Instance compared to Azure SQL Database? (Select 3 answers)
AProvides close to 100% SQL Server compatibility for lift-and-shift workloads from on-premises.check_circle Correct
BExposes the SQL endpoint only through a private IP address by default during provisioning.check_circle Correct
CSupports cross-database queries, SQL Server Agent, and Service Broker natively in the engine.check_circle Correct
DSupports the Hyperscale service tier for databases up to 128 TB capacity per instance.
EPermits user databases up to 4 TB with native columnstore indexes on every service tier.
MI = near-100 percent SQL Server compatibility, private endpoint by default, Agent/Service Broker/cross-DB; Hyperscale is SQL Database only. Managed Instance is positioned as the high-compatibility PaaS landing zone: near-100 percent SQL Server feature compatibility, a private VNet endpoint by default, and instance-scoped features such as Agent, Service Broker, cross-database queries, and CLR. Hyperscale is exclusive to Azure SQL Database.
Why A is correct: Correct. Provides close to 100% SQL Server compatibility for lift-and-shift workloads from on-premises is one of the keyed answers. Managed Instance is positioned as the high-compatibility PaaS landing zone: near-100 percent SQL Server feature compatibility, a private VNet endpoint by default, and instance-scoped features such as Agent, Service Broker, cross-database queries, and CLR.
Why B is correct: Correct. Exposes the SQL endpoint only through a private IP address by default during provisioning is one of the keyed answers. Managed Instance is positioned as the high-compatibility PaaS landing zone: near-100 percent SQL Server feature compatibility, a private VNet endpoint by default, and instance-scoped features such as Agent, Service Broker, cross-database queries, and CLR.
Why C is correct: Correct. Supports cross-database queries, SQL Server Agent, and Service Broker natively in the engine is one of the keyed answers. Managed Instance is positioned as the high-compatibility PaaS landing zone: near-100 percent SQL Server feature compatibility, a private VNet endpoint by default, and instance-scoped features such as Agent, Service Broker, cross-database queries, and CLR.
Why D is wrong: Hyperscale is an Azure SQL Database service tier; Managed Instance offers General Purpose, Next-gen General Purpose, and Business Critical, with no Hyperscale tier.
Why E is wrong: The 4 TB cap and tier-specific columnstore behaviour described is an Azure SQL Database limit; Managed Instance has its own storage limits per tier and supports columnstore on the SQL Server engine surface.
What you must be able to do. Given recovery point and recovery time objectives with cost and scope constraints, design the backup, disaster-recovery, and high-availability solution that meets the RPO and RTO while respecting documented platform limits and replication trade-offs.
In one sentenceThe resilience domain: turning RPO and RTO targets into a backup, replication, and availability-zone or multi-region design that actually meets them within Azure's documented limits.
Recall check: answer these from memory first
What is the documented replication split for high-priority versus lower-priority data across availability zones and regions, and why is synchronous cross-region not the default?
What is the per-subscription limit on Recovery Services vaults, and how does a 600-vault isolation requirement comply with it?
How often does Azure Site Recovery create crash-consistent recovery points, and can that cadence be tightened?
Which behaviours apply to a Cosmos DB account with multiple write regions regarding consistency, downtime, and RPO?
What it tests. Designing for survival of failures. Backup and disaster recovery with Azure Backup (Recovery Services vaults and their per-subscription limits) and Azure Site Recovery (replication policy, fixed crash-consistent recovery-point cadence, RTO behaviour); and high availability with availability zones, availability sets, and multi-region architectures, including the documented replication split of synchronous across zones and asynchronous across regions, and Cosmos DB multi-region write behaviour against RPO and RTO targets.
How to study it. Anchor every answer to a recovery objective and a documented limit. Learn the WAF replication pattern as a default: synchronous replication across availability zones for high-priority data, asynchronous across regions for lower-priority data, because synchronous cross-region replication is rarely recommended due to latency. Learn the platform ceilings the exam loves: Recovery Services vaults cap at 500 per subscription (so a 600-vault isolation design must span subscriptions), and ASR crash-consistent recovery points are fixed at five minutes and cannot be tightened. For Cosmos DB continuity, tie multi-region writes to their RPO behaviour (under 15 minutes for Session, prefix, and eventual; no Strong consistency; no expected downtime when SDK region preferences are set). Practise mapping an RPO or RTO straight to the zone-versus-region and replication-mode choice.
Easy to confuse
Availability zones versus multi-region for resilience. Availability zones spread resources across physically separate zones in one region to survive a zone failure with synchronous replication; multi-region spreads across regions to survive a whole-region outage, typically with asynchronous replication at higher cost and latency. Match the design to whether the objective is surviving a zone failure or a regional one.
Microsoft-managed versus customer-managed ASR recovery-point cadence. Azure Site Recovery crash-consistent recovery points are fixed at every five minutes and cannot be modified; only the app-consistent snapshot cadence is configurable. A request to tighten crash-consistent RPO below five minutes must be declined and met outside ASR replication-policy settings.
Worked example from the AZ-305 bank
lock_openFree sampleDesign Business Continuity Solutionsmedium
You are designing a backup topology for a customer with 600 application teams who each want their own Recovery Services vault for isolation, with a target RPO of 24 hours and RTO of 8 hours per workload. Which design respects the documented per-subscription limit?
ASpread the vaults across two or more subscriptions because each subscription supports a maximum of 500 Recovery Services vaults.check_circle Correct
BCreate all 600 Recovery Services vaults inside one subscription; the per-subscription cap is documented as 1,000 vaults.
CReplace Recovery Services vaults with Backup vaults to bypass the 500-vault cap, then attach VM and MARS workloads to the Backup vaults.
DCreate 100 shared vaults in one subscription so each vault protects multiple teams, even though isolation will be lost.
Recovery Services vaults are capped at 500 per subscription; large-isolation designs span multiple subscriptions. Azure Backup documentation states that each Azure subscription supports up to 500 Recovery Services vaults. A 600-vault isolation requirement therefore must be split across two or more subscriptions to comply with the platform limit while keeping the workload-vault binding intact.
Why A is correct: Correct. Azure Backup documentation states that each Azure subscription supports up to 500 Recovery Services vaults.
Why B is wrong: The documented limit is 500 vaults per subscription, not 1,000, so 600 cannot fit in a single subscription.
Why C is wrong: MARS-agent and Azure VM extension backups are not supported in Backup vault, so the substitution does not satisfy the workload mix.
Why D is wrong: This sidesteps the customer's stated isolation requirement and is not driven by the documented per-subscription cap.
What you must be able to do. Given compute, application, migration, and networking requirements, choose the compute platform, application pattern, migration approach, and network topology that fit the stated scale, timeout, multi-region, and connectivity constraints at the least operational overhead.
In one sentenceThe heaviest domain: designing compute, application architecture, migration, and networking, and choosing correctly between VMs, containers, and serverless, the right messaging and API pattern, and the right hybrid topology.
Recall check: answer these from memory first
What is the maximum timeout on the legacy Azure Functions Consumption plan, and which plans do you move to for a longer-running job?
Which API Management tier supports active-active multi-region deployment under a single instance, and which newer tier does not?
Which pattern fits a workload that is mostly reads where the read tier must scale independently of the write tier, and why?
Name three signals that route a containerised workload to AKS rather than to Container Apps or ACI.
What it tests. The largest slice of the exam, designing the workload itself. Compute selection across virtual machines, containers (AKS, Container Apps, ACI), and serverless (Azure Functions hosting plans and their timeout limits); application architecture with microservices, messaging, integration patterns such as CQRS and Saga, and API Management tier selection; migration planning for moving workloads from on-premises or other clouds; and network design with hub-and-spoke topologies, hybrid connectivity, and network security.
How to study it. Spend the most time here because it is the biggest domain by weight, and most of it is matching a requirement to a platform, tier, or pattern. For compute, fix the decision tree: route to AKS when the workload needs the Kubernetes API, an existing Helm and operator ecosystem, or the large node-scale envelope, and to Container Apps or ACI for serverless containers without running Kubernetes. Learn the Functions plan timeouts (legacy Consumption tops out at ten minutes, so a longer job needs Flex Consumption, Premium, or Dedicated). For application patterns, pick CQRS when reads and writes must scale independently under a high read-to-write ratio. For API Management, remember multi-region active-active deployment is a Classic Premium exclusive, not Premium v2. For networking, design hub-and-spoke with shared services in the hub and connectivity radiating to spokes. Practise matching each constraint to its tier or pattern.
Easy to confuse
AKS versus Container Apps or ACI. AKS is the choice when the workload needs direct Kubernetes API access, an existing Helm and operator ecosystem, or scale into thousands of nodes; Container Apps and ACI give serverless containers (event-driven scaling, single short-lived groups) without operating Kubernetes day to day. If the scenario names Kubernetes itself or its ecosystem, it is AKS.
API Management Classic Premium versus Premium v2. Active-active multi-region deployment under one API Management instance is supported only on the Classic Premium tier; Premium v2 adds availability zones and higher scale units but does not include multi-region. When the requirement is gateways in several regions under one instance, it is Classic Premium.
A global API platform must run gateways in three Azure regions under a single API Management instance with active-active multi-region routing. Which tier supports this?
AUse the Premium v2 tier and add regional gateways during provisioning.
BUse the Standard v2 tier with outbound VNet integration in three regions.
CUse the Classic Premium tier for the multi-region API Management deployment.check_circle Correct
DUse the Consumption tier and rely on automatic regional scaling.
Multi-region API Management deployment is a Classic Premium exclusive; Premium v2 does not support it. The feature table explicitly lists multi-region deployment as supported only on Classic Premium. Premium v2 adds availability zones and 30 scale units but does not include multi-region; this is one of the exam's key tier differentiators.
Why A is wrong: Premium v2 supports availability zones and 30 scale units but does not offer multi-region deployment; that capability is reserved for Classic Premium.
Why B is wrong: Standard v2 offers outbound VNet integration and workspaces but cannot host a single multi-region API Management service.
Why C is correct: Correct. The feature table explicitly lists multi-region deployment as supported only on Classic Premium.
Why D is wrong: Consumption is a serverless gateway with no multi-region deployment, no static IP, and no built-in cache; it cannot satisfy the requirement.
A study plan that works
Map the blueprint and book a date
Day 1
Read Microsoft's skills-measured outline and the four design areas with their weights. Book a provisional date now: a fixed date turns open-ended study into a plan and is the strongest predictor of actually sitting. Note that Infrastructure and Identity, Governance, and Monitoring are roughly two thirds of the exam between them, so weight your time accordingly.
Build the design-decision maps
Week 1
Before drilling any domain, build the decision trees the whole exam rests on: identity and governance (system versus user-assigned identity, RBAC versus Policy, Log Analytics workspace design) and compute (VMs versus AKS versus Container Apps and ACI versus Functions plans). Use the recall prompts in this guide: cover the answer, choose from the constraint, then reveal. If you cannot pick from the requirement alone, you do not own it yet.
Go deep on Infrastructure (Domain 4)
Weeks 1 to 3
This is the largest domain, so it gets the most time. Drill the compute decision tree, Functions plan timeouts, API Management tier differences, CQRS and other application patterns, and hub-and-spoke networking. Practise on scenario questions and read the worked explanation on every one, including the ones you got right, watching for the named constraint that picks the answer.
Lock Identity, Governance, and Monitoring (Domain 1)
Weeks 3 to 4
These are reliable marks if you separate the layers cleanly: RBAC for who can act, Policy and management groups for what is allowed, diagnostic settings and Log Analytics design for observability. Do the managed-identity and workspace-design calls by hand until the requirement alone decides them, and learn the diagnostic-setting destination limit.
Cover Data Storage and Business Continuity (Domains 2 and 3)
Week 4
Storage rewards a clean selection tree (Managed Instance versus SQL Database, Cosmos DB API and consistency rules) plus a few configuration traps. Continuity ties straight to RPO and RTO: the zone-versus-region split, the synchronous-across-zones and asynchronous-across-regions pattern, and the documented limits like the 500-vault cap and fixed ASR cadence. Both are learnable and dependable.
Drill weak domains, then space the review
Week 5
Use your per-domain accuracy to attack the two domains dragging you down, not to re-read what you already know. Then space it: revisit each domain's recall prompts after a few days and again a week later. Spacing roughly doubles what sticks compared with cramming.
Sit timed mocks and rehearse case studies
Weeks 5 to 6
Take at least one full timed mock under exam conditions to rehearse pacing and the flag-and-return habit, and practise reading a case study once to extract every requirement before answering its question cluster. Treat the score as a per-domain readiness signal, not a single number, and review every missed question, naming the constraint you misread, before you book or sit.
Know when you're ready
Readiness for AZ-305 is a score on scenario and case-study questions you have not seen before, not a feeling that the services are familiar. Those are different things, and the gap between them is where people fail. Re-reading the documentation builds fluency, and fluency feels like knowledge, so confidence rises while real recall does not. The fix is to test yourself: if you can read a fresh scenario, extract every constraint, and pick the right design while explaining why each other option is wrong, you know it; if you can only nod along to an explanation, you do not yet.
Be especially wary of early confidence on the service map. Knowing what AKS, Cosmos DB, Azure Site Recovery, and Azure Policy each do is the easy half; choosing the right one, the right tier, or the right setting under stacked identity, recovery, and cost constraints, when two would plausibly work, is the half the exam actually tests. Trust your measured per-domain accuracy over your gut, and set the bar at clearing every domain comfortably on unseen questions across more than one session, including the multi-question case studies, not scraping a single pass.
This guide gives you the map. The practice bank is where you find out whether you can navigate it, with a worked explanation and a reason every distractor is wrong on every question. Readiness scoring tells you when you are there. Not before.
Ready to put this into practice?
Free AZ-305 questions with worked explanations. No sign-up.
Extract every constraint before judging the options. Case studies and scenarios stack identity, governance, recovery, cost, and operational limits; the answer is the design that satisfies all of them, not just the most obvious one.
When two designs both work, default to the managed, documented pattern at the least overhead. Microsoft writes the exam around its well-architected guidance, so reach for the heavier or less obvious option only when the scenario names a reason.
Match the tier to the feature. Many traps hinge on a capability being tier-exclusive: multi-region API Management is Classic Premium only, Hyperscale is Azure SQL Database only, so check the tier supports the requirement before choosing it.
Respect the documented platform limit. The exam loves hard numbers: 500 Recovery Services vaults per subscription, ASR crash-consistent points fixed at five minutes, one of each destination type per diagnostic setting. If an option ignores a stated limit, it is wrong.
Map recovery objectives straight to the design. An RPO or RTO target picks the zone-versus-region choice and the replication mode: synchronous across zones for high-priority data, asynchronous across regions for the rest, customer-managed failover when humans must control timing.
Read the case study once, fully, before its questions. Extract the requirements into a mental list, then answer the cluster against that list so you do not re-read screens of context per item.
Flag and move on. Cover every question once before you spend time on a hard one; collecting the clear marks first protects the ones you actually know across a tight clock.
Frequently asked questions
Is AZ-305 hard?
It is an expert-level architecture exam, and the difficulty is judgement rather than recall. Most questions are scenarios, and the case studies stack several design decisions on one set of requirements, where several Azure services or tiers could work and only one fits every stated constraint. Scenario practice with worked explanations matters far more than memorising what each service does.
What is the difference between AZ-305 and AZ-104?
AZ-104 (Azure Administrator) is about configuring and operating resources; AZ-305 sits one level above and is about designing and justifying the architecture. AZ-305 assumes the AZ-104 skill set as background, then tests whether you can turn requirements into the right identity, governance, storage, continuity, and infrastructure design.
Do I need AZ-104 before taking AZ-305?
It is not a formal prerequisite, but the administrator-level knowledge it covers is assumed throughout. If you cannot already configure RBAC, networking, storage, and monitoring, the design-level case studies will be very hard. Most candidates take AZ-305 after building real administration experience.
How long should I study for AZ-305?
Most candidates with real Azure architecture experience are ready in five to seven weeks of steady study. Less hands-on exposure means more time on the two heavy areas, Infrastructure and Identity, Governance, and Monitoring, and on the design decisions the whole exam rests on.
How are the case studies different from standalone questions?
A case study gives you several screens of business and technical requirements, then a cluster of questions that all draw on them. Read the whole scenario once and extract every constraint before answering, because each question is testing whether your design choice satisfies the requirements you were given, not a generic best practice.
Which domains should I focus on?
Infrastructure is the largest area and Identity, Governance, and Monitoring is the next largest, so together they deserve the most time. Data Storage and Business Continuity are smaller but rewarding, because they reduce to clean decision trees: storage selection and consistency rules for one, RPO and RTO mapped to replication and availability design for the other.
How many practice questions should I do before booking?
Enough that every domain clears comfortably on questions you have not seen, and a full timed mock including a case study feels comfortable on pacing. Quality of review beats raw volume: on every question, read the explanation and name the constraint that picked the answer, including on the ones you got right.
Is AZ-305 worth it?
It suits practising Azure architects and senior engineers who design identity, governance, storage, continuity, and infrastructure at an organisational level and want to demonstrate that capability formally. Combined with AZ-104, it completes the Administrator plus Solutions Architect pairing that employers commonly expect of senior cloud hires.
Examworthy is not affiliated with or endorsed by Microsoft. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. AZ-305 and related marks belong to their respective owners.
