Sign in Subscribe

AZ-900 Core Azure Services Explained: Compute, Networking, Storage, and Databases for Beginners Preparing for Microsoft Azure Fundamentals

AZ-900 Core Azure Services Explained: Compute, Networking, Storage, and Databases for Beginners Preparing for Microsoft Azure Fundamentals

Introduction

When I teach AZ-900, I always tell people not to treat Azure like a giant flashcard deck. Honestly, that’s just not how the exam works. What Microsoft’s really checking is whether you can recognize the main service families, see how they fit together, and pick the one that best matches the scenario you’re looking at. Put simply, Azure is more about spotting patterns than memorizing a pile of product names — are you after full control, or are you trying to keep management overhead as low as possible? Regional or global delivery? Relational or NoSQL data? Public access or private access?

This guide covers Azure core services with that decision-making lens. I’m keeping this practical and exam-focused, but I also want you to walk away with a solid mental model right from the start.

Azure global infrastructure, governance, and ARM — the big pieces that hold the whole platform together

Azure runs in geographies, which contain regions such as East US or West Europe. A region is basically a group of datacenters in a specific geographic area where Azure services are available. And here’s the thing: not every service or feature exists in every region, so your region choice can affect latency, compliance, cost, and sometimes even whether a feature is available at all.

Availability Zones are unique physical locations within an Azure region, each with independent power, cooling, and networking, and each made up of one or more datacenters. Zones are there to help protect you from a datacenter-level failure inside a region. That said, not every region has them, and not every Azure service can take advantage of them, so it’s worth checking that assumption before you rely on it.

Region pairs are Azure-defined regional relationships used for platform resilience, update sequencing, and some replication patterns. They help with disaster recovery planning, but they do not automatically fail over your application. If your workload needs real failover, that still comes down to how you’ve designed the application and data layers.

The management hierarchy is Management Groups → Subscriptions → Resource Groups → Resources. Subscriptions are primarily billing and administrative containers. Access is enforced through Azure RBAC, which can be assigned at management group, subscription, resource group, or resource scope. Resource groups are logical containers for related resources, and in real projects I usually see them grouped around a shared lifecycle. In other words, if the pieces usually get created, updated, and retired together, they probably belong in the same resource group.

For governance, remember four supporting tools: tags for organization and cost reporting, Azure Policy for compliance rules, resource locks to prevent accidental deletion or modification, and RBAC for least-privilege access.

Azure Resource Manager (ARM) is Azure’s control plane for deploying and managing resources. Whether you’re using the portal, Azure CLI, PowerShell, templates, or APIs, ARM is still the part handling the request behind the scenes. Different tools, same control plane underneath. ARM supports declarative deployment, dependency handling, tagging, policy enforcement, and repeatable infrastructure-as-code workflows that don’t fall apart the second you run them twice. For repeatable deployments, you may see ARM templates or Bicep, with Bicep now being Microsoft’s preferred authoring experience for many infrastructure-as-code scenarios.

Control plane vs data plane is worth knowing: creating a storage account is a control-plane operation through ARM; reading a blob inside that account is a data-plane operation against the storage service itself.

Compute Services

The most common AZ-900 compute decision is this: choose the least complex service that still meets the requirement.

Shared responsibility model: with IaaS like Virtual Machines, you manage the OS, patches, runtime, and much of the security configuration. With PaaS like App Service or Azure SQL Database, Microsoft manages more of the platform. With serverless like Functions, you focus mostly on code and triggers. With SaaS, you mostly consume the application.

Azure Virtual Machines are IaaS and give full OS control. I’d use them for lift-and-shift migrations, legacy apps, custom agents, or any situation where you’ve got unusual OS-level requirements to deal with. With VMs, though, you’ve still got to think through sizing, images, disks, networking, patching, backups, and availability design on your own. That flexibility is great, but it does come with more management overhead. For VM high availability, know the difference between Availability Sets and Availability Zones: sets spread VMs across fault and update domains in a datacenter; zones spread them across separate physical locations in a region.

Virtual Machine Scale Sets deploy and manage groups of similar VMs and can scale based on rules such as CPU or schedule. They often work with Azure Load Balancer, but the big exam takeaway is that they’re meant for elastic scaling of VM-based workloads.

