AZ-900: Regions, Compute, and Resilience

Cloud architecture begins with location and failure boundaries, not a diagram full of service logos. A product team may need fast responses for customers in several countries, a sensible recovery arrangement and a hosting platform that can be managed by a small engineering staff. Each requirement pulls the design in a different direction. The architecture portion of Microsoft AZ-900 asks candidates to identify Azure regions, availability zones, management hierarchy and broad compute options. It expects sound conceptual choices, not the configuration fluency of an Azure architect.

A helpful example is an online learning platform with users in Europe and Asia. Its website contains mostly read-heavy content, but account progress and payment events must be stored reliably. The correct conversation is not simply “Which region is fastest?” It is which parts of the system are sensitive to latency, which need data-residency controls, what failures the organization can withstand, and how much operational responsibility it wants to retain.

Region selection is a business decision with technical consequences

An Azure region is a geographic area containing datacenter infrastructure, and available services and capabilities can vary by region. Geographic proximity can reduce network latency, but it is not the only consideration. Data-residency requirements, regulatory obligations, approved service availability, pricing and the location of connected systems can all influence the final choice. A company whose customers are primarily in one country might still discover that its critical partner integration sits elsewhere and dominates end-to-end response time.

Region pairs and sovereign regions have specific roles in Azure architecture. A region pair is a concept used by Azure for some platform recovery and deployment considerations; it is not a promise that every service automatically replicates data to the partner region. Sovereign regions serve particular residency, compliance or jurisdictional needs and may differ from ordinary commercial Azure regions in identity, connectivity and service availability. It is risky to turn a regional label into a guarantee about a workload’s recovery behavior.

For a small site, starting with one appropriate region and a clear backup strategy may be reasonable. For a payment-processing system with stringent continuity requirements, the team may need to examine multi-region design, replication consistency and the cost of operating a second environment. AZ-900 rewards recognition of the trade-off; AZ-305 goes further into designing solutions to meet detailed architectural constraints.

Availability zones protect against a narrower class of failure

Availability zones are physically separate datacenter groupings within a supported Azure region, with independent infrastructure characteristics. Deploying across zones can reduce exposure to a localized facility failure. However, a region with zones does not automatically provide zonal redundancy to every application component. Virtual machines, databases, load balancers and storage need suitable configurations; supported choices depend on the service. A database confined to one zone can remain the single point of failure even if the web tier spans several.

An availability set is a different construct associated with spreading virtual machines across fault and update domains; it is not a synonym for an availability zone. Virtual Machine Scale Sets are chiefly a way to manage groups of VMs with consistent configuration and scaling characteristics. A scale set may participate in an availability design, but scale and resilience are not the same property. The exact placement model matters. A scenario describing a planned maintenance event calls for a different analysis from one describing complete region loss.

It also helps to separate recovery time from recovery point. Recovery time is how long a service may be unavailable; recovery point concerns how much recent data can be lost within an accepted objective. Multiple web servers might restore service quickly but cannot recover database transactions that were never replicated. The difference between high availability and fault tolerance puts those expectations into the right perspective. A resilience claim should describe which component and which failure it addresses.

Compute starts with control, execution pattern and operational burden

Azure virtual machines are appropriate when a team needs operating-system-level control or must run software that expects a particular environment. They involve choices about VM size, image, disks, networking, updates and monitoring. A VM is not just compute capacity; it has a lifecycle and dependencies. For a fleet of similar machines, repeatable configuration and scale mechanisms can reduce manual effort, but the team still owns substantial guest-system administration.

Azure App Service is a platform for hosting web applications and APIs without managing the underlying server fleet as directly. Containers bundle software and dependencies into portable images; hosting options vary from managed container application environments to Kubernetes orchestration. Azure Functions uses triggers for event-driven execution and is well suited to particular background tasks and integration patterns. A scheduled report processor and a continuously available customer-facing application may share code but have very different runtime needs.

