AZ-900: Understanding the Azure Decision Map

Azure Fundamentals becomes easier when the services stop looking like a catalogue and start looking like decisions. A small company wants to launch a customer portal, protect employee access, maintain useful recovery options and avoid paying for idle capacity. None of those requirements names a product. They describe outcomes: ownership, availability, cost, security and the ability to change course. The AZ-900 exam tests whether you can connect those outcomes with cloud concepts and the roles of Azure services. It does not ask a fundamentals candidate to build an entire production environment from memory.

The July 2026 Microsoft outline allocates roughly a quarter to a third of the exam to general cloud concepts, a larger share to architecture and services, and the remainder to management and governance. These are not isolated blocks. A virtual machine decision changes who patches the operating system; a region decision affects latency and resilience; a subscription boundary changes billing and administration. Understanding those connections is more durable than memorizing a long list of service names.

Begin with the operating model, not the product

Imagine a retailer moving an internal order-processing application from its own server room into Azure. The first question is not whether an Azure virtual machine has enough memory. It is which responsibilities the retailer wants to continue performing. With infrastructure as a service, the organization still manages the guest operating system, installed software, much of the configuration and application data. The cloud provider runs the physical facility and underlying infrastructure. With a managed application platform, the provider takes on more of the runtime infrastructure. With software as a service, customers principally configure and use an application while the supplier operates the application stack.

This is the shared responsibility model in practical terms. Cloud adoption transfers certain duties; it does not transfer accountability for everything. A stolen credential or an overly broad permission can expose data even when the physical datacenter is professionally secured. Nor does a managed database remove the need to decide retention periods or understand who is allowed to query sensitive records. Recognizing which control belongs to which party is more useful than assuming that moving a workload to Azure makes it secure automatically.

Public, private and hybrid cloud describe deployment relationships, not service-quality rankings. A hybrid organization might retain a sensitive legacy application on premises while hosting a modern portal in Azure, connected through controlled networking. That does not automatically imply better resilience: two interconnected environments add dependencies and can complicate identity, monitoring and change management. A grounded account of public, private and hybrid cloud models helps clarify why a deployment model is a business and architecture choice rather than a prestige label.

Match elasticity, scalability and availability to the workload

A seasonal ticketing site needs enough capacity for a short surge without paying for peak traffic all year. Scaling means adding resources or increasing their capacity. Elasticity means adjusting those resources in response to demand, potentially scaling back when the rush ends. Consumption pricing is valuable only when the organization can control the resources it consumes; a permanently oversized virtual machine still accrues charges in the cloud. An automatically scaling service can save money, but its benefit depends on scale rules, workload behavior and the price of connected services.

Availability addresses a different problem. Adding compute instances can improve throughput while doing little for a shared database failure. An availability zone provides physically separate facilities within a region, but an application does not become zone-resilient simply because the region offers zones. Workload components must be configured to use suitable redundancy and tolerate failures. Cross-region designs deal with a different failure scope and usually introduce more cost, data-replication and recovery decisions. The difference between high availability and fault tolerance is especially helpful when a scenario describes graceful recovery rather than literally uninterrupted service.

Reliability and predictability are not synonyms for unlimited capacity. Predictable performance depends on sensible limits, monitoring and load testing. A service may be highly available yet too slow at peak demand. The AZ-900 skill is to notice which requirement is under discussion before selecting a concept such as autoscaling, redundancy or disaster recovery.

See how Azure organizes ownership and control

Azure resources are deployed in resource groups, which sit within subscriptions; subscriptions can be organized under management groups. Those constructs do different jobs. Resource groups are logical lifecycle and management containers, subscriptions provide an important billing and access boundary, and management groups allow governance assignments across collections of subscriptions. A resource can belong to one resource group at a time, while the same subscription can contain many resource groups. The resource’s region is a separate attribute from the region where resource-group metadata is kept.

Consider a company with development, production and regulated workloads. Placing everything in one resource group because the applications share a brand would obscure the fact that they have different access requirements and change schedules. Conversely, making a separate subscription for every tiny component may increase operational overhead. The design should reflect ownership, spending accountability, isolation and policy. Applying role-based access control at an appropriate scope helps grant access to the people who need it without giving every contributor administrative control over the wider tenant.

Subscriptions also prevent a common billing misunderstanding. A management group does not itself replace a subscription, and resource tags do not move a charge to a new invoice. Tags provide metadata for classification, reporting and automation; they work best when teams consistently apply them. If finance needs reliable cost allocation, tag design must be accompanied by accountability for untagged or shared resources.