Azure App Service is PaaS for web apps and APIs. It is usually the best answer when the requirement is “host a web app without managing servers.” Some of the key features to recognize are App Service plans, scale up versus scale out, deployment slots, custom domains, TLS/SSL, and authentication integration. If you’re dealing with a straightforward website or API, App Service is usually the first place I’d look. It’s a really solid fit when you want managed web hosting without dragging servers into the conversation.

Azure Functions is event-driven serverless compute. That “something” could be an HTTP request, a timer, a queue message, or even a blob upload. So instead of always running, it just wakes up when it’s needed. Functions can run on Consumption, Premium, or App Service plans, depending on how much control, performance, and predictability you want. That choice matters more than people think. They cut down a lot of infrastructure management, but startup latency can vary depending on the hosting plan, so don’t assume every function wakes up instantly.

Azure Kubernetes Service (AKS) is managed Kubernetes. Azure manages the control plane, but you’re still on the hook for things like node pools, workloads, networking choices, upgrades, and your overall security posture. So yes, it’s managed — but it’s definitely not zero-effort. AKS is the right choice when you genuinely need Kubernetes orchestration for microservices or a more complex container platform. I’d definitely avoid using it just because you need a place to run a web app — that’s usually overkill.

Azure Container Instances (ACI) runs containers without a full orchestrator. It works well for simple container workloads, batch jobs, testing, or small container groups. It can run longer-lived containers too, but it doesn’t give you the orchestration, rolling deployments, autoscaling, or deeper service management you get with AKS. So it’s simpler, but also less capable.

Azure Container Apps is worth awareness at a high level as a more managed container option between ACI and AKS. For AZ-900, AKS and ACI are usually the main comparison points, but Container Apps can still pop up in broader Azure discussions. So it’s definitely worth recognizing, even if it isn’t the main focus.

Azure Virtual Desktop provides desktop and app virtualization for remote users. The simplest way to think about it is that it’s for virtual desktops and remote app delivery, not general-purpose web hosting. At a high level, pooled desktops are shared across users, while personal desktops are dedicated to one user. That distinction shows up a lot in exam questions.

Quick compute clues: full server control = VM; scalable VM fleet = Scale Set; managed web app/API = App Service; event trigger = Functions; Kubernetes orchestration = AKS; simple container run = ACI.

Networking and Network Security

An Azure Virtual Network (VNet) is your private network in Azure. You divide it into subnets for segmentation, security, and delegated service placement. Good network design starts with address planning, because you really don’t want your Azure IP ranges colliding with what you already use on-premises. That overlap causes headaches fast.

VNet peering connects VNets privately over the Microsoft backbone. It is low-latency, but it is not transitive by default. Subnets are also where you often apply Network Security Groups (NSGs), which filter traffic using allow/deny rules. At a higher level, Azure Firewall provides centralized network traffic control, and DDoS Protection helps defend internet-facing workloads from volumetric attacks.

Public IP means internet reachable. Private IP means reachable only within a VNet or connected private network. For PaaS services, you should also know Private Endpoint/Private Link, which lets you access services like Storage or SQL over a private IP, and service endpoints, which extend VNet identity to supported services.

VPN Gateway provides encrypted connectivity over the public internet. The VPN types you’ll hear about most often are site-to-site, point-to-site, and VNet-to-VNet. Those names come up often enough that they’re absolutely worth recognizing. ExpressRoute provides private dedicated connectivity through a provider. One important nuance is that private connectivity is not the same thing as automatic encryption. ExpressRoute traffic isn’t inherently encrypted by default, so some organizations still add encryption on top.

For name resolution, Azure DNS hosts public DNS zones. Azure Private DNS provides private name resolution inside VNets and is commonly paired with Private Endpoints.

For traffic distribution, separate the services clearly. Azure Load Balancer is Layer 4 for TCP/UDP and can be public or internal. It uses frontend IPs, backend pools, health probes, and rules to spread traffic across targets. You don’t need to memorize every setting for AZ-900, but the overall idea really matters. Application Gateway is Layer 7 for HTTP/HTTPS and supports host-based and path-based routing, SSL/TLS termination, and optional WAF protection through WAF policies or WAF-enabled service tiers.