Avoid treating serverless as a claim that no servers exist. It describes an operating and billing model that abstracts much of the server management from the application team. In some cases, event-driven execution and automatic scaling are a strong fit; in others, cold-start characteristics, execution limits, persistent connections or predictable steady loads affect the choice. AZ-900 questions usually ask you to identify the pattern, not tune runtime parameters.

A virtual desktop is not the same as a hosted website

Azure Virtual Desktop serves remote desktop and application delivery scenarios. Its users interact with a desktop session or published application rather than sending ordinary HTTP requests to a web service. That distinction matters when a scenario mentions contractors needing secure access to Windows applications from unmanaged devices. The architecture may involve identity, session hosts and user profiles—requirements different from hosting a public web application. A foundational candidate should recognize the service category without assuming every remotely accessed application needs virtual desktops.

A common error is to choose a VM whenever the question says “Windows.” App Service and other platforms may host applications written for Microsoft ecosystems, while Azure Virtual Desktop addresses interactive user computing. The key is what users actually need to do. If they must work inside a desktop environment, the desktop service may fit; if they need a REST endpoint for a mobile app, the requirement is application hosting. The difference is easy to miss when both use terms such as remote, Windows and application.

The broader AZ-140 specialization concerns Azure Virtual Desktop infrastructure in depth, but its existence should not tempt an AZ-900 learner to over-engineer a simple question about service purpose.

Account for the invisible dependencies around a compute service

A web tier cannot be evaluated in isolation. It needs identity, a data store, network paths, configuration and observability. A virtual machine requires storage and a network interface. A private workload depends on address spaces, subnets, routing, name resolution and sometimes hybrid connectivity. A container deployment needs images and a controlled approach to supplying secrets. An App Service deployment still needs application settings, network access and a way to observe failures. Managed hosting removes categories of maintenance but never eliminates architectural dependencies.

Consider two designs for the same learning platform. In one, a VM hosts the web application and database together. This might be quick to prototype, yet a reboot or a resource spike affects both functions. In another, managed hosting handles the application and a separate managed data service maintains course progress. The latter can give independent scaling and operational responsibilities, while introducing service-to-service authentication, network connectivity and pricing dimensions. There is no universal winner without knowing the team’s constraints and operating practices.

The distinction between containers and hypervisors provides a useful conceptual bridge: containers package processes using an operating-system kernel, while virtual machines virtualize a guest operating system. The choice affects isolation, portability and maintenance, but it does not by itself settle how resilient an application will be.

Resource organization should reflect the application’s lifecycle

A resource group provides a management container for associated Azure resources. A subscription is a key boundary for billing, access and quotas, and management groups can apply governance across subscriptions. Applications that are developed and retired together may reasonably share some resource-group lifecycle concerns, while a centrally managed network or monitoring service may have different owners and a different lifecycle. Simply putting every object in a group named after the company is not an architecture.

Teams should decide who can create, modify or delete resources before environments proliferate. A development group may need freedom to experiment, but the same identity should not necessarily have broad rights over production networking. Policy assignments and access scopes can express those differences. Location is another independent design dimension: placing resources in the same resource group does not mean their compute or data is co-located automatically. Read the requirement carefully whenever management constructs are mentioned alongside regions.

Resource organization affects incident response, too. During a service failure, engineers need to identify the owning team, deployment history and affected dependency. Naming conventions and tags are valuable only if they make that operational context discoverable. A well-structured subscription arrangement can simplify accountability, but it cannot substitute for an inventory of what connects to what.

Follow an outage through the architecture

Suppose users can load course pages but cannot save progress. The symptom points toward a stateful dependency rather than automatically proving that the entire Azure region is down. If a web instance failed, scaling or load distribution might maintain service; if the database is unavailable, extra web instances do not help. If a regional service incident affects the database, the recovery question becomes whether a tested cross-region arrangement exists and what data freshness it provides. The correct response depends on the component at fault.

Ask three questions of any resilience scenario: which failure boundary is involved, which components must remain available, and which trade-offs the design accepts. Availability zones, region choices, VM configurations and managed-service capabilities are different pieces of the answer. Good AZ-900 reasoning is not a memorized architecture diagram but a clear explanation of why a service and placement choice match the failure the business is actually concerned about.