I sat AZ-305 about six weeks after passing AZ-104, and I walked out with a very different feeling than I did after the 104. With AZ-104 you either know how to create a VNet peering or you don't. AZ-305 doesn't care whether you can click the right blade. It cares whether you can look at a customer's mess and say "here's why you'd pick Cosmos DB over Azure SQL here, and here's the one requirement that kills that choice."
The published skills outline is fine as a checklist, but it flattens everything. It makes "design data storage solutions" sound equal in weight to "design identity solutions." In the actual exam they are not equal, and the way each domain is tested is different from how the outline reads. So here's my domain-by-domain take on what AZ-305 really asks of you. If you want a sense of the question style before you commit, the AZ-305 exam guide on ExamCert lines up well with what I saw, and it's where I did most of my last-week drilling.
One thing up front: do AZ-104 first, or at least have real hands-on Azure. Microsoft "recommends" it. I'd say it's borderline mandatory. AZ-305 assumes you already know what a NSG, a managed identity, and a storage account tier are. It won't teach you. It'll hand you five services that all technically work and ask which one an architect would actually sign off on.
Design identity, governance, and monitoring solutions
This is the domain people underestimate, and it's the one that quietly sinks scores. The outline makes it sound like Entra ID trivia. It isn't. It's mostly about boundaries and blast radius.
Expect a lot of:
- Management groups vs subscriptions vs resource groups as governance boundaries. When do you split a subscription? (Answer usually revolves around policy scope, billing separation, or a hard quota — not "because it feels tidy.")
- Azure Policy vs RBAC vs Azure Blueprints. The trap is that two of them "would work" and you have to pick the one that enforces at the right layer. Policy governs what resources can exist and how they're configured; RBAC governs who can do things. If the requirement says "prevent anyone from deploying outside West Europe," that's Policy, not RBAC, even though an over-privileged RBAC answer is sitting right there.
- Managed identities, and specifically system-assigned vs user-assigned. If the scenario says "multiple resources need the same identity and it must survive the resource being deleted," that's user-assigned. They test that exact distinction constantly.
- Monitoring design: Log Analytics workspace topology, when to centralize vs federate, and Azure Monitor vs Application Insights scope.
Governance questions reward the boring, correct answer. Resist the clever one.
Design data storage solutions
This was the largest chunk for me, and it's where the "trade-off" nature of the exam is most obvious. You're rarely asked "what is Cosmos DB." You're asked to match a workload profile to a store.
The mental grid I built and kept in my head:
Relational + transactional + existing SQL skills -> Azure SQL Database
Global, low-latency, multi-region writes, flexible -> Cosmos DB (watch the consistency level!)
Big analytical / warehouse -> Synapse / dedicated SQL pool
Unstructured blobs, tiers, lifecycle -> Blob Storage (Hot/Cool/Archive)
Lift-and-shift file shares (SMB) -> Azure Files
The consistency-level questions on Cosmos deserve their own warning. Strong, bounded staleness, session, consistent prefix, eventual — you need to know the ordering and what each one costs you in latency and availability. A scenario will say "users must never read their own stale writes but we want the cheapest option that satisfies that" and the answer is session consistency, not strong. If you memorize the five levels as a list without understanding the trade, you'll get these wrong.
Also budget time for Storage account redundancy (LRS / ZRS / GRS / GZRS) framed as a durability requirement. "Must survive a full region loss" = geo-redundant. "Must survive a datacenter/AZ failure but data can't leave the region for compliance" = ZRS. The compliance clause is the tell.
Design business continuity solutions
Backup and disaster recovery, and this domain is more mechanical than the others — which is good news, because you can just learn the numbers.
Know cold:
- RPO vs RTO. RPO = how much data you can lose (drives backup frequency / replication). RTO = how long you can be down (drives failover strategy). Half the questions here are just testing whether you can map a sentence to the right acronym.
- Azure Site Recovery for VM-level DR and region failover, vs Azure Backup for point-in-time restore.
- Availability Zones vs Availability Sets vs region pairs, and the SLA implications. A single VM with premium SSD hits one SLA; spread across zones hits a higher one. They'll ask you to pick the minimum design that meets a stated SLA — over-engineering is a wrong answer here even though it "works."
If you're short on study time, this is the highest points-per-hour domain. The concepts are finite.
Design infrastructure solutions
The biggest and broadest: compute, networking, application architecture, and migrations. It sprawls, but the questions cluster.
Compute is a decision tree you should be able to run in your sleep: full control / legacy / lift-and-shift → VMs; containers with orchestration → AKS; simple containers without managing a cluster → Container Apps or ACI; event-driven glue → Functions; standard web app → App Service. The exam loves handing you a workload and making you eliminate three of these on a single constraint (stateful? needs the OS? has spiky traffic? cost-sensitive at idle?).
Networking design leans on hub-and-spoke topology, when you need a firewall vs an NSG vs Application Gateway (WAF), and private endpoints vs service endpoints. The private-vs-service-endpoint distinction is a repeat offender — private endpoint gives a resource a private IP in your VNet; service endpoint just extends your VNet identity to the service over the backbone. Compliance scenarios that say "traffic must never traverse the public internet and the resource needs a private IP" want private endpoints.
Migrations mostly means knowing the Azure Migrate tooling and the 5 Rs framing (rehost, refactor, rearchitect, rebuild, replace) well enough to match a scenario to one.
How I'd actually prep
Case studies are the real exam within the exam. You get a wall of text — company background, technical requirements, constraints buried mid-paragraph — and several questions hanging off it. Read the requirements and constraints first, then the narrative. The constraint that eliminates the obvious answer is almost always tucked somewhere unglamorous like "the finance team's tooling only supports SQL."
Practice under that pressure. I ran through the free AZ-305 practice test enough times that the trade-off pattern became reflexive — not the specific answers, but the instinct to hunt for the disqualifying constraint before committing. That instinct is basically the whole exam.
If AZ-104 felt like "can you operate Azure," AZ-305 is "can you be trusted to design it and defend the design." Study the trade-offs, not the feature list, and you'll be fine.
Top comments (0)