Traffic Manager is DNS-based global routing. It doesn’t proxy the traffic itself; it just answers DNS queries using methods like priority, weighted, geographic, or performance-based routing. That’s a very common exam distinction. Failover is influenced by DNS caching and TTL, so it may not look instant from every client.

Azure Front Door is a global Layer 7 entry point for HTTP/HTTPS applications using Microsoft’s edge network. It gives you global routing, acceleration, health probing, origin groups, and optional WAF integration. A useful exam distinction is this: Front Door handles global application delivery for dynamic and static web traffic; CDN primarily caches static content.

Azure CDN is best when the requirement is static asset acceleration for images, scripts, media, or downloadable content. In modern designs there is some overlap with Front Door Standard and Premium capabilities, but CDN’s core identity is still edge caching for static content.

Quick network clues: TCP/UDP balancing = Load Balancer; URL/path routing or WAF = Application Gateway; DNS failover = Traffic Manager; global web acceleration = Front Door; static content caching = CDN; secure internet tunnel = VPN Gateway; private dedicated circuit = ExpressRoute.

Storage Services

A storage account is the top-level Azure container for services such as Blob, Files, Queue, and Table storage. Account type, redundancy choice, region, and performance tier can all affect what’s available, so you won’t see every option in every location. Azure storage definitely isn’t one-size-fits-all, and that’s part of why the choice matters.

Blob Storage is object storage for unstructured data such as backups, images, logs, and archives. Know the access tiers: Hot for frequent access, Cool for infrequent access, and Archive for long-term retention. Archive data must be rehydrated before normal access, so tiers affect storage cost, retrieval cost, and access latency. Protection features such as soft delete, versioning, and lifecycle management are separate from redundancy.

Azure Files provides managed file shares using SMB, and NFS is available for specific share types and configurations. It is a strong fit for lift-and-shift file shares, shared application storage, and hybrid scenarios with Azure File Sync.

Queue Storage is simple message storage for asynchronous workflows. It is useful when one component needs to hand work to another later. For exam purposes, remember that Queue Storage is simple messaging, while Azure Service Bus is for more advanced enterprise messaging features.

Table Storage is a schemaless NoSQL key-attribute store that uses partition keys and row keys. It is not a full relational database and not just a simple file store.

Managed Disks are block storage for VMs. Common disk types include Standard HDD, Standard SSD, Premium SSD, and Ultra Disk. They’re used for OS disks and data disks, and they work with snapshot and backup scenarios.

Do not confuse access tiers with redundancy. Redundancy options include LRS (copies within a single region), ZRS (across zones in a region), GRS (replication to a secondary region), RA-GRS (read access to the secondary region), GZRS (zone redundancy plus secondary region replication), and RA-GZRS (readable secondary with GZRS). Which of those options you can actually use depends on the region and the storage account type. That part trips people up more often than you’d think.

Quick storage clues: unstructured objects = Blob; shared drive semantics = Azure Files; async work queue = Queue Storage; schemaless key/attribute data = Table; VM disks = Managed Disks.

Database Services

The core exam split is relational vs non-relational. If the workload needs tables, relationships, and transactions, think relational. If it needs flexible schema, global distribution, or document-style data, think NoSQL.

Azure SQL Database is a managed relational PaaS database based on the SQL Server engine. It’s a strong fit for transactional business applications and structured data. High availability, backup, and scaling are built into the managed service model.

Know the broader SQL family comparison: Azure SQL Database is managed PaaS for single databases and elastic pools; SQL Managed Instance offers higher SQL Server compatibility with more instance-level features; SQL Server on Azure VM gives the most control but also the most management overhead.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database service. It supports multiple APIs, including SQL/Core, MongoDB, Cassandra, Gremlin, and Table. So depending on the workload, it can fit several different application styles. At a high level, the big ideas are global distribution, partitioning, consistency choices, and throughput concepts like RU/s. You don’t need to master the internals for AZ-900, but you do need to recognize what makes Cosmos DB different. For AZ-900, the big clue is still: globally distributed NoSQL with flexible data models.

Azure Database for PostgreSQL and Azure Database for MySQL are managed open-source relational database services. They’re especially useful when you want the benefits of a managed cloud service without rewriting an app that already depends on PostgreSQL or MySQL. That compatibility story is a big reason people choose them.

