Crack the AZ-305: Designing Microsoft Azure Infrastructure Solutions

The Microsoft AZ-305 exam asks an architect to recommend Azure infrastructure solutions rather than merely demonstrate that a service can be deployed. The April 17, 2026 Microsoft blueprint groups the work into identity, governance and monitoring; data storage; business continuity; and infrastructure design. These disciplines converge when a business requirement forces several technically valid services to compete. An architect must choose, document the compromise and describe how the design will be operated.

Consider a regional order-processing application used by staff and customers. It has a web front end, an API, relational records, documents uploaded by customers, and a background process that sends confirmations. The organization has an existing private billing system, a small operations team, sensitive customer data, a constrained budget and a requirement to restore service after a failure. Nothing in that brief yet justifies a particular Azure product. The first task is to discover what would make one design acceptable and another unsafe or unaffordable.

Turn business statements into design constraints

Ask the business to define who uses the application, how many concurrent sessions matter, which requests cannot be lost, which systems require private connectivity and who may access each data class. Turn “highly available” into a measurable service objective and “recover quickly” into a recovery time objective (RTO). Define a recovery point objective (RPO) for records that must survive a disaster. These numbers are requirements to validate, not properties that follow automatically from choosing an Azure service.

Suppose the organization wants an RTO of two hours and an RPO of fifteen minutes for confirmed orders. Those are illustrative targets, not Microsoft product guarantees. An architect now needs evidence about the database recovery model, backup frequency, replication behavior, restore procedures and staff availability. A solution might pass an uptime demonstration yet fail the RPO when a region is unavailable. Record that failure explicitly rather than hiding it under an availability percentage.

Also separate functional constraints from preferences. The billing system may need a fixed route to on-premises resources; the support team may prefer familiar tooling; compliance may require restricted data handling; the budget may make full active-active replication unreasonable. A good architecture decision record names the requirement, two plausible options, the condition that would disqualify each, and the evidence needed before implementation.

Choose network boundaries that match actual flows

Draw the client-to-front-end path, the application-to-data path, and the route to the private billing system separately. A public front end does not require a public database. Likewise, placing a service behind a private endpoint does not prove every client can resolve or reach it. Private connectivity requires correct routes, permitted traffic and name resolution from each relevant network, including on-premises resolvers when the system crosses that boundary.

An architecture proposal might use a hub-and-spoke topology to centralize selected connectivity and shared inspection. That is a design choice, not a mandatory Azure default. A small application may be better served by fewer networks; a regulated, multi-workload environment may need distinct trust zones. Include an explicit failure exercise: a user can reach the API but the API cannot reach storage. Test DNS, effective routes, private-endpoint configuration and network security group rules in a defined order. Relaxing every firewall rule is not an acceptable diagnostic shortcut.

For the billing connection, compare a site-to-site VPN with a dedicated connectivity approach only after collecting throughput, latency, failover and operational requirements. The architect should identify who runs the on-premises router, where redundancy is required, what DNS namespaces must resolve and how access is monitored. A diagram without ownership information will not survive the first real incident.

Design identity, secrets and governance together

Give human administrators and applications separate identities. Human access should use appropriate Microsoft Entra authentication and just-in-time or least-privileged administrative roles where applicable. Workload identities should authenticate to supported services without embedding long-lived secrets in code. A managed identity still needs an appropriate data-plane role; the fact that an operator can deploy a storage account does not automatically grant an application permission to read blobs.

Define who controls subscriptions, resource groups, role assignments, configuration and data. Azure RBAC, Azure Policy, resource locks and application authorization answer different questions. RBAC constrains actions by identity and scope. Policy evaluates or enforces resource configurations. Locks can prevent selected control-plane operations but do not protect every possible data deletion or service action. Application authorization remains responsible for deciding whether one customer may view another customer’s order.

A governance blueprint should also name an owner for security exceptions, define tagging conventions for costs and operational responsibility, and require a documented route to audit evidence. Avoid treating a deployment success as a security review. Provisioning a compliant resource does not prove that credentials, data access or downstream integrations remain controlled after release.

Select compute for workload behavior and operating capacity

For a conventional web application with predictable HTTP traffic and a small team, Azure App Service can reduce guest-operating-system work. It still leaves application code, secrets, identity, network exposure, scaling settings and deployment safety with the owner. Virtual machines remain appropriate when an application genuinely needs guest-level control or runs software that cannot fit a managed platform. That flexibility carries patching, image management, disk, backup and capacity responsibilities.

Container platforms require a more nuanced choice. A packaged workload might fit a managed container service, while Azure Kubernetes Service becomes more compelling when the organization needs the orchestration model and can operate its networking, cluster upgrades, observability and security boundaries. Do not recommend Kubernetes merely because the word “microservices” appears in a requirements document. For this order-processing application, additional cluster operations could be more burden than benefit.

