Microsoft Azure Fundamentals AZ-900: Core Azure Services Study Guide

1. Introduction to core Azure services

Honestly, Azure starts to click a lot faster when you stop treating it like a massive shopping catalogue and start seeing it as a toolbox for solving everyday IT problems.

For AZ-900, that way of thinking really matters.

It’s not trying to turn you into a cloud architect overnight. Basically, AZ-900 is checking whether you can read a requirement and spot the right service for the job. It’s not some mystical cloud puzzle, really. At the end of the day, it’s really just a case of matching the service to the job that’s actually sitting in front of you.

You’re not expected to know every knob and dial, but you are expected to recognise what a service does, when it makes sense, and when the simpler option is the smarter one.

The main service families are pretty straightforward, actually: compute runs workloads, networking connects them, storage holds the data, databases organise application information, and management tools help you deploy, govern, monitor, and secure the lot. AZ-900 leans hard on scenarios, so what you really want is service recognition: if the requirement calls for full OS control, think virtual machine; if it says managed web hosting, think App Service; and if it says event-driven code, think Functions.

One practical rule I always tell people to keep in mind is this: Azure has plenty of overlapping options, but AZ-900 usually rewards the most appropriate general-purpose service, not the flashiest one.

2. AZ-900 foundations for service choice

Before you start comparing services, it helps to get three basics straight: cloud service models, Azure architecture, and governance scope.

Cloud service models:

  • IaaS: Microsoft manages the physical datacenters, hardware, and core platform. You still handle the operating system, patching, applications, plenty of the network controls, and, of course, your data.
  • PaaS: Microsoft manages more of the platform and operating environment. That usually leaves you managing your application code, configuration, identities, and data.
  • SaaS: you consume a finished application. Microsoft manages most of the stack, while you still take care of users, access, and how the data gets used.

Shared responsibility is a constant exam theme.

In IaaS, you’re on the hook for more of the work.

That’s the trade-off, really, and it’s absolutely worth remembering.

With PaaS, Microsoft handles more of the plumbing, but you’re still responsible for things like data protection, access control, configuration, and identity decisions.

Azure architecture basics:

  • Regions are geographic areas where Azure services are deployed.
  • Availability Zones are separate physical locations within a region, each with independent power, cooling, and networking, and each made up of one or more datacenters.
  • Region pairs support parts of Azure's resilience design, but they do not automatically provide disaster recovery for every workload. You still need service-specific replication and failover planning.

Also remember that not every Azure service, feature, or SKU is available in every region. That regional availability can absolutely affect both real-world design choices and exam answers.

Resource hierarchy and scope:

  • Management groups: governance across multiple subscriptions
  • Subscriptions: billing, access, deployment, quota, and policy scope boundaries
  • Resource groups: logical containers for related resources
  • Resources: the actual services

Azure RBAC and Azure Policy can be applied at management group, subscription, resource group, or resource level, and permissions usually flow downward from there.

So if a question asks about organising many subscriptions under one governance model, think management groups.

If it asks where related app resources should live together, think resource group.

3. Azure compute services explained

ServiceBest fitOperational modelCommon exam clue
Azure Virtual MachinesLegacy apps, custom server workloadsYou manage OS and server configurationNeed full OS control
Virtual Machine Scale SetsLarge VM fleets with scalingVM-based with automated scalingNeed many identical VMs
Azure App ServiceWeb apps and APIsManaged platformDeploy code, not servers
Azure FunctionsEvent-driven processingServerless/event-drivenRun code when triggered
Azure Kubernetes ServiceContainer orchestrationManaged Kubernetes control planeNeed container orchestration
Azure Virtual DesktopRemote desktops and appsCentralised desktop deliveryDesktop for users

Azure Virtual Machines are IaaS. You choose the image, size, disks, networking, and OS.

A VM is usually built with a VNet, subnet, NIC, NSG, private IP, optional public IP, OS disk, and maybe data disks too.

You’re responsible for patching, backups, monitoring, and access hardening. In other words, you’ve still got real server responsibility on your plate.

If the requirement says install custom software, control Windows or Linux, or migrate with minimal code changes, VMs are the obvious fit.

