Infrastructure design for Microsoft AZ-305 Azure Solutions Architect: Concepts, Scenarios, and Study Priorities

 

Infrastructure design is the largest AZ-305 domain because it connects compute, application architecture, networking, migration, integration, scaling, governance, and operations. Strong preparation focuses on requirement-to-design mapping and on the trade-offs between managed services and direct control.

For related ExamSnap context, use AZ-305 resources for the exam-level reference, container design practice when you want a nearby applied exercise, and Azure architect path when the credential or vendor path helps place the topic in context.

Choose compute from workload requirements

In this infrastructure review, the fastest way to expose a weak mental model is to ask what would happen if one variable changed. Virtual machines, containers, managed application platforms, serverless services, and batch-oriented compute offer different control, scaling, isolation, deployment, and operations models.

This is where practical rehearsal pays off, because verification exposes weak assumptions quickly. A legacy application requires OS-level agents while a bursty API has unpredictable demand. Explain why a single compute pattern is unlikely to be optimal for both.

Make Choose compute from workload requirements concrete by writing the requirement first and mapping the dependencies underneath it. Keep workload requirements, managed responsibility, scaling, deployment, networking, identity, private access, integration, migration constraints, observability, and cost visible while you reason. The core idea here—virtual machines, containers, managed application platforms, serverless services, and batch-oriented compute offer different control, scaling, isolation, deployment, and operations models.—should let you predict what changes when one condition moves. For the Azure infrastructure decision, state one prerequisite and one boundary where the mechanism would no longer be the right fit.

Use the Choose compute from workload requirements scenario as a controlled experiment: A legacy application requires OS-level agents while a bursty API has unpredictable demand. When tracing the workload path, explain why a single compute pattern is unlikely to be optimal for both. Once the baseline is clear, add private-access requirements, reduce operations capacity, introduce a second region, change scaling patterns, or impose a phased migration constraint and predict the new result before checking it. Write the expected evidence first; useful signals include request-path behavior, scaling state, route and DNS results, deployment health, integration traces, platform metrics, migration validation, and operational burden. From an operability perspective, if observation and prediction differ, isolate the earliest uncertain assumption and test that before changing several things at once.

When two choices look valid in Choose compute from workload requirements, compare scope, sequence, side effects, and operating responsibility rather than matching the first familiar term.

For Choose compute from workload requirements, write an architecture decision record with requirement, options, decision, consequences, and a condition that would trigger reconsideration. Keep it short enough that the trade-off remains visible.

For Choose compute from workload requirements, write the acceptance evidence before finalizing the design. In the migration and network scenario, that might be measured latency, recovery timing, effective access, a failover result, an architecture review criterion, or a cost and operations estimate tied to the requirement.

Design application integration and messaging

In this infrastructure review, good preparation here is less about recall speed and more about explaining why the behavior follows from the design. Messaging, events, APIs, caching, configuration, and deployment patterns determine how application components communicate and fail independently.

For the Azure infrastructure decision, a small diagram or decision table usually reveals more than another paragraph of notes because it makes the dependencies visible. An order workflow must absorb spikes, avoid losing work, and notify downstream systems without making the customer request wait for every dependency.

Make Design application integration and messaging concrete by writing the requirement first and mapping the dependencies underneath it. When tracing the workload path, keep workload requirements, managed responsibility, scaling, deployment, networking, identity, private access, integration, migration constraints, observability, and cost visible while you reason. The core idea here—messaging, events, APIs, caching, configuration, and deployment patterns determine how application components communicate and fail independently.—should let you predict what changes when one condition moves. From an operability perspective, state one prerequisite and one boundary where the mechanism would no longer be the right fit.

Turn the section into a test case: An order workflow must absorb spikes, avoid losing work, and notify downstream systems without making the customer request wait for every dependency. Then change one condition: add private-access requirements, reduce operations capacity, introduce a second region, change scaling patterns, or impose a phased migration constraint. In the migration and network scenario, write the expected evidence first; useful signals include request-path behavior, scaling state, route and DNS results, deployment health, integration traces, platform metrics, migration validation, and operational burden. In this infrastructure review, a mismatch is useful data: record which assumption failed, make the smallest correction, and verify again.

Write one near-miss for Design application integration and messaging—a case where the same mechanism is available but fails a decisive requirement. That boundary is often what the exam is actually testing.