The confirmation worker is a different problem from the web front end. The job may run after a document arrives or an order completes. Compare a queue-triggered worker, a managed workflow and a continuously running process by latency, retry behavior, ownership and cost. Azure Functions, Logic Apps and Event Grid have different responsibilities; an event notification is not itself a durable work queue. Design idempotency so that retrying a message cannot charge a customer or issue a confirmation twice.

Make the data design survive failure and misuse

The relational order records, uploaded documents and analytical reporting should not be forced into one storage model. Choose a managed relational service when transactions and relational constraints matter; evaluate service tier, availability options, scaling, backup and access. Blob Storage may fit documents, with tiering and lifecycle policies only after recovery and retention obligations are defined. An analytics destination may require a separate ingestion and permission boundary rather than production-database access from every reporting job.

For each store, list the allowed writers and readers, encryption and key-management requirements, network restrictions, data retention rules, replication choices and deletion recovery. A private endpoint reduces exposure but does not replace identity or application checks. A role assignment can be correctly scoped yet an overly broad shared-access signature still create unwanted access. Test an authorized upload, a forbidden cross-customer read and recovery from an accidental delete.

Data integration is an architectural decision as well. If the billing system is briefly offline, should the API block checkout, return a pending state, or queue the work? The answer depends on business tolerance for duplicate processing and delayed confirmation. A queue or asynchronous workflow reduces direct coupling but introduces ordering, poison-message handling and observability responsibilities. Design those before estimating a throughput number.

Separate availability, recovery and backup

An availability zone can help a supported deployment tolerate some zone failures within a region. It is not the same as a second-region disaster-recovery plan. Region resilience may require replicated data, appropriate routing, configuration consistency and an exercised failover procedure. Backup protects a recoverable state, but backup retention does not itself establish a recovery-time guarantee. Model a zone failure, a regional failure and a mistaken data deletion as three different incidents.

For the illustrative two-hour RTO and fifteen-minute RPO, write a test plan: stop the primary service in a permitted environment, measure the time to restore request handling, and compare recovered orders against the last known confirmed transaction. Record dependency ordering: DNS changes, secrets access, application release, database failover and on-call approval. A design that promises recovery but has never been exercised is an unverified proposal, not an accepted architecture.

Higher resilience is not free. Extra replicas, cross-region traffic, monitoring and deployment coordination increase spend and security surface area. An architect should show what risk each extra component addresses and why that risk merits the cost and operational complexity. A simpler design may be more reliable when the team lacks the ability to maintain a sophisticated failover arrangement.

Treat observability and cost as acceptance criteria

A monitoring design should start with questions that operators must answer: are orders succeeding, is confirmation delayed, can the worker reach the database, and has recovery actually completed? Capture request failures, latency, queue depth, dependency health and relevant security logs. Assign each alert an owner and a response. An alert without an actionable owner is a notification burden. Avoid sending customer payloads or secrets to logs merely to simplify troubleshooting.

Budgets and cost analysis should be considered before deployment, but a budget alert is not an automatic stop to resource consumption. Compare expected steady-state cost, peak scaling, storage growth, network egress, log ingestion, backup retention and disaster-recovery resources. Price several configurations with explicit assumptions. A low-cost compute estimate can be misleading if the preferred architecture requires expensive data replication or a complex on-call model.

Use the Azure Well-Architected pillars as lenses rather than a scoring contest. Security, reliability, performance, cost optimization and operational excellence can pull in different directions. The architect’s job is to make those tensions visible and justify the compromise that fits the business. If a proposal cannot be implemented, monitored and recovered by the actual team, the architecture is not complete.

Prepare for AZ-305 by defending one decision record

Build a small architecture packet instead of memorizing long product comparison lists. Include the business brief, data-flow and trust-boundary diagram, service selection table, two explicit rejected alternatives, capacity estimate, cost assumptions, recovery requirements, monitoring signals and test results. Have a reviewer change one condition—data residency, peak load, private connectivity or staffing—and require yourself to revise the design without starting from a product catalog.

Microsoft’s April 2026 AZ-305 blueprint weights identity/governance/monitoring at 25–30%, data storage at 20–25%, business continuity at 15–20% and infrastructure at 30–35%. Those are proportions of assessed design responsibilities, not quotas for separate disconnected study chapters. A single order-processing decision can legitimately cross all four domains. Check the current Microsoft study guide before scheduling because those objectives may change.

Finally, distinguish the exam from the credential. Passing AZ-305 is one requirement for Microsoft Certified: Azure Solutions Architect Expert; Microsoft also requires the Azure Administrator Associate certification. That prerequisite is an active credential requirement, not a claim that the AZ-104 exam must be sat on the same day or in a fixed order. Good preparation for AZ-305 produces explainable design judgments, realistic tradeoffs and testable acceptance evidence—not merely a list of Azure services.

• Category: All Certifications Microsoft
• Tags: AZ-305, azure, Infrastructure, microsoft, solutions