Quick database clues: structured transactional app = Azure SQL Database; higher SQL Server compatibility = SQL Managed Instance; full SQL/OS control = SQL Server on VM; globally distributed NoSQL = Cosmos DB; existing PostgreSQL/MySQL app = matching managed service.

Identity, authorization, and security basics

Microsoft Entra ID is the identity platform formerly known as Azure Active Directory. It handles identities for users, groups, applications, and managed identities. So it’s really the identity foundation underneath a lot of Azure access scenarios. The clean distinction is this: authentication proves who you are; authorization determines what you can do.

In Azure, Entra ID commonly handles authentication, while Azure RBAC handles authorization to Azure resources. RBAC assignments can be scoped at the management group, subscription, resource group, or individual resource level. That gives you a lot of flexibility without having to overexpose everything. For stronger security, know the high-level role of MFA, Conditional Access, single sign-on, and managed identities. Managed identities matter a lot because they let Azure resources authenticatete to other Azure services without storing secrets in your code.vices without having to store secrets in your code.rdcoding secrets into your code.our code.

Security runs through everything in Azure, so I always come back to the same basics: use least privilege, encrypt data at rest and in transit, keepp public exposure to a minimum, and use NSGs and firewallss for network control, use WAF for web protection, and use private endpoints when PaaS traffic should stay private.

Monitoring, Troubleshooting, and Practical Service Selection

AZ-900 isn’t a deep operations exam, but a little troubleshooting logic definitely helps you choose the right service. Azure Monitor collects metrics, logs, and alerts. Log Analytics stores and queries operational data. Health probes matter for Load Balancer, Application Gateway, Front Door, and Traffic Manager because routing decisions depend on whether the backends are healthy.

If users can’t reach a VM, I’d check the obvious path first: public IP or private path, NSG rules, subnet routing, load balancer rules, and whether the VM is actually running. If a global app feels slow, ask whether the issue is static content caching, regional placement, or whether Front Door would solve it better. If data must stay private, think Private Endpoint, VPN, or ExpressRoute rather than public endpoints.

Here are four compact reference patterns:

  • Modern web app: App Service + Azure SQL Database + Front Door + Entra ID
  • Legacy server app: VM + Managed Disks + VPN Gateway/ExpressRoute + Azure Files
  • Event workflow: Blob Storage + Queue Storage + Functions
  • Global low-latency app: Front Door + Cosmos DB + multi-region design

A tiny CLI example is enough to connect the concepts:

az group create --name rg-demo --location eastus
az storage account create --name mystorageacct123 --resource-group rg-demo --location eastus --sku Standard_LRS

And a minimal Bicep example for repeatable deployment looks like this:

resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
 name: 'mystorageacct123'
 location: resourceGroup().location
 sku: { name: 'Standard_LRS' }
 kind: 'StorageV2'
}

AZ-900 Rapid Review: Common Confusion Points

Region vs Availability Zone: geography vs isolated physical location within a region.

Resource Group vs Subscription: lifecycle grouping vs billing/admin container.

Entra ID vs RBAC: authentication vs authorization.

VM vs App Service vs Functions: full control vs managed web hosting vs event-driven code.

ACI vs AKS: simple container hosting vs Kubernetes orchestration.

Blob tier vs redundancy: access cost/latency vs resilience scope.

Blob vs Files: object storage vs shared file shares.

Load Balancer vs Application Gateway: Layer 4 TCP/UDP vs Layer 7 HTTP/HTTPS routing and WAF.

Traffic Manager vs Front Door: DNS-based endpoint selection vs global Layer 7 application delivery and acceleration.

VPN Gateway vs ExpressRoute: encrypted internet tunnel vs private dedicated connectivity.

Azure SQL Database vs Cosmos DB: relational transactions vs globally distributed NoSQL.

Final Exam Strategy

When you see an AZ-900 question, identify the requirement keywords first: event-driven, shared file access, global acceleration, private connectivity, relational, NoSQL, full control, or low management overhead. Then eliminate answers that mismatch the service model.

Also remember that the exam usually wants the best fit, not every service that could technically work. If a managed service satisfies the requirement, it is often the right answer over a more complex IaaS design.

If you keep that mindset, Azure stops looking like a pile of product names and starts looking like a set of architectural choices. That’s exactly the shift AZ-900 is trying to test.