Build a requirement matrix for Design application integration and messaging: availability, security, performance, cost, operations, data, and governance. For the Azure infrastructure decision, compare two plausible Azure designs and record why one wins for this particular case.

For Design application integration and messaging, write the acceptance evidence before finalizing the design. When tracing the workload path, that might be measured latency, recovery timing, effective access, a failover result, an architecture review criterion, or a cost and operations estimate tied to the requirement.

For infrastructure design, use an adjacent AZ-305 article only to close a named gap such as migration sequencing, network boundaries, or recovery coupling.

Design network connectivity and private access

From an operability perspective, start from the traffic, data, identity, or service requirement and work outward; the terminology will fit more naturally after that. Architecture must consider address space, DNS, internet ingress and egress, hybrid connectivity, private endpoints, routing, segmentation, performance, and operational visibility.

In the migration and network scenario, a small diagram or decision table usually reveals more than another paragraph of notes because it makes the dependencies visible. A regulated workload needs private access from on-premises networks to Azure PaaS services and cannot rely on public endpoints. Map the traffic and name the DNS dependencies.

Treat Design network connectivity and private access as an applied systems problem: identify the requirement, the decision point, the resulting state, and the proof. In this infrastructure review, keep workload requirements, managed responsibility, scaling, deployment, networking, identity, private access, integration, migration constraints, observability, and cost visible while you reason. The core idea here—architecture must consider address space, DNS, internet ingress and egress, hybrid connectivity, private endpoints, routing, segmentation, performance, and operational visibility.—should let you predict what changes when one condition moves.

Rehearse Design network connectivity and private access with this baseline: A regulated workload needs private access from on-premises networks to Azure PaaS services and cannot rely on public endpoints. Map the traffic and name the DNS dependencies. When tracing the workload path, change one condition: add private-access requirements, reduce operations capacity, introduce a second region, change scaling patterns, or impose a phased migration constraint. From an operability perspective, write the expected evidence first; useful signals include request-path behavior, scaling state, route and DNS results, deployment health, integration traces, platform metrics, migration validation, and operational burden. In the migration and network scenario, a mismatch is useful data: record which assumption failed, make the smallest correction, and verify again.

Keep the boundary of Design network connectivity and private access explicit: identify what the mechanism can change, what it cannot change, and which prerequisite must already be true.

Turn Design network connectivity and private access into a failure exercise. In this infrastructure review, break one dependency or tighten one business requirement, then redraw only the parts of the Azure design that must change.

A good Design network connectivity and private access decision is testable. For the Azure infrastructure decision, state what observation would prove the architecture meets the business constraint and what result would force you back to the design table.

This point also connects naturally with The ultimate guide to passing the az 305 exam and becoming a Microsoft certified; the link is most useful when you can state exactly what additional question you want that page to answer.

Select traffic distribution by layer and scope

When tracing the workload path, think of this area as a chain of decisions: identify the state, choose the mechanism, and prove the outcome. Load-balancing and routing choices vary by global versus regional scope, Layer 4 versus Layer 7 requirements, TLS handling, health checks, web security, and failover behavior.

From an operability perspective, once that relationship is clear, several memorization-heavy details become easier to reconstruct from first principles. A global web application needs path-based routing, web application firewall capability, and regional failover while an internal service needs low-latency TCP distribution inside one region.

Treat Select traffic distribution by layer and scope as an applied systems problem: identify the requirement, the decision point, the resulting state, and the proof. In the migration and network scenario, keep failure scope, availability target, RTO, RPO, replication, backup, failover routing, dependency order, data consistency, testing, and ownership visible while you reason. The core idea here—load-balancing and routing choices vary by global versus regional scope, Layer 4 versus Layer 7 requirements, TLS handling, health checks, web security, and failover behavior.—should let you predict what changes when one condition moves. In this infrastructure review, state one prerequisite and one boundary where the mechanism would no longer be the right fit.

Rehearse Select traffic distribution by layer and scope with this baseline: A global web application needs path-based routing, web application firewall capability, and regional failover while an internal service needs low-latency TCP distribution inside one region. For the Azure infrastructure decision, once the baseline is clear, fail a zone or region, corrupt data, remove one dependency, tighten RTO, reduce RPO, or require a return-to-primary process and predict the new result before checking it. Do not verify blindly. When tracing the workload path, predict what you expect to find in recovery timing, replicated state, restore success, failover health, dependency readiness, traffic behavior, and post-recovery validation and what a contradictory result would mean. From an operability perspective, a mismatch is useful data: record which assumption failed, make the smallest correction, and verify again.