VM Scale Sets extend that idea for many identical VMs with autoscaling. For AZ-900, it’s enough to know that scale sets are Azure’s way of running and scaling groups of VMs that all look the same.

Azure App Service is PaaS for web apps and APIs.

Microsoft handles the underlying infrastructure and platform patching, while you focus on the code, app settings, scaling rules, authentication choices, and some of the networking and security integration.

Key concepts worth recognising are App Service Plans, autoscale, deployment slots, custom domains, and TLS/SSL. If the question is about hosting a website or API without having to manage IIS or the operating system, App Service is usually the right call.

Azure Functions runs code in response to triggers such as HTTP requests, timers, or blob uploads. Functions use triggers and bindings to connect to other services. They can be billed per execution in the Consumption plan, but there are also Premium and Dedicated hosting plans. That means “pay only when the code runs” is not universally true. Functions are brilliant for short-lived, event-driven tasks, like processing a file that’s just landed in Blob Storage.

Azure Kubernetes Service (AKS) is for container orchestration.

Azure manages the Kubernetes control plane, but you’re still responsible for node pools, upgrades, networking choices, identities, workloads, ingress, and day-to-day cluster operations.

That’s what makes AKS powerful, but it also makes it a lot heavier operationally than App Service or Functions. I’m a big fan of keeping things as simple as the requirement allows.

If the scenario only says “host a website,” AKS is usually overkill.

Azure Virtual Desktop (AVD) delivers desktops or remote apps to users. Core terms are host pools, session hosts, workspaces, application groups, and profile storage such as FSLogix. AVD can support secure remote access, but security depends on Microsoft Entra ID, MFA, Conditional Access, session host hardening, and data handling controls. It is about desktop delivery, not just “a VM for each user.”

Quick comparison traps: VM vs App Service is control vs managed web hosting. App Service vs Functions is continuously hosted app vs event-driven code. VM vs containers is server environment vs packaged application. AKS only really becomes the right answer when you genuinely need orchestration.

4. Azure networking services explained

ServicePurposeExam clue
Virtual Network (VNet)Private network for Azure resourcesNeed private communication in Azure
Network Security Group (NSG)Traffic filtering for subnets/NICsAllow or deny inbound/outbound traffic
VNet peeringPrivate connection between VNetsConnect Azure networks privately
VPN GatewayEncrypted connectivity over the public internetHybrid connection over the internet
ExpressRoutePrivate dedicated connection to AzurePrivate connectivity, not internet transit
Load BalancerLayer 4 traffic distributionTCP/UDP balancing
Application GatewayLayer 7 web traffic routing + optional WAFPath-based HTTP/HTTPS routing
Azure Front DoorGlobal HTTP/HTTPS entry point and accelerationGlobal web routing and acceleration
Traffic ManagerDNS-based traffic routingRoute users to endpoints by DNS policy
Azure DNSHosts DNS zones and recordsName resolution
Azure BastionSecure RDP/SSH through the portalAdmin access without public VM IPs

VNet is your private Azure network. You divide it into subnets, attach resources, and control traffic with NSGs. VNet peering connects VNets privately over the Azure backbone. If a service should stay private, you may also see private endpoints, which let PaaS services be reached through private IPs instead of public endpoints.

VPN Gateway supports site-to-site, point-to-site, and VNet-to-VNet connectivity over encrypted tunnels on the public internet. ExpressRoute provides private connectivity that does not traverse the public internet for the connection path. It’s useful when you want more predictable performance and enterprise-grade hybrid connectivity, but it isn’t a full security solution on its own; you still need segmentation, identity controls, monitoring, and sometimes encryption.

Traffic distribution depends on the layer you’re working at, and that’s the bit people often miss. Azure Load Balancer is Layer 4 for TCP/UDP. Application Gateway is Layer 7 for regional web traffic, path-based routing, and optional Web Application Firewall. Azure Front Door is the global Layer 7 option for web acceleration and routing. Traffic Manager is DNS-based routing, not a load balancer in the same sense.

Azure CDN is used for caching static content closer to users.

