Core Azure Services for AZ-900: What They Are and When to Use Them
If you’re getting ready for Microsoft Azure Fundamentals AZ-900, honestly, the quickest way to get comfortable with core Azure services isn’t to memorize a giant shopping list of product names. That usually falls apart pretty fast. What helps way more is learning to spot the pattern: what problem are you trying to solve, how much control do you really need, and who’s doing most of the heavy lifting — Microsoft or you? That is exactly how many AZ-900 questions are written.
So this guide stays practical and exam-focused. I’ll group Azure the way Microsoft expects you to think about it: infrastructure and hierarchy first, then compute, networking, storage, databases, and the tools and governance services that tie everything together.
Azure infrastructure, regions, and management hierarchy
Azure runs across a global infrastructure made up of geographies, regions, and datacenters. At the AZ-900 level, the big thing to remember is that a region is way more than just “a place on a map.” Think of it as a cluster of datacenters grouped together inside a low-latency boundary and connected through Microsoft’s regional network. The region you choose can absolutely affect latency, compliance, data residency, and, in some cases, even which services are available to you. Also, some Azure services are global, so not everything is tied to a single region in the same way.
Availability zones are separate physical locations within an Azure region, each made up of one or more datacenters with independent power, cooling, and networking. Zones are there to make a single region more resilient, plain and simple. Not every region supports availability zones, and not every service is zone-aware, so always treat zone support as region- and service-dependent.
Region pairs are Microsoft-defined regional pairings used in many continuity and recovery designs. The exam-safe way to think about it is pretty straightforward: zones help with high availability inside one region, while region pairs are about broader cross-region resilience. They do not replace customer disaster recovery planning, because actual failover and replication behavior depends on the service and architecture you choose.
One more nuance that helps on the exam: region selection influences data residency, but actual data location and replication can vary by service and redundancy option. For example, geo-redundant storage may copy data to another region.
Azure’s management hierarchy is equally important: management groups → subscriptions → resource groups → resources. Management groups are really useful when a large organization wants to apply governance across a bunch of subscriptions. Subscriptions are the boundary for billing, quotas, and access, which is why they matter so much in real environments. Resource groups are logical containers for resources that usually share the same lifecycle, project, or owner. And the resources themselves are the actual services you deploy, like VMs, VNets, and storage accounts. Resources in the same resource group can still be deployed to different regions.
Azure Resource Manager, or ARM, is the control plane for Azure. It’s what handles deployment, configuration, tagging, and policy-driven management. By contrast, data plane actions are the things you do inside the service itself, like reading blobs from storage. That control-plane versus data-plane distinction appears frequently in official Azure guidance and is worth recognizing.
Governance sits on top of this hierarchy. Role-based access control, or RBAC, can be applied at the management group, subscription, resource group, or resource level, and permissions flow downward from there. Azure Policy can enforce things like approved regions, required tags, or other rules you want consistently applied. For identity, Microsoft Entra ID underpins authentication across Azure administration, and managed identities let Azure resources authenticate to other services without storing secrets in code.
Azure compute services
Compute is really about control versus convenience. If you want maximum operating system control, you manage more. If you want Azure to handle more of the platform, you manage less.
Azure Virtual Machines are IaaS virtual servers. They’re a strong fit for lift-and-shift migrations, older apps, custom software stacks, and basically any situation where you want full OS-level control. You choose the image, size, disks, networking, and availability settings yourself, which is why VMs give you so much flexibility. In real life, a VM deployment usually comes with a VNet, a subnet, a network interface, disks, and often an NSG as well. For resilience, Azure can use availability sets or availability zones, depending on how the solution is put together. If the question says full control, custom software, or minimal app changes during migration, think VM.
Virtual Machine Scale Sets are for deploying and scaling largely identical VMs. They’re a great fit for stateless web tiers and batch workers, and they often sit behind Azure Load Balancer. Autoscale can respond to things like CPU usage or scheduled demand spikes. They are best for scale-out patterns, though per-instance customization is still possible through extensions or automation.
Azure App Service is PaaS for web apps and APIs. It’s the classic answer when you need managed web hosting and don’t want to get dragged into operating system maintenance. App Service runs inside an App Service plan, and that plan drives the pricing, scaling, and compute size underneath. The exam likes to hint at features like autoscaling, deployment slots, custom domains, TLS/SSL, built-in authentication, and WebJobs for background tasks. VM versus App Service is one of the most common AZ-900 comparisons: use VMs for server control, App Service for managed web hosting.
Azure Kubernetes Service, or AKS, is managed Kubernetes. Azure takes care of the Kubernetes control plane, but you’re still responsible for node pools, workloads, networking decisions, and a lot of the cluster operation side. AKS is for orchestrating containerized apps across multiple nodes, which is why it’s such a common fit for microservices and larger container platforms. If the wording says orchestrate containers, cluster, scaling, or microservices platform, AKS is usually the best fit.
Azure Container Instances, or ACI, runs containers without managing servers or a Kubernetes cluster. It works really well for isolated containers, task-based jobs, bursty workloads, or quick testing. It is not a replacement for Kubernetes-style orchestration, service discovery, or complex multi-container platform management.
Azure Container Apps is worth recognizing as a modern middle ground. It supports containerized apps with less orchestration complexity than AKS, and it’s often used for microservices, APIs, and event-driven containers. Even if it is not the centerpiece of every AZ-900 objective set, it is increasingly relevant in Azure comparisons.
Azure Functions is serverless, event-driven compute. Its triggers can be HTTP requests, timers, queue messages, or blob changes. Bindings make it easier to connect to other services without writing a ton of plumbing code. Functions is best for event-driven work and short-to-medium execution patterns. Durable Functions can handle longer workflow-style orchestration, but if you need something always on, that’s usually better handled somewhere else. If the prompt says “run code when an event happens,” think Functions.
Azure Virtual Desktop, or AVD, delivers full desktops and published remote apps from Azure. The core terms to recognize are host pools, session hosts, pooled versus personal desktops, and Microsoft Entra ID integration. It centralizes desktop and app delivery, but users still need endpoint devices to connect.
Quick exam clues: full OS control = VM; scale identical VMs = VMSS; managed web app = App Service; orchestrate containers = AKS; run a single container quickly = ACI; event-driven code = Functions; cloud desktops or remote apps = AVD.
Azure networking services
Azure Virtual Network, or VNet, is the private networking foundation in Azure. You start by defining an address space, then split it into subnets. Subnets help you segment workloads, like keeping web servers in one subnet and databases in another. For traffic filtering, know Network Security Groups, or NSGs: they allow or deny traffic to subnets or NICs based on rules.
Azure Load Balancer is a Layer 4 service for TCP/UDP traffic. It can be either public or internal, depending on what you’re trying to distribute. A public Load Balancer distributes internet-facing traffic, while an internal Load Balancer distributes private traffic inside the network. If the requirement is simple traffic distribution across healthy instances, think Load Balancer.
Azure Application Gateway is different. It works at Layer 7 for HTTP/HTTPS and supports web routing features like host-based routing, path-based routing, and Web Application Firewall integration. So if the question mentions web traffic inspection or application-layer routing, Application Gateway is usually the better fit than Load Balancer. Azure Front Door is another service to recognize for global web application delivery and acceleration.
VPN Gateway provides encrypted connectivity over the public internet. At fundamentals level, recognize site-to-site VPN for network-to-network connectivity and point-to-site VPN for individual client devices.
ExpressRoute provides private dedicated connectivity to Azure through a connectivity provider. The exam-safe distinction is simple: VPN Gateway uses encrypted tunnels over the internet; ExpressRoute uses private dedicated connectivity and can provide more consistent network characteristics for enterprise hybrid scenarios.
Azure DNS hosts DNS zones and records such as A, CNAME, and MX. Azure DNS is for authoritative DNS hosting, not general recursive browsing resolution. Also recognize Azure Private DNS for private name resolution inside VNets.
Other networking and security services worth recognizing: Azure Firewall for centralized network traffic filtering, Azure Bastion for RDP/SSH access to VMs without exposing public IPs, DDoS Protection for enhanced defense against volumetric attacks, and Private Link/Private Endpoint for private access to Azure PaaS services over a private IP rather than the public internet.
Azure storage services
A storage account is the top-level Azure Storage container for services such as Blob, Files, Queues, and Tables, depending on account type and features. The exam usually tests storage by asking what kind of data you have and how it is accessed.
Blob Storage is object storage for unstructured data such as application media, backups, and logs. It uses containers to organize blobs, which is an easy detail to remember. At a high level, block blobs are common for files and media, append blobs are good for append-heavy logging, and page blobs are used in scenarios like VHD storage. Access tiers matter: Hot is for frequently accessed data, Cool is for less frequent access, and Archive is for long-term retention. Archive is an offline tier with slower retrieval and rehydration delay, so it is not for immediate access.
Azure Files provides managed file shares over SMB, with NFS support in some scenarios. It’s the right choice when apps or users need shared file access that feels more like a traditional file server. Azure File Sync is the hybrid concept to recognize when on-premises file servers need to cache and sync with Azure.
Queue Storage is simple storage-based messaging for asynchronous processing. A producer places a message in the queue; a consumer retrieves and processes it later. For richer enterprise messaging features such as more advanced delivery patterns, Azure Service Bus is often the better service, so don’t confuse the two.
Table Storage is a NoSQL key-value store in Azure Storage. It is less emphasized than Blob or Files in many introductions, but it is still part of the core storage family and worth recognizing.
Managed Disks are persistent disks for Azure VMs. Azure abstracts the underlying storage management. Common disk types to recognize are Standard HDD, Standard SSD, Premium SSD, and Ultra Disk. Snapshots are used for point-in-time disk capture.
Storage redundancy is a high-frequency AZ-900 topic. LRS keeps multiple copies in one datacenter. ZRS replicates across availability zones in one region. GRS replicates to a secondary region. RA-GRS adds read access to the secondary region. GZRS combines zone redundancy in the primary region with geo-replication to a secondary region, and RA-GZRS adds read access to that secondary copy. The exam pattern is usually durability versus availability versus cost.
Azure database services
The first question in database selection is usually relational or non-relational. Azure SQL Database is a fully managed relational database service in Azure based on the SQL Server engine. It fits business applications, structured data, SQL queries, and scenarios where built-in high availability, backups, and reduced administration matter.
Azure SQL Managed Instance is worth recognizing as a managed service with broader SQL Server compatibility than Azure SQL Database, often useful in migrations where near-full SQL Server features are needed.
Azure Database for PostgreSQL flexible server and Azure Database for MySQL flexible server are managed PaaS offerings for teams that want those engines without self-managing infrastructure.
Azure Cosmos DB is a globally distributed NoSQL database designed for low latency, elastic scale, and flexible data models. It supports multiple APIs and models, including SQL, MongoDB, Cassandra, Gremlin, and Table options. It is not the default answer for every app, but if the scenario says globally distributed, flexible schema, or NoSQL at scale, Cosmos DB is the clue.
Management, deployment, monitoring, and security tools
For management tools, know the differences. Azure Portal is the browser GUI. Azure CLI is command-line and scriptable. Azure PowerShell is PowerShell-based administration. Azure Cloud Shell gives you browser-based CLI or PowerShell without local installation.
For infrastructure as code, ARM templates are JSON-based declarative deployments, and Bicep is the newer, more concise Microsoft-recommended authoring experience that compiles to ARM. Declarative means you describe the desired end state and Azure handles deployment idempotently.
resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: 'staz900demo123' location: resourceGroup().location sku: { name: 'Standard_LRS' } kind: 'StorageV2'}
That Bicep example is intentionally minimal but valid in structure, and it shows the current Azure direction better than an incomplete ARM JSON fragment.
For operations, recognize Azure Monitor for metrics, logs, and alerts; Activity Log for subscription-level control-plane events; Service Health for Azure service incidents and planned maintenance; and Azure Advisor for best-practice recommendations on cost, reliability, performance, and security.
For security, know Microsoft Defender for Cloud for security posture and recommendations, Key Vault for secrets and keys, and the basics of least privilege, encryption at rest, encryption in transit, private endpoints, and avoiding direct RDP/SSH exposure when Bastion or more secure access patterns are available.
Azure Marketplace is where Microsoft and third-party images and solutions can be deployed into Azure. It can accelerate implementation, but you still need to review publisher trust, cost, licensing, and compliance implications.
High-frequency AZ-900 comparisons and exam strategy
If you want the highest return on study time, master these comparisons:
Region vs Availability Zone vs Region Pair: region = deployment geography; zone = separate physical location within a region; region pair = broader cross-region continuity relationship.
Resource Group vs Subscription vs Management Group: resource group = logical container; subscription = billing and admin boundary; management group = governance across subscriptions.
VM vs App Service: VM for OS control, App Service for managed web hosting.
AKS vs ACI vs Functions: AKS for orchestrated containers, ACI for simple container runs, Functions for event-driven code.
Load Balancer vs Application Gateway: Load Balancer is Layer 4; Application Gateway is Layer 7 for web traffic.
VPN Gateway vs ExpressRoute vs Private Endpoint: VPN Gateway = encrypted internet tunnel; ExpressRoute = private dedicated connectivity; Private Endpoint = private access to a PaaS service.
Blob vs Azure Files vs Managed Disks vs Queue Storage: objects, shared files, VM disks, and messages.
Azure SQL Database vs Cosmos DB: relational SQL versus globally distributed NoSQL.
My elimination strategy for AZ-900 is simple: identify the service family first, then look for clue words such as managed, full control, event-driven, shared file access, private dedicated connectivity, relational, or globally distributed. In many questions, the most managed service that still meets the requirement is the best answer unless the scenario explicitly demands lower-level control.
Last-minute study checklist: can you explain the Azure hierarchy; distinguish regions, zones, and region pairs; pick VM versus App Service; separate AKS, ACI, and Functions; choose VPN Gateway versus ExpressRoute; map Blob, Files, Queues, Tables, and Managed Disks correctly; choose Azure SQL Database versus Cosmos DB; and recognize RBAC, Policy, Monitor, Advisor, Defender for Cloud, and Key Vault at a high level?
If you can do that, you’re not memorizing Azure anymore. You’re thinking like the exam expects you to think.