When two choices look valid in Select traffic distribution by layer and scope, compare scope, sequence, side effects, and operating responsibility rather than matching the first familiar term.

Turn Select traffic distribution by layer and scope into a failure exercise. In the migration and network scenario, break one dependency or tighten one business requirement, then redraw only the parts of the Azure design that must change.

For Select traffic distribution by layer and scope, write the acceptance evidence before finalizing the design. In this infrastructure review, that might be measured latency, recovery timing, effective access, a failover result, an architecture review criterion, or a cost and operations estimate tied to the requirement.

If infrastructure design remains a weak point, continue with Microsoft az 305 container compute design practice test and compare its scenarios with the decision rules used here.

Plan migrations as staged architecture decisions

For the Azure infrastructure decision, candidates often know the vocabulary here but still lose points because they cannot apply it under a constraint. Migration design includes assessment, dependency discovery, landing-zone readiness, data movement, cutover, rollback, modernization choices, and validation.

When tracing the workload path, this is where practical rehearsal pays off, because verification exposes weak assumptions quickly. A portfolio contains lift-and-shift candidates, databases that can move to managed services, and one application that should be refactored. Build a phased plan rather than forcing one migration method.

To deepen Plan migrations as staged architecture decisions, describe the state before and after the decision rather than adding another definition to your notes. From an operability perspective, keep data shape, transactional pattern, consistency, latency, throughput, regional distribution, security, analytics needs, backup, recovery, cost, and operational responsibility visible while you reason. The core idea here—migration design includes assessment, dependency discovery, landing-zone readiness, data movement, cutover, rollback, modernization choices, and validation.—should let you predict what changes when one condition moves. In the migration and network scenario, state one prerequisite and one boundary where the mechanism would no longer be the right fit.

Rehearse Plan migrations as staged architecture decisions with this baseline: A portfolio contains lift-and-shift candidates, databases that can move to managed services, and one application that should be refactored. In this infrastructure review, on a second pass, make reads global, tighten consistency, change the data model, add analytics, introduce residency constraints, or reduce the acceptable recovery window. Do not verify blindly. For the Azure infrastructure decision, predict what you expect to find in latency and throughput, replication state, consistency behavior, access path, backup and restore results, capacity, cost, and operational health and what a contradictory result would mean. When tracing the workload path, if observation and prediction differ, isolate the earliest uncertain assumption and test that before changing several things at once.

Write one near-miss for Plan migrations as staged architecture decisions—a case where the same mechanism is available but fails a decisive requirement.

For Plan migrations as staged architecture decisions, write an architecture decision record with requirement, options, decision, consequences, and a condition that would trigger reconsideration. Keep it short enough that the trade-off remains visible.

For Plan migrations as staged architecture decisions, write the acceptance evidence before finalizing the design. From an operability perspective, that might be measured latency, recovery timing, effective access, a failover result, an architecture review criterion, or a cost and operations estimate tied to the requirement.

If the readiness matrix still exposes infrastructure gaps, return to that matrix after you can explain this section without notes.

Design for scale without losing operability

In the migration and network scenario, start from the traffic, data, identity, or service requirement and work outward; the terminology will fit more naturally after that. Autoscaling, deployment automation, health probes, observability, configuration management, and failure isolation should grow together. Scale is not only a capacity question.

In this infrastructure review, the same idea also appears in troubleshooting: a symptom is not the same thing as the root cause. A service handles ten times more traffic after a launch, but incidents take longer to diagnose because logs and dependency traces were not designed for the new architecture.

For Design for scale without losing operability, the useful study move is to turn recognition into a decision you can defend under a changed constraint. Keep requirement extraction, constraint ranking, service fit, elimination logic, architecture trade-offs, uncertainty management, evidence, and final-review discipline visible while you reason. The core idea here—autoscaling, deployment automation, health probes, observability, configuration management, and failure isolation should grow together. Scale is not only a capacity question.—should let you predict what changes when one condition moves.

