Microsoft AZ-305: Compute Architecture Choices

Compute design in Microsoft AZ-305 is an exercise in matching workload characteristics to the right execution model. Virtual machines, managed web platforms, containers, serverless functions, and batch services can all run code, but they differ sharply in control, scaling, deployment, isolation, and operational burden.

The current blueprint places compute inside the 30–35% infrastructure-design domain. Candidates should be able to recommend VM-based, container-based, serverless, and batch solutions, then explain how availability, networking, security, and application architecture change with that choice.

Profile the workload before selecting compute

Start with runtime requirements, operating-system control, deployment unit, traffic pattern, state, startup time, scaling behavior, compliance constraints, and team skills. A legacy application that installs drivers has different needs from an HTTP API that can scale horizontally.

Architects should also ask how often the application changes. A platform that accelerates frequent releases may create more value than one that offers maximum host control. Operational ownership is part of the decision, not an afterthought.

Choose virtual machines when host-level control is essential

VMs are appropriate when the application depends on a specific operating system, custom agents, kernel-level configuration, legacy middleware, or installation procedures that do not fit a managed platform. They also support lift-and-shift migration when modernization cannot happen immediately.

That control comes with responsibility. Teams must manage patching, image lifecycle, anti-malware, capacity, scaling, and availability. A VM architecture should therefore include automation for image creation, configuration, monitoring, and replacement rather than relying on manually maintained servers.

Use managed application platforms to reduce undifferentiated work

Managed web and application services are attractive when the workload fits supported runtimes and benefits from built-in deployment slots, autoscale, certificates, health checks, and platform patching. The architect trades some host control for a smaller operational surface.

This can be especially effective for standard web APIs and line-of-business applications. The design should still consider network integration, private access, identity, outbound connectivity, regional deployment, and whether the application can tolerate platform-specific constraints.

Select containers for portable deployment and service composition

containers and hypervisors have different isolation and resource boundaries; containers generally start faster and carry less guest-OS overhead than full virtual machines.

Container orchestration becomes valuable when the system has many services, frequent releases, variable scale, or requirements for rollout strategies and self-healing. The trade-off is platform complexity: clusters, networking, ingress, policy, observability, and capacity management all need architectural attention.

Understand where Kubernetes adds value

Kubernetes is not required just because an application uses containers. The distinction between pods and containers is useful because the orchestration layer introduces its own scheduling and lifecycle model. A simpler container platform may be a better fit for a small number of services.

Use a managed Kubernetes service when the workload genuinely needs orchestration flexibility, ecosystem tooling, complex service topology, or portability. Otherwise, a simpler managed container environment can reduce operational overhead while retaining container packaging.

Use serverless for event-driven and bursty work

Functions and other serverless models fit workloads that react to events, run briefly, scale rapidly, and do not require long-lived host state. Billing tied to execution can be attractive for intermittent workloads, and platform management is minimal.

The architect must still consider execution duration, cold start, networking, concurrency, downstream throttling, and idempotency. A function that scales instantly can overwhelm a database that cannot. Serverless design therefore requires end-to-end capacity reasoning.

Design batch compute around throughput and queueing

Batch processing often values total throughput, parallelism, scheduling, and cost more than request latency. Jobs can be queued, partitioned, retried, and distributed across pools of compute that scale according to backlog.

Spot or interruptible capacity may reduce cost for fault-tolerant jobs, but the application must checkpoint progress and recover from eviction. The architecture should distinguish jobs that can be retried safely from those with side effects that require stronger coordination.

Make availability a property of the application

Availability comes from multiple healthy instances, independent failure domains, health-aware traffic distribution, and state that survives instance loss. Simply choosing a managed platform does not guarantee that an application is resilient to region or dependency failure.

Stateless services are easier to replace and scale. When state is necessary, externalize it to appropriate data services and define consistency, session, and failover behavior. This makes compute instances disposable rather than irreplaceable.

Use the exam scenario to narrow the operating model