If the question is about global performance for images, scripts, or downloadable files, CDN is usually the service to think about.

If it is about a global web entry point with routing and acceleration, think Front Door.

Troubleshooting shortcut: if users cannot reach a VM, check the VNet, subnet, NSG rules, route table, DNS, public or private access path, and gateway configuration. In fundamentals exams, the answer is often tucked away in one of those building blocks.

5. Azure storage services explained

ServiceBest fitCommon exam clue
Storage accountNamespace and management boundary for Azure StorageNeed Blob, Files, Queue, or Table services
Blob StorageUnstructured object storageBackups, media, logs, archives
Azure FilesManaged file sharesShared folders / mapped drives
Queue StorageSimple queue-based messagingBasic asynchronous processing
Table StorageNoSQL key-attribute storeSimple schemaless table data
Managed disksPersistent VM storageOS disk or data disk for a VM

A storage account is not just a generic container; it is the namespace and management boundary for Azure Storage services. When you create one, you usually choose the region, redundancy, performance tier, access settings, and sometimes network restrictions like firewall rules or private endpoints.

Blob Storage is object storage for unstructured data. Important concepts are containers, access tiers, lifecycle management, soft delete, versioning, and immutability. Blob access tiers are:

  • Hot: frequent access
  • Cool: infrequent access with lower storage cost but higher access cost
  • Archive: long-term retention with very low storage cost and slower retrieval

Azure Files provides managed SMB or NFS file shares.

It’s the better answer when the requirement is a shared folder, a mapped drive, or a hybrid file-server replacement.

Azure File Sync can extend those file shares into on-premises environments if needed.

Queue Storage is best for simple messaging between application components. For more advanced enterprise messaging features such as sessions, dead-lettering, transactions, ordering, or publish-subscribe patterns, Azure Service Bus is usually the better service.

Table Storage is a schemaless NoSQL key-attribute store using PartitionKey and RowKey. It’s not a relational database, and it’s definitely not a SQL table.

Managed disks are block storage for VMs.

You should recognise Standard HDD, Standard SSD, Premium SSD, and Ultra Disk as the main performance options.

Managed disks get attached to VMs, Azure Files is shared storage, and Blob is object storage.

Those are different access models, and that distinction matters a lot.

Storage redundancy is a high-yield exam topic:

  • LRS: multiple copies within a single primary region scope
  • ZRS: copies across availability zones in the region
  • GRS: copies to a secondary paired region
  • RA-GRS: GRS plus read access to the secondary
  • GZRS: zone redundancy in the primary region plus geo-replication
  • RA-GZRS: GZRS plus read access to the secondary

Pick redundancy based on the kind of failure you’re trying to protect against: a local hardware issue, a zone issue, or a full regional outage. And don’t forget that redundancy choices depend on the region and on whether the storage account or service supports them.

6. Azure database services explained

ServiceTypeBest fit
Azure SQL DatabaseFully managed relational database based on the SQL Server engineModern transactional apps
Azure SQL Managed InstanceManaged SQL with broader SQL Server compatibilityLift-and-shift style SQL workloads
Azure Cosmos DBGlobally distributed NoSQL databaseLow-latency, elastic, globally distributed apps
Azure Database for PostgreSQL - Flexible ServerManaged PostgreSQLApps requiring PostgreSQL compatibility
Azure Database for MySQL - Flexible ServerManaged MySQLApps requiring MySQL compatibility

Azure SQL Database is a fully managed relational database service in Azure based on the Microsoft SQL Server engine.

Think structured tables, relationships, and transactional workloads.

You should also recognise terms like logical server, firewall rules, private access, backups, scaling, and high availability.

Azure SQL Managed Instance sits between Azure SQL Database and running SQL Server on a VM. It’s still managed, but it offers broader SQL Server compatibility for applications that expect more traditional SQL Server features.

Azure Cosmos DB is Azure's globally distributed NoSQL database.

It supports multiple APIs and models, including SQL API, MongoDB, Cassandra, Gremlin, and Table.

The big ideas to know are global replication, low latency, elastic scale, throughput, and partition keys.