Turn the section into a test case: A service handles ten times more traffic after a launch, but incidents take longer to diagnose because logs and dependency traces were not designed for the new architecture. Once the baseline is clear, add a hidden constraint, remove a familiar service name, introduce two plausible answers, or force yourself to justify the rejected alternatives and predict the new result before checking it. Write the expected evidence first; useful signals include your written requirement summary, elimination rationale, confidence markers, unresolved assumptions, and consistency with the current AZ-305 objective domain. When tracing the workload path, a mismatch is useful data: record which assumption failed, make the smallest correction, and verify again.

When two choices look valid in Design for scale without losing operability, compare scope, sequence, side effects, and operating responsibility rather than matching the first familiar term.

Turn Design for scale without losing operability into a failure exercise. From an operability perspective, break one dependency or tighten one business requirement, then redraw only the parts of the Azure design that must change.

A good Design for scale without losing operability decision is testable. In the migration and network scenario, state what observation would prove the architecture meets the business constraint and what result would force you back to the design table.

Connect infrastructure to identity and governance

In this infrastructure review, a candidate who can explain the failure mode usually understands the success path as well. Resource design is constrained by subscription boundaries, RBAC, policy, managed identities, secrets, naming, tagging, and the organizational operating model.

That distinction matters because exam scenarios routinely hide the decisive clue inside an operational constraint. A platform team wants standardized network and security controls while application teams need deployment autonomy. Design boundaries that allow both without duplicating every control.

Treat Connect infrastructure to identity and governance as an applied systems problem: identify the requirement, the decision point, the resulting state, and the proof. For the Azure infrastructure decision, keep workload requirements, managed responsibility, scaling, deployment, networking, identity, private access, integration, migration constraints, observability, and cost visible while you reason. The core idea here—resource design is constrained by subscription boundaries, RBAC, policy, managed identities, secrets, naming, tagging, and the organizational operating model.—should let you predict what changes when one condition moves. When tracing the workload path, state one prerequisite and one boundary where the mechanism would no longer be the right fit.

Rehearse Connect infrastructure to identity and governance with this baseline: A platform team wants standardized network and security controls while application teams need deployment autonomy. Design boundaries that allow both without duplicating every control. From an operability perspective, change one condition: add private-access requirements, reduce operations capacity, introduce a second region, change scaling patterns, or impose a phased migration constraint. Choose evidence that tests the decision directly; for this topic that can include request-path behavior, scaling state, route and DNS results, deployment health, integration traces, platform metrics, migration validation, and operational burden.

Separate the desired result in Connect infrastructure to identity and governance from the implementation used to get there. In this infrastructure review, the same outcome may have several technically possible paths with very different consequences.

Turn Connect infrastructure to identity and governance into a failure exercise. For the Azure infrastructure decision, break one dependency or tighten one business requirement, then redraw only the parts of the Azure design that must change.

A good Connect infrastructure to identity and governance decision is testable. When tracing the workload path, state what observation would prove the architecture meets the business constraint and what result would force you back to the design table.

Use the Well-Architected mindset to resolve trade-offs

From an operability perspective, a useful study standard is to be able to predict the result before you configure or select anything. Reliability, security, cost, operational excellence, and performance can conflict. Architects should document why one trade-off is acceptable for a specific business requirement.

Two architectures meet functionality: one costs more but reduces recovery risk; the other is cheaper but increases manual operations. Decide using explicit business priorities rather than preference.

Make Use the Well-Architected mindset to resolve trade-offs concrete by writing the requirement first and mapping the dependencies underneath it. In this infrastructure review, keep failure scope, availability target, RTO, RPO, replication, backup, failover routing, dependency order, data consistency, testing, and ownership visible while you reason. The core idea here—reliability, security, cost, operational excellence, and performance can conflict. Architects should document why one trade-off is acceptable for a specific business requirement.—should let you predict what changes when one condition moves.

Use the Use the Well-Architected mindset to resolve trade-offs scenario as a controlled experiment: Two architectures meet functionality: one costs more but reduces recovery risk; the other is cheaper but increases manual operations. Decide using explicit business priorities rather than preference. Then change one condition: fail a zone or region, corrupt data, remove one dependency, tighten RTO, reduce RPO, or require a return-to-primary process. Do not verify blindly. From an operability perspective, this predict-check-correct cycle produces notes tied to behavior rather than to the wording of one question.

