AZ-900 Core Azure Services Explained: Compute, Networking, Storage, and Databases
1. Introduction
When I teach Microsoft Azure Fundamentals AZ-900, I tell people to stop memorizing product names and start recognizing service patterns. Azure is Microsoft’s cloud platform, but for the exam it helps to think of it as a toolkit: compute runs workloads, networking connects them, storage holds data, databases organize it, and governance keeps everything controlled.
AZ-900 is mostly a service-recognition exam. You usually are not being asked to build a full solution. You are being asked which service best fits a scenario. That means you need a clean mental model of cloud concepts. With IaaS, you’re basically renting the infrastructure and getting a lot of control over it, but you’re still responsible for the operating system and quite a bit of the software layer on top. PaaS takes a big chunk of the operational work off your plate, which is nice, because you can focus more on the application itself and the data it uses. SaaS is the finished product, plain and simple—you just use the app, and Microsoft takes care of the platform underneath. Serverless means you run code or workflows without managing servers directly.
A few terms matter a lot. Elasticity is the cloud’s ability to stretch or shrink resources automatically when demand goes up or down. Scalability is really about whether a service can grow with demand, either by adding more instances or by giving one instance more power. High availability means the service is designed to stay up and reachable even when something in the environment has a problem. Fault tolerance means the system can still keep running even if one of its parts fails. And the shared responsibility model changes depending on the service: with Azure Virtual Machines, you’ve got a lot more to manage than you do with App Service, and with SaaS, you’re responsible for much less. On the exam, always ask: what am I still responsible for?
Exam Tip: AZ-900 tests recognition and conceptual understanding, not deep deployment skills. If a question feels too technical, step back and identify the service category first.
2. What Azure core services are
Azure core services are the foundational building blocks used in most solutions: compute, networking, storage, databases, identity, and management. They are called “core” because they appear in almost every architecture, whether you are hosting a website, migrating a legacy application, supporting hybrid connectivity, or building a mobile backend.
The easiest way to study them is by problem solved. Need full operating system control? That points toward Azure Virtual Machines. Need a managed web platform? Think Azure App Service. Need shared file access? Azure Files. Need a relational database? Azure SQL Database. Need globally distributed NoSQL data? Azure Cosmos DB.
That pattern recognition is what AZ-900 rewards.
3. Azure global infrastructure and architectural components
Azure runs on a global infrastructure designed for performance, resiliency, and compliance. The terms sound similar, so precision matters.
Azure geographies are defined by data residency, compliance, and market boundaries. A geography contains one or more regions.
Azure regions are sets of one or more datacenters deployed within a latency-defined perimeter. The region you choose can affect latency, pricing, compliance requirements, and even which services are available to you. Not every Azure service is available in every region, so region selection is both a technical and business decision.
Availability Zones are physically separate datacenter locations within a supported region, each with independent power, cooling, and networking. They help protect against datacenter-level failures. Not all Azure regions support Availability Zones, so do not assume zonal deployment is always available.
Region pairs are Microsoft-defined paired regions used as part of Azure’s platform resiliency strategy. They matter for disaster recovery planning, but they are not a substitute for customer architecture decisions. Just because something is in Azure doesn’t mean you automatically have a complete disaster recovery design or guaranteed high availability. Actual availability depends on the service SLA and how you architect the workload.
Quick clues: data residency and legal boundaries point to geographies; user proximity and service placement point to regions; surviving a datacenter failure in one region points to Availability Zones; cross-region recovery planning points to region-pair awareness.
4. Resource organization, identity, and governance
Azure resources are organized in a hierarchy: management groups > subscriptions > resource groups > resources. A subscription isn’t only for billing; it also acts as a boundary for access, quotas, and policy. Resource groups hold related resources for a solution lifecycle. Management groups let large organizations govern multiple subscriptions consistently.
Azure Resource Manager (ARM) is the deployment and management framework for Azure. It provides the control plane experience used by the portal, command-line tools, scripting tools, templates, and APIs. Behind ARM, Azure resource providers expose service-specific capabilities.
Tags are name-value pairs used for cost tracking, ownership, environment, and reporting. They can be applied at multiple scopes, but tags do not automatically inherit in the same way policy and RBAC assignments can apply through hierarchy.
Microsoft Entra ID, formerly Azure Active Directory, is the identity service that controls sign-in and authentication. Azure RBAC controls authorization: who can do what, and at which scope. Common built-in roles include Owner, Contributor, and Reader.
Azure Policy is different from RBAC. RBAC gives people permissions. Policy enforces standards, such as requiring tags, restricting allowed regions, or auditing noncompliant resources. Policy effects include audit and deny. Resource locks add another governance control by helping prevent accidental deletion or modification.
Practical example: Finance might get Reader on a subscription, DevOps might get Contributor on a resource group, and a policy might require every resource to include a cost-center tag.
Memory aid: RBAC grants access; Policy governs standards.
5. Azure compute services
Compute is where workloads run, and this is a major AZ-900 topic because the services sound similar.
Azure Virtual Machines are IaaS. You’d choose them when you need full control of the operating system, custom software, or you’re doing a lift-and-shift migration from on-premises. You manage the OS, patching approach, runtime, and much of the application stack, even if some tasks can be automated with Azure tools.
Virtual Machine Scale Sets are groups of identical VMs that can scale out or in. They fit stateless workloads that still need VM-level control.
Azure App Service is a managed platform for web apps and APIs. It cuts down the infrastructure work quite a bit, but you’re still responsible for your code, app settings, identity integration, and the data the app uses. Features such as deployment slots, scaling plans, custom domains, and TLS support make it a strong default for managed web hosting.
Azure Functions is serverless, event-driven compute. It is a good fit when code runs in response to triggers such as HTTP requests, timers, queue messages, or blob uploads.
Azure Container Instances run containers without managing virtual machines or Kubernetes. This is a useful contrast with AKS: if you need simple container execution, ACI may be enough.
Azure Kubernetes Service (AKS) is a managed Kubernetes service. Azure manages the Kubernetes control plane, while you’re still responsible for container images, workloads, node pool choices, networking decisions, and Kubernetes objects. Use AKS when you need container orchestration for microservices or complex containerized apps. If the requirement is just “run one container,” AKS is usually too much.
Azure Virtual Desktop is a managed desktop and app virtualization service. It is usually the best answer when the scenario is about delivering remote desktops or remote applications to users.
Decision flow: need OS control = VM; need scalable identical VMs = VM Scale Sets; need managed web hosting = App Service; need event-driven code = Functions; need simple containers = Container Instances; need orchestrated containers = AKS; need desktops = Azure Virtual Desktop.
Security note: for compute, think patching responsibility, identity, secrets handling, and whether the workload is exposed publicly or only through private networking.
6. Azure networking services
Networking connects Azure resources, users, and on-premises environments.
Azure Virtual Network (VNet) is the private network boundary in Azure. Inside a VNet, you create subnets to segment workloads. Network Security Groups (NSGs) filter traffic with allow and deny rules at subnet or NIC level.
Azure Load Balancer distributes traffic at Layer 4 (TCP/UDP). It is used for high-performance network load balancing across back-end instances and can be public or internal.
Azure Application Gateway works at Layer 7 for web traffic. It supports HTTP/HTTPS features such as host-based and path-based routing, and it can include a Web Application Firewall.
Azure Front Door is a global entry service for web applications, providing edge acceleration, global routing, and application delivery optimization.
Azure DNS hosts DNS domains and records. It provides name resolution; it does not load balance traffic by itself in the same way a load balancer does.
VPN Gateway provides encrypted connectivity over the public internet, including site-to-site and point-to-site connections.
ExpressRoute provides private dedicated connectivity to Azure through a connectivity provider. It avoids the public internet path, but private does not automatically mean encrypted by default.
Other recognition-level services: Azure Firewall is a managed network security service, and Azure DDoS Protection helps defend against volumetric attacks.
Memory aid: DNS names, Load Balancer traffic, Application Gateway web routing, Front Door global web entry, VPN encrypted internet tunnel, ExpressRoute private dedicated link.
7. Azure storage services
The easiest way to understand Azure storage is by data type and access pattern. An Azure Storage account is the parent resource that can contain Blob, Files, Queue, and Table services.
Blob Storage is object storage for unstructured data such as backups, logs, media, and documents.
Azure Files provides managed SMB and NFS file shares for shared access.
Azure Disk Storage provides block storage attached to VMs. This is where VM operating system and data disks live. Common disk types include Standard HDD, Standard SSD, and Premium SSD.
Queue Storage supports asynchronous messaging between application components.
Table Storage is a NoSQL key-attribute store for large amounts of semi-structured data.
Blob access tiers are Hot, Cool, and Archive. These tiers apply to Blob Storage, not to every Azure storage type. Archive is for long-term retention and may require rehydration time before access.
Redundancy options are heavily tested: LRS keeps copies in one datacenter, ZRS replicates across availability zones in one region, GRS replicates to a secondary region, RA-GRS adds read access to that secondary region, GZRS combines zone redundancy with geo-replication, and RA-GZRS adds read access to the secondary region.
Security note: storage can be protected with encryption, firewall rules, shared access signatures, RBAC, and private endpoints. A common exam clue is public versus private access.
Memory aid: Blob = objects, Files = shares, Disk = VM-attached block storage.
8. Azure database services
For AZ-900, start with one question: is the data relational or NoSQL?
Azure SQL Database is a fully managed relational database service built on the SQL Server engine. That’s not the same thing as installing SQL Server on an Azure Virtual Machine. Choose it for structured, transactional applications when you want less infrastructure management.
SQL Server on Azure VM is still SQL Server, but hosted on a virtual machine. Use it when you need OS-level or SQL instance-level control.
Azure SQL Managed Instance sits between those two ideas at a recognition level: managed SQL with greater SQL Server compatibility than single-database Azure SQL Database scenarios.
Azure Database for MySQL and Azure Database for PostgreSQL are managed relational services for open-source database engines.
Azure Cosmos DB is a globally distributed NoSQL database designed for low-latency applications and flexible data models. It also supports multiple APIs, including SQL, MongoDB, Cassandra, Gremlin, and Table. At a recognition level, know that Cosmos DB uses partitioning and a throughput model commonly discussed as RU/s.
Security note: database access commonly depends on firewall rules, authentication choices, encryption, and sometimes private endpoints.
Memory aid: relational and transactional = Azure SQL Database; globally distributed NoSQL = Cosmos DB.
9. Azure management, monitoring, and deployment tools
Azure Portal is the web GUI and easiest place to learn. Azure CLI and Azure PowerShell are better for automation and repeatability. Cloud Shell gives you browser-based command-line or scripting access without local installation.
Example CLI commands:
az group create --name rg-demo --location eastus
az network vnet create --name vnet-demo --resource-group rg-demo --address-prefix 10.0.0.0/16 --subnet-name app-subnet --subnet-prefix 10.0.1.0/24
az storage account create --name mystorageacct12345 --resource-group rg-demo --location eastus --sku Standard_LRS
That last command needs a globally unique storage account name, which is why the example includes extra digits.
Infrastructure as Code means defining resources declaratively so deployments are repeatable and consistent. ARM templates are still relevant for AZ-900, but Bicep is the modern Microsoft-preferred authoring experience over raw ARM JSON.
Minimal Bicep example:
resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: 'mystorageacct12345' location: resourceGroup().location sku: { name: 'Standard_LRS' } kind: 'StorageV2'}
For operations, know three more services: Azure Monitor collects metrics, logs, and alerts; Service Health reports Azure platform incidents and maintenance; Azure Advisor gives best-practice recommendations for reliability, security, performance, and cost.
10. Common troubleshooting clues and exam traps
If a VM is unreachable, think public IP, NSG rules, routing, and OS firewall. If an App Service app is down, check the app status, deployment, configuration, and scaling plan. If storage access is denied, check keys, shared access signatures, RBAC, firewall rules, or private endpoint settings. If SQL connectivity fails, check the connection string, firewall, authentication, and network access path.
Common exam confusion pairs are predictable: VM vs App Service, AKS vs Container Instances, Load Balancer vs Application Gateway vs DNS, VPN Gateway vs ExpressRoute, Blob vs Files vs Disk, SQL Database vs Cosmos DB, and RBAC vs Policy.
Five quick drills:
1. Legacy Windows app needing admin access? Azure VM.
2. Web API with minimal server management? App Service.
3. Code runs when a blob is uploaded? Azure Functions.
4. Shared file access for several servers? Azure Files.
5. Global app with flexible schema and low-latency replication? Cosmos DB.
11. AZ-900 final review checklist
Before the exam, make sure you can recognize these one-liners: VM = full control; App Service = managed web hosting; Functions = event-driven serverless; AKS = container orchestration; VPN Gateway = encrypted over the internet; ExpressRoute = private dedicated connectivity; Blob = object storage; Files = shared file storage; Disk = VM-attached block storage; Azure SQL Database = managed relational database; Cosmos DB = globally distributed NoSQL; RBAC = permissions; Policy = compliance rules.
If you remember nothing else, remember this: AZ-900 rewards best-fit thinking. Match the requirement to the service, avoid overengineering, and watch for the trigger words built into the scenario.