For AZ-900, the giveaway is usually global NoSQL with flexible schema and fast access across regions.

Azure Database for PostgreSQL - Flexible Server and Azure Database for MySQL - Flexible Server are managed relational services for those engines.

They cut down operational effort while keeping engine compatibility intact.

In questions, the deciding clue is often existing application dependency on PostgreSQL or MySQL.

Quick comparison: SQL Database and Managed Instance are relational.

Cosmos DB is non-relational.

PostgreSQL and MySQL are relational, but they’re usually chosen because the workload already depends on those ecosystems.

7. Management, governance, monitoring, and security tools

Azure Portal is the browser interface. Azure CLI and Azure PowerShell support scripting and automation. For example, az group list lists resource groups in the current subscription context that your signed-in identity can enumerate. Connect-AzAccount signs in for the current PowerShell session or context.

Azure Resource Manager (ARM) is the management plane for Azure resources.

ARM templates define infrastructure declaratively in JSON.

Bicep is the newer Azure-native authoring language that compiles to ARM and is generally easier to read and maintain. The key exam idea is repeatable, consistent deployment through infrastructure as code.

Microsoft Entra ID handles identity and authentication. Azure RBAC handles authorization to Azure resources using roles such as Reader, Contributor, and Owner. Access is often identity plus RBAC, not Entra ID alone. Managed identities let Azure services authenticate to other Azure services without storing secrets in code.

Azure Policy enforces governance rules, resource locks help prevent accidental deletion or modification, and tagging supports organisation, reporting, and chargeback.

Azure Monitor collects metrics, logs, and alerts. Log Analytics stores and queries operational data. Activity Log shows subscription-level control-plane events. Azure Service Health provides personalised guidance about issues affecting your services, while Azure Status shows broader platform status.

For security awareness, remember NSGs, private endpoints, encryption at rest and in transit, Azure Bastion, Key Vault for secrets, and Defender for Cloud for security posture recommendations. Fundamentals questions also expect least privilege, MFA, and identity-first thinking.

8. Common AZ-900 service confusion traps

  • VM vs App Service: need OS control = VM; need managed web hosting = App Service.
  • App Service vs Functions: always-on web app or API = App Service; event-triggered code = Functions.
  • VPN Gateway vs ExpressRoute: encrypted over internet = VPN; private dedicated path = ExpressRoute.
  • Load Balancer vs Application Gateway vs Front Door vs DNS: Layer 4 balancing = Load Balancer; Layer 7 web routing = Application Gateway; global web entry = Front Door; name resolution = DNS; DNS-based endpoint routing = Traffic Manager.
  • Blob Storage vs Azure Files: objects, backups, and media = Blob; shared folders = Azure Files.
  • Queue Storage vs Service Bus: simple queue = Queue Storage; advanced enterprise messaging = Service Bus.
  • SQL Database vs Cosmos DB: relational transactions = SQL; globally distributed NoSQL = Cosmos DB.
  • Entra ID vs RBAC: identity and authentication = Entra ID; permission to Azure resources = RBAC.

9. AZ-900 exam revision and final takeaways

What AZ-900 expects: know the purpose of major services, the difference between similar services, and the basic cloud model behind them. You do not need deep production configuration knowledge.

Memory aids:

  • VM = server control
  • App Service = managed web app
  • Functions = trigger-based code
  • AKS = container orchestration
  • AVD = desktops for users
  • VNet = private network
  • VPN = encrypted over internet
  • ExpressRoute = private dedicated connection
  • Blob = objects
  • Files = shared folders
  • SQL = relational
  • Cosmos = global NoSQL

Revision method: study by comparison pairs, not by memorising product names in isolation. Focus on VM vs App Service, Functions vs App Service, VPN vs ExpressRoute, Blob vs Files, SQL vs Cosmos, and Load Balancer vs Application Gateway vs Front Door.

Final exam advice: read the requirement carefully, identify the verb, and eliminate advanced services that are not explicitly needed. If the scenario does not mention containers, do not jump to AKS. If it does not require OS control, do not default to VMs. In AZ-900, the simplest correct Azure service is very often the right answer.