Write one near-miss for Use the Well-Architected mindset to resolve trade-offs—a case where the same mechanism is available but fails a decisive requirement.

Build a requirement matrix for Use the Well-Architected mindset to resolve trade-offs: availability, security, performance, cost, operations, data, and governance. In the migration and network scenario, compare two plausible Azure designs and record why one wins for this particular case.

A good Use the Well-Architected mindset to resolve trade-offs decision is testable. In this infrastructure review, state what observation would prove the architecture meets the business constraint and what result would force you back to the design table.

Convert Azure infrastructure design into architecture decisions

For the Azure infrastructure decision, change one business constraint in each scenario—recovery, security, operations, cost, performance, residency, or scale—and decide whether the architecture should change. You are ready when you can turn a written business requirement into a defensible Azure architecture, identify the dependencies and failure paths, justify the managed-service boundary, and explain how networking, identity, observability, migration, and operations fit the same design.

Rather than rereading this section, test the idea against Microsoft Azure certification roadmap from fundamentals to administrator and see whether you can transfer the reasoning to a new scenario.

Infrastructure lab: trace a workload from entry point to migration and operations

Treat infrastructure design as one connected path from user request to compute, dependency, data, and operations. Consider an enterprise application that has an internet-facing API, asynchronous workers, a relational database, private connectivity to an on-premises system, and a requirement to migrate with minimal interruption. Before selecting Azure services, write the workload characteristics: request pattern, statefulness, scaling trigger, network trust boundary, deployment frequency, recovery target, and operational skill set. That prevents the compute choice from being made independently of networking, integration, and migration constraints.

Compute selection should start with control and execution model. Virtual machines provide broad compatibility and operating-system control but leave more patching, scaling, and resilience responsibility with the customer. Container platforms can standardize packaging and orchestration while introducing cluster, image, networking, and observability considerations. Serverless options can reduce infrastructure management for event-driven or bursty functions, but execution limits, cold behavior, integration patterns, and state design still matter. The exam decision is rarely ‘which service is best’; it is ‘which operating model satisfies the requirement with the least unnecessary responsibility.’

Application architecture becomes more resilient when synchronous dependencies are challenged. If a user request waits on several downstream services, one slow dependency can extend latency or trigger cascading failure. Messaging, queues, pub/sub, events, caching, API management, and retry policies can decouple parts of the path, but every decoupling decision changes ordering, idempotency, consistency, observability, and failure handling. A strong design states which interactions truly need immediate response and which can tolerate asynchronous completion, then explains how duplicates, poison messages, and delayed processing are handled.

Networking decisions should be drawn as packet paths. Show how internet users reach the service, how private workloads reach platform services, how Azure reaches on-premises networks, where name resolution occurs, and where security controls are enforced. Then distinguish global from regional traffic distribution and Layer 4 from Layer 7 requirements. A load-balancing answer that ignores TLS termination, HTTP routing, private addressing, cross-region failover, or source connectivity can be technically possible yet still miss the requirement that decides the scenario.

Migration is an architecture program, not a copy operation. Classify each component by its dependency, change tolerance, data gravity, downtime allowance, target operating model, and rollback path. Rehost may reduce initial application change but preserve operational debt; replatforming can lower management burden while requiring compatibility work; refactoring can unlock cloud-native behavior but expands delivery risk and testing. The right choice can differ by component in the same application. Build sequencing around dependencies and data synchronization so that migration waves can be validated independently instead of relying on one high-risk cutover.

Close the design with operability. Define monitoring signals, deployment and rollback behavior, autoscale thresholds, quota assumptions, health probes, security ownership, cost controls, and failure tests before declaring the architecture complete. Then change one condition—double traffic, remove on-premises connectivity, lose a zone, or require private-only data access—and identify the smallest set of components that must change. That counterfactual exercise is valuable for AZ-305 because it proves whether you understand architectural boundaries rather than merely recognizing a service diagram.

Infrastructure architecture: connect dependencies before products

Infrastructure architecture is a system of dependencies, not a collection of independent Azure products. Trace requests, state, network paths, deployments, migrations, failure behavior, and ownership together. When you can explain how one changed constraint propagates through that system, infrastructure scenarios become decisions you can reason through instead of diagrams you must memorize.