AZ-305 covers such a wide architecture surface that studying services alphabetically is inefficient. A better sequence follows dependency: learn Azure governance and identity first, then monitoring, storage and data, business continuity, compute, application architecture, networking, migration, and finally mixed design scenarios. Each phase should reuse a small reference architecture so later decisions connect to earlier constraints.<\/p>\n
Keep the current AZ-305<\/a> guide as the checklist. The April 17, 2026 blueprint is current, and Microsoft recommends hands-on experience. The order below is designed to build architectural reasoning rather than a list of service facts.<\/p>\n Start with management groups, subscriptions, resource groups, tags, governance, compliance, Microsoft Entra, role-based access, workload identities, secrets, certificates, keys, and hybrid authorization. Create a small hierarchy and state which policies and roles belong at each level.<\/p>\n A Key Vault<\/a> exercise can connect identity with secret and certificate management. The important question is always which principal needs which permission at which scope.<\/p>\n Study logging, log routing, monitoring, metrics, alerts, diagnostics, and operational ownership. Decide which events belong in centralized workspaces and which service-level indicators represent user impact.<\/p>\n Use Azure Monitor<\/a> as a foundation, then attach observability to every later lab. Monitoring is more useful when designed before incidents than when added after a failure.<\/p>\n Compare relational, semi-structured, and unstructured data according to transaction behavior, schema, consistency, query pattern, scale, latency, compatibility, durability, and cost. Then study database tiers, compute tiers, scalability, data protection, integration, and analysis.<\/p>\n Use Cosmos DB<\/a> as one contrast with relational services. The goal is not to prefer one service; it is to recognize which workload characteristics make each model appropriate.<\/p>\n Define RTO and RPO for each critical component. Then compare high availability, backup, replication, failover, and disaster recovery for compute, databases, and unstructured data.<\/p>\n A review of Azure Backup<\/a> should be connected to restore testing. A backup policy is not proven until the architecture can restore data inside the business requirement.<\/p>\n Move into virtual machines, containers, serverless services, and batch. For each, list control, scaling, deployment, networking, state, startup, limits, and operational ownership.<\/p>\n The Azure compute<\/a> overview should become a decision table driven by workload requirements. Avoid memorizing that one service is \u201cbest\u201d for all modern applications.<\/p>\n Add messaging, events, API integration, caching, configuration management, and automated deployment. Practice deciding when asynchronous communication reduces coupling and when an API or direct call remains simpler.<\/p>\n Use Service Bus<\/a>, API Management<\/a>, and Azure Cache for Redis<\/a> as examples of different responsibilities. Each supporting service should have a clear reason to exist.<\/p>\n Study virtual networks, subnets, private endpoints, internet access, hybrid connectivity, VPN, ExpressRoute, routing, load balancing, network performance, and network security. Draw the user, administration, application, and data paths separately.<\/p>\n A virtual network<\/a> review and Azure Load Balancer<\/a> context help only when the architecture makes traffic requirements explicit. Networking is easier to remember when every route has a business purpose.<\/p>\n Use the Cloud Adoption Framework to assess on-premises servers, applications, data, databases, and unstructured storage. Compare IaaS migration, PaaS modernization, replatforming, and replacement according to compatibility, timeline, cost, and operations.<\/p>\n Create a dependency map before selecting tools. A migration fails when an unseen identity, network, data, or application dependency is cut too early.<\/p>\n For each reference architecture, review reliability, security, cost optimization, operational excellence, and performance. One design choice often improves one pillar while increasing cost or complexity somewhere else.<\/p>\n The architect should be able to explain why the chosen trade-off is appropriate for the stated business requirement rather than claiming the design is universally optimal.<\/p>\n Use final practice sessions to solve cases that combine identity, storage, continuity, application, migration, and network requirements. State the non-negotiable constraints first, then choose services.<\/p>\n Keep one architecture decision record throughout the plan. For each major choice, write context, decision, alternatives, consequences, and verification. This turns study into a sequence of defensible recommendations and provides a compact final-review artifact that is much more useful than hundreds of disconnected service notes.<\/p>\n During governance study, practice inheritance and scope. Apply a hypothetical policy or role at management-group, subscription, resource-group, and resource level and explain the blast radius. This helps candidates see why an otherwise correct control can become dangerous when assigned too broadly.<\/p>\n During monitoring study, separate collection from response. Logs and metrics should flow somewhere useful, but alerts also need thresholds, owners, escalation, and runbooks. A monitoring design that creates data but no operational action is incomplete.<\/p>\n During data study, use one workload that evolves. Start with a relational design, then introduce global distribution, semi-structured payloads, analytical reporting, and archival data. Re-evaluate the service mix each time. This teaches that storage architecture changes as access patterns and business requirements change.<\/p>\n During continuity study, test recovery assumptions. Define RTO and RPO, choose backup or replication, then walk through the actual sequence needed to restore the application. Include DNS, identity, secrets, network, and application configuration. Recovery time is end-to-end, not simply the restore time of one service.<\/p>\n During compute study, compare lifecycle responsibilities. Who patches the operating system? Who manages runtime upgrades? How are deployments rolled back? How is scale configured? What evidence shows health? Those questions often differentiate VM, container, and serverless designs more clearly than feature tables.<\/p>\n During distributed-application study, practice failure modes. Stop a consumer, throttle an API, expire a cache entry, or change configuration. Then predict whether the user request should fail, retry, queue, or degrade gracefully. Architecture decisions become memorable when their failure behavior is explicit.<\/p>\n During networking study, draw traffic instead of memorizing service diagrams. Trace internet ingress, private east-west traffic, Azure service access, hybrid traffic, and administrative access. Add the load-balancing or routing service only after the path and protocol are known.<\/p>\n During migration study, create a decision table for rehost, replatform, refactor, replace, and retire. Include schedule, compatibility, cost, operational burden, and business value. This prevents migration from becoming a default \u201clift and shift\u201d exercise when PaaS or retirement would be stronger.<\/p>\n In the final week, use only mixed scenarios and require yourself to explain rejected options. If you recommend Service Bus, state why direct synchronous communication is weaker. If you choose Cosmos DB, state why relational storage is less suitable. Contrast builds architecture judgment faster than rereading definitions.<\/p>\n Add one weekly architecture-review session where you identify unnecessary complexity. Look for custom virtual machines that could become managed services, repeated synchronous calls that could be decoupled, duplicated secrets that could move to Key Vault, or public paths that could become private. Simplification is useful only when the managed alternative still satisfies compatibility and control requirements.<\/p>\n Add a cost and quota checkpoint after each major phase. Record the likely cost driver, scaling limit, and operational dependency for the services you chose. This helps prevent designs that are theoretically elastic but constrained by throughput, connection, regional, or service limits that were never considered.<\/p>\n Use one scenario per week that forces a deliberate compromise. For example, require low latency and low cost but only moderate availability, or require maximum continuity but accept greater operational complexity. Explaining why you are not maximizing every design property is central to architecture thinking.<\/p>\n Practice explaining designs to two audiences. Give one version to an engineer with technical detail and another to a business stakeholder focused on risk, cost, recovery, and outcome. AZ-305’s audience profile explicitly includes advising stakeholders, so communication is part of the role even when the exam question is technical.<\/p>\n Before exam day, perform a closed-book review of the four domains. For each domain, state its major decision areas, one common trade-off, one failure mode, and one evidence source. If you can move between domains without relying on service lists, your study sequence has produced the intended architecture mindset.<\/p>\n Add one scenario every week that includes an on-premises dependency. This forces you to practice hybrid identity, VPN or ExpressRoute, DNS, migration sequencing, data movement, and recovery. Azure architecture is often hybrid even when the target state is increasingly cloud-native.<\/p>\n Add one scenario every week that includes a regulatory or governance constraint. Require data to stay in a region, restrict public access, separate production from development, or centralize logging. These constraints help you practice the management hierarchy and policy decisions that candidates often under-study compared with compute.<\/p>\n Build one \u201cservice confusion\u201d list for final review: load balancer versus application gateway; queue versus event grid; Service Bus versus direct API; relational versus Cosmos DB; VM versus container versus serverless; backup versus replication; high availability versus disaster recovery. Contrast makes architecture decisions easier under time pressure.<\/p>\n Practice translating the same workload into two designs: one optimized for control and one optimized for low operational burden. Then decide which business context justifies each. This exercise is especially useful for VM-versus-PaaS and self-managed-versus-managed data scenarios.<\/p>\n Reserve the final two days for architecture summaries, not new services. Review the four domain weights, current April 2026 objectives, decision records, and failure scenarios. A stable mental model is more valuable than last-minute breadth that you cannot apply.<\/p>\nPhase one: build the management and identity foundation<\/h3>\n
Phase two: design monitoring before adding workload complexity<\/h3>\n
Phase three: learn data storage by access pattern<\/h3>\n
Phase four: add high availability, backup, and disaster recovery<\/h3>\n
Phase five: compare compute operating models<\/h3>\n
Phase six: study distributed application patterns<\/h3>\n
Phase seven: build network architecture from traffic paths<\/h3>\n
Phase eight: learn migration as a transition architecture<\/h3>\n
Phase nine: practice trade-offs across the Well-Architected Framework<\/h3>\n
Finish with mixed scenario drills<\/h3>\n