Candidates with an administration background from Microsoft AZ-104 should avoid choosing the service they know best. AZ-305 asks which operating model fits the requirement. Host control points toward VMs; orchestrated microservices may point toward Kubernetes; standard web apps may fit managed application hosting; event-driven bursts may favor serverless.

Then test the choice against security, network access, deployment frequency, scale, and recovery. The right compute answer is the one that satisfies the workload while minimizing unnecessary platform ownership.

Compute placement also interacts with licensing and software support. Some commercial applications have licensing terms tied to cores, hosts, or virtualization models. An architecture that looks cheaper in infrastructure can become more expensive after software licensing is included. Architects should capture these external constraints early because they can eliminate otherwise attractive platform choices.

Scaling strategy should match the unit of work. Horizontal scaling adds instances and works well for stateless requests, while vertical scaling increases resources on a single instance and may suit software that cannot distribute work. Horizontal scale generally improves resilience, but it often requires shared state, idempotent processing, and load distribution. The exam may present a simple growth requirement that actually implies a change in application architecture.

Deployment behavior is another differentiator. Managed platforms can support slots, staged releases, or rapid rollback, while VM-based systems may require image replacement or configuration orchestration. Container platforms can enable rolling, blue-green, or canary releases but need health probes and version-aware service communication. The design should consider how safely the organization can change the system, not only how it runs after deployment.

Compute security includes more than patching. Workload identity, network boundaries, secrets, image provenance, endpoint protection, and administrative access all vary by execution model. A serverless function may eliminate server patching but still expose sensitive credentials if the application stores them poorly. Managed services reduce some responsibilities; they do not remove application security.

Background processing is often better separated from interactive request paths. Queues can absorb bursts, let workers scale independently, and prevent users from waiting on long operations. This pattern also improves resilience because work can remain durable while workers restart. Architects should recognize when a scenario that asks for ‘better performance’ is really asking for asynchronous decoupling.

Stateful container workloads deserve caution. Kubernetes can run databases and other stateful systems, but the organization then owns more storage and recovery complexity than it would with many managed data services. The architect should choose stateful containers because the workload needs them, not because the organization has standardized on Kubernetes for stateless services.

Capacity limits and service quotas should appear in design reviews before production load arrives. Autoscale cannot create instances beyond quota, and regional platform limits can block a recovery plan. Observability should therefore track both application demand and available capacity headroom. The best compute architecture includes enough operational visibility to know when its assumptions are approaching a limit.

Architecture questions may also distinguish interactive services from scheduled or long-running processes. A workload that runs for hours can be a poor fit for a function execution model even if the code is simple. Conversely, keeping a permanent VM online for a task that runs for seconds a few times per day wastes capacity and increases patching work.

Compute choice affects team boundaries. A managed platform lets application teams own code while the cloud provider owns more of the operating system and runtime maintenance. A Kubernetes platform may require a dedicated platform team. AZ-305 answers should reflect whether the organization has the skills and operating model to support the proposed technology.

Disaster recovery for compute is easier when deployments are reproducible. Golden images, container registries, deployment templates, and infrastructure code allow a secondary environment to be created consistently. A server that exists only because an administrator configured it manually is much harder to recover confidently.

Resource placement also affects latency between tiers. A compute platform in one region that calls a database in another may technically function while adding unacceptable response time and egress cost. Architects should keep tightly coupled tiers close unless a specific resilience or sovereignty requirement justifies separation.

Temporary and ephemeral compute can simplify clean deployment. Replacing instances from a known image or container version is often safer than repairing long-lived servers in place. This immutable mindset reduces configuration drift and makes scaling and recovery more predictable.

Cost evaluation should include idle capacity, operational labor, and platform fees together. A VM may appear inexpensive until patching and standby instances are included; a managed platform may look more expensive per unit while eliminating entire categories of administration. Architecture decisions are stronger when they compare total operating cost rather than list price alone.

When the scenario leaves several compute options technically possible, prefer the model that removes operational responsibilities the application does not need. Extra control is useful only when a requirement depends on it; otherwise it becomes another surface to patch, monitor, scale, and recover.