Learn to read a service choice as a bundle of responsibilities

A simple web application might run on an Azure virtual machine, Azure App Service or a container platform. A VM offers guest operating-system control but entails operating-system upkeep. App Service abstracts much of the hosting platform and lets developers concentrate on the application. Containers package application dependencies consistently, but someone must still decide how to deploy, scale, patch base images and observe the running workload. Azure Functions fits event-driven tasks that execute in response to a trigger. None of these choices is universally cheapest or best.

The foundational distinction is between the amount of control required and the operational burden the team can absorb. A vendor-supplied application demanding a particular operating-system configuration may justify a VM. A straightforward managed web application may not. A scheduled image-processing task with unpredictable bursts may suit event-driven execution. Candidates studying beyond these first principles can explore the administrator’s scope in AZ-104, but AZ-900 is fundamentally about recognizing the relevant service class rather than writing deployment scripts.

Storage and networking enter the picture immediately. A web server may need an object store for uploaded documents, a private path to a database and a public endpoint for visitors. Choosing a compute service without considering those dependencies produces an incomplete architecture. In AZ-900 questions, separate the requested capability from implementation details that belong to specialist certifications.

Understand why costs do not follow the headline price

Pay-as-you-go pricing replaces some capital spending with variable operational expenditure, but the actual bill depends on usage patterns. Compute time, storage capacity, transactions, networking transfer and managed-service features can all affect costs. A backup copy in another region may be a sensible resilience expense; a forgotten test environment running every evening may not. Predicting costs therefore begins with a workload estimate, an availability design and an explicit account of the resources that continue running when no one is using the application.

Azure’s pricing calculator helps forecast planned configurations, while cost-management tools analyze spending against actual activity. Budgets and alerts can prompt investigation, but they should not be mistaken for automatic spending caps. Tags make it easier to distinguish production from test expenses, yet they do not correct poor ownership records by themselves. Reserved capacity or other commercial commitments may lower unit costs for predictable workloads while reducing flexibility; the right comparison includes expected utilization and terms, not just a displayed discount.

For an AZ-900 scenario, watch the verbs. “Estimate” points toward a calculator; “analyze an unexpectedly high bill” points toward monitoring and cost-management views; “identify which team owns a resource” points toward metadata and governance. These are related tasks performed by different features.

Distinguish policy, protection and monitoring tools

Azure Policy evaluates resource configurations against defined rules and can support governance at scale. A resource lock restricts specified management operations, such as accidental deletion, but it is not a comprehensive security boundary. Microsoft Purview addresses governance and compliance concerns involving data. Neither a tag nor a lock replaces identity permissions. A coherent environment uses separate controls for separate purposes: preventive access rules, configuration governance, operational safety and evidence that the controls continue to work.

The same separation applies to operations. Azure Advisor provides recommendations based on aspects of an environment; Service Health informs customers about relevant platform events and service issues; Azure Monitor collects and analyzes operational telemetry, including logs, metrics and alerts. An application that is slow for one subset of users may require application telemetry and tracing rather than a general service-status page. A region-wide platform event is not diagnosed in the same way as a faulty deployment. Learn what question each tool answers before trying to memorize its user interface.

Management tools also have distinct roles. The Azure portal is graphical; Azure CLI and Azure PowerShell support command-line management; Cloud Shell provides a hosted command environment; Azure Resource Manager is central to defining and managing Azure resources. Infrastructure-as-code templates express a desired configuration that can be reviewed and deployed consistently. Repeating an installation procedure manually is not equivalent to describing the intended infrastructure declaratively.

Use a single scenario to connect the domains

Return to the retailer. Its customer portal needs a public web endpoint, a protected order store, staff access, a modest monthly budget and a recovery approach. A plausible Azure design must identify the service model for the application, select an appropriate region and availability configuration, assign resources to a meaningful management boundary, define who can change infrastructure, and estimate the cost of both normal operation and resilience. Monitoring must distinguish application problems from Azure service incidents. Those decisions belong together even though Microsoft’s study guide sorts them into separate skill groups.

A useful self-check is to change one requirement at a time. If the business now insists that only private connectivity reach the database, does the compute choice change, or mainly the network design? If finance asks for per-department spending visibility, do permissions need adjustment, or is the immediate gap tagging and cost allocation? If an outage affects one facility, can the proposed deployment actually survive it? Practicing these distinctions helps avoid the wrong answer that happens to name a popular Azure product. Fundamentals is the art of identifying the layer at which a problem should be solved.