Infrastructure architecture on the Microsoft AZ-305 exam is broader than choosing virtual machines. The current skills outline includes compute, containers, serverless, batch processing, messaging, event-driven architecture, APIs, caching, configuration management, automated deployment, migrations, internet and hybrid connectivity, network performance, network security, load balancing, and routing. The architect must turn workload requirements into a coherent combination of those capabilities.
A strong design starts with qualities rather than products. What must scale? What must remain stateful? What is the latency target? How much operational control is needed? What failure domains matter? Which parts are synchronous? Which can be asynchronous? Those answers determine the infrastructure shape.
Choose the compute model from operational responsibility
Virtual machines provide strong compatibility and operating-system control, but they also carry patching, image, availability, and scaling responsibilities. Containers package applications with their dependencies and can support portable, orchestrated deployment. Serverless services reduce infrastructure management further and can scale with event or request demand.
The decision is not a maturity ladder where serverless is always better than containers and containers are always better than VMs. A legacy application that requires kernel-level control may belong on VMs. A microservice platform may justify Kubernetes. An event-processing function with bursty traffic may suit serverless. Architecture matches the operating model to the application.
Batch workloads have different economics from interactive workloads
Batch processing often tolerates queued execution and can use elastic compute more efficiently than always-on infrastructure. Architects should consider job duration, parallelism, data locality, retry behavior, scheduling, and deadlines. A high-performance batch process may need many cores for a short time rather than a permanently large cluster.
This is a recurring AZ-305 theme: workload behavior should shape the resource model. Optimizing for peak capacity without considering time can lead to expensive idle infrastructure.
Messaging decouples components
Queues and messaging services allow producers and consumers to operate at different rates and can improve resilience when downstream components are temporarily unavailable. Decoupling is especially useful when synchronous dependencies would otherwise create cascading failures.
The architect should decide whether the workload needs ordered delivery, publish-subscribe distribution, competing consumers, transaction semantics, event streaming, or simple buffering. Those requirements help distinguish messaging patterns and services.
Event-driven architecture reacts to change
Events represent facts that something happened. An event-driven design can connect loosely coupled systems and allow multiple consumers to react independently. This differs from a command-oriented queue in which a message asks a specific consumer to perform work.
Good event architecture includes idempotent consumers, retry strategy, poison-message handling, schema management, and observability. Without those operational details, an event-driven system can become difficult to troubleshoot even if the high-level diagram looks elegant.
API integration needs governance as well as connectivity
APIs create explicit contracts between systems. Azure API Management and related services can provide routing, policy, authentication, throttling, transformation, observability, and developer-facing management around those contracts. The architecture should decide where API governance belongs and which callers are trusted.
Exposing an internal service directly to the internet because it already speaks HTTP is usually not an architecture. The design should consider identity, rate control, versioning, abuse protection, private connectivity, and operational ownership.
Caching is a performance tool with consistency consequences
Caching can reduce latency and backend load, but stale data is the price of many cache strategies. Architects need to understand which data can be cached, how long it remains valid, how invalidation works, and what happens when the cache is unavailable.
Use caching when the workload benefits from repeated reads or expensive recomputation and can tolerate the chosen consistency model. Do not add a cache simply because high-performance systems often have one. Every cache adds another stateful component and another failure mode.
Configuration management should separate code from environment
Applications often need different endpoints, feature flags, secrets, or operational settings across environments. Configuration services and secret stores allow those values to be managed without rebuilding application code. The architecture should keep sensitive secrets out of ordinary configuration and use identities to control access.
Central configuration also creates dependency and blast-radius questions. If every application depends on one configuration service, that service becomes critical infrastructure. Architects should design availability, caching, and fallback behavior accordingly.
Deployment architecture should make change safe
Automated deployments reduce manual error and make infrastructure repeatable. Infrastructure as code, deployment pipelines, staged environments, canary or blue-green techniques, and automated validation can all reduce release risk. The architect should recommend a deployment approach that matches the workload’s availability requirements and change frequency.
The AZ-400 DevOps path goes much deeper into delivery engineering, while AZ-305 focuses on whether automated and controlled deployment belongs in the architecture. For modern services, the answer is usually yes.
Network architecture connects the workload to its users and dependencies
AZ-305 includes internet connectivity, on-premises connectivity, network performance, security, load balancing, and routing. These decisions interact. A private application may need ExpressRoute or VPN rather than public exposure. A global application may need edge routing and regional load distribution. East-west traffic may need segmentation and private endpoints.
The AZ-700 networking path covers implementation depth, but the architect decides the topology and service roles. Network decisions should support application requirements rather than exist as a separate infrastructure exercise.
Load balancing depends on layer and scope
Some load-balancing requirements operate at transport layer, others at HTTP layer, and others across global regions. Health probing, session behavior, TLS termination, web application firewall integration, geographic routing, and failover behavior all influence the selection.
A common exam mistake is choosing a load balancer based only on the word “load balancing.” The architect should first identify protocol, scope, routing intelligence, security needs, and whether the solution is regional or global.
Security should be embedded in the topology
Network security groups, Azure Firewall, Web Application Firewall, private endpoints, DDoS protection, routing, and identity all contribute to infrastructure security. The right design minimizes unnecessary public exposure and creates clear trust boundaries between application tiers and administrative paths.
Security architecture should not add inspection devices everywhere without understanding traffic. Controls need an explicit purpose: restrict reachability, inspect application traffic, control egress, protect public endpoints, isolate management, or enforce identity-based access.
Observability is an infrastructure requirement
Distributed architectures are difficult to operate without logs, metrics, traces, health checks, and correlation. The architect should plan observability before an incident. That includes where telemetry is collected, which signals indicate service health, how alerts are routed, and how operators distinguish application failure from network or dependency failure.
Monitoring is especially important in asynchronous systems because failures may not be visible to end users immediately. A queue can silently accumulate backlog while the front end appears healthy. Operational architecture must make hidden failure visible.
Hybrid infrastructure needs latency and failure planning
When applications span Azure and on-premises environments, the network becomes a dependency. Latency, throughput, route convergence, DNS, identity, firewall policy, and circuit failure all affect application behavior. Hybrid designs should include a degraded-mode plan if private connectivity is interrupted.
The cloud architecture certification path provides broader context because hybrid design is a common cross-vendor challenge: architecture must account for the weakest dependency across both environments.
Use requirements to eliminate options
Architecture questions become easier when you use constraints to remove unsuitable choices. If the workload needs full OS control, serverless is unlikely to fit. If it needs massive burst elasticity with minimal operations, static VMs are unlikely to be ideal. If the API must be private, internet-first designs become less attractive. If users are global, a single regional entry point may violate latency and resilience goals.
This constraint-first method is more reliable than trying to remember which Azure service is “best.” There is no best service in isolation, only a service that best fits the stated requirements.
Architecture should minimize accidental coupling
Many infrastructure failures become severe because unrelated components share hidden dependencies. Multiple services might rely on one subnet, one identity, one database, one configuration store, or one deployment pipeline without the design making that dependency obvious. Architects should identify which components can fail independently and which dependencies deserve redundancy or isolation.
Loose coupling does not mean eliminating every shared service. It means sharing intentionally and understanding the blast radius. A shared platform can reduce cost and operations, but the design should explain what happens when that platform is unavailable and whether critical workloads have an acceptable fallback.
Capacity limits are part of the architecture
Azure services have quotas, regional availability differences, throughput limits, and scaling characteristics. A design that works at pilot scale can fail at production scale if the required capacity cannot be provisioned quickly enough or if a dependent service becomes the bottleneck. Capacity planning therefore belongs before deployment, not after the first saturation event.
For high-growth workloads, architects should identify likely ceilings, request quota increases early where necessary, and design graceful degradation when a downstream limit is reached. This is especially important for global, event-driven, and burst-heavy systems.
The durable lesson
Azure infrastructure architecture is the composition of compute, integration, networking, deployment, security, and operations into one workload system. Every service choice creates dependencies, failure modes, and operational responsibilities. AZ-305 tests whether you can see those interactions.
The Microsoft Azure infrastructure certification path covers the components in greater implementation depth. The architect’s responsibility is to select the right patterns, define the boundaries, and ensure that the complete design meets reliability, security, performance, and operational requirements rather than optimizing one component in isolation.