Microsoft Azure Fundamentals: Core Azure Services for AZ-900

1. Introduction to Core Azure Services in AZ-900

When I teach AZ-900, this is the point where people stop thinking “cloud equals rented servers” and start seeing Azure as a collection of service models, architectural choices, and managed capabilities. In the exam, “Core Azure Services” really means the main Azure service families you use to build, connect, store, secure, monitor, and govern workloads. Microsoft is not asking you to become an architect or administrator overnight. They want you to recognize requirements, compare service options, and choose the best fit.

The most important mindset is this: choose the most managed service that still satisfies the requirement. That single rule clears up a lot of confusion. If you do not need operating system control, a virtual machine is often not the best answer. If you do not need Kubernetes orchestration, AKS is usually too much. If you only need event-driven code, a full web hosting platform may be unnecessary.

You also need the cloud service models in your head. IaaS gives you the most control and the most operational responsibility. PaaS gives you a managed platform so you can focus more on the application and less on infrastructure. SaaS gives you a complete application delivered as a service. AZ-900 is mostly about mapping a business or technical need to one of those models and then to the right Azure service.

2. Azure Architectural Building Blocks

Before compute, networking, and storage, you need the Azure structure. Azure sits on a pretty massive global foundation, really. You've got geographies, regions, datacenter facilities, and edge locations all working together under the hood. A geography is a broad market area, such as Europe or the United States. A region is a set of one or more datacenter locations in a specific area, such as UK South or East US. An edge location is used for content delivery and network optimization services rather than general resource deployment.

Region choice is never just “pick the nearest one.” When I’m choosing an Azure region, I’m usually balancing a few things at once: latency, compliance, data residency, cost, and, honestly, whether the service I need is even available there. And here’s the thing — not every Azure service is available in every region, and not every service supports Availability Zones everywhere either. So if an exam question starts talking about availability requirements or regional restrictions, that’s usually a very strong clue about the Azure service or feature they want you to pick.

Region pairs are Microsoft-defined regional relationships used in geo-redundancy and recovery design. In most cases, region pairs sit within the same geography, but honestly, for AZ-900, the idea behind them matters a lot more than memorizing the actual pair names. Availability Zones are physically separate locations within a region, with independent power, cooling, and networking. That separation gives you a lot more protection if one datacenter in the region runs into trouble. Availability Sets are different: they distribute virtual machines across fault domains and update domains within an Azure datacenter deployment to reduce the impact of host failures and planned maintenance. They improve VM availability, but they do not protect against a full datacenter-level or regional outage.

Azure Resource Manager, or ARM, is the control plane for deploying and managing Azure resources. ARM gives you consistent deployments, tagging, RBAC, policy enforcement, and infrastructure as code — which is really useful when you’re trying to keep everything tidy, repeatable, and under control. At a fundamentals level, know that ARM deployments can be defined declaratively using ARM templates or Bicep. The control plane is for managing resources, while the data plane is where you actually use the service itself — like reading blobs from storage or querying a database.

The hierarchy is: Management groups → Subscriptions → Resource groups → Resources. Management groups help govern multiple subscriptions. Subscriptions are billing, quota, and access boundaries. Resource groups are logical containers for related resources. Resources are the actual services, like a VM, VNet, or storage account.

Scope Purpose Common Use Exam Trap
Management Group Govern multiple subscriptions Apply policy across business units Not used for billing
Subscription Billing, quota, access boundary Separate prod/non-prod or departments Not just a folder for apps
Resource Group Logical container for related resources App components managed together Not a billing boundary
Resource Actual Azure service instance VM, storage account, database Lowest scope, not governance-wide

In practice, an organization might use a top-level management group for the company, child management groups for Production and NonProduction, separate subscriptions for Finance, Retail, and Shared Services, and resource groups per application or environment. That is the sort of structure behind many landing zone designs, even if AZ-900 only expects recognition-level understanding.

High availability is about keeping services running even when smaller, local failures happen. Disaster recovery is about getting services back on their feet after a major outage, and quite often that means failing over to another region. Business continuity is the bigger picture — it’s the plan for keeping the organisation running when disruption hits, even if things get a bit messy for a while. Region choice, resilience features, and redundancy options all feed into that plan, so yeah, they all matter quite a bit.

3. Azure Compute Services

Compute is where service selection becomes very visible. Azure gives you a spectrum from infrastructure-heavy to highly managed. The exam is not testing whether you can build a cluster from scratch; it is testing whether you can map a workload to the right compute model.

Azure Virtual Machines are IaaS. You pick the image, size, disks, network settings, and availability option, and then you’re responsible for the guest OS, patching approach, and whatever software you install on top. VMs are a strong fit for lift-and-shift migrations, legacy software, custom agents, or anything that needs full operating system control. And of course, they usually sit alongside other services like VNets, NICs, NSGs, managed disks, backup, and monitoring — the usual supporting cast, really.

Virtual Machine Scale Sets are used when you need many identical VMs that can scale in or out, often behind a load balancer. They are common for stateless front-end tiers.

Azure App Service is a managed platform for hosting web apps, APIs, and related web workloads. You deploy code rather than managing servers. At awareness level, it’s worth knowing the basics of App Service Plans, autoscaling, deployment slots, custom domains, and SSL support. If the requirement says something like “host a web app with minimal infrastructure management,” I’d usually reach for App Service first.

Azure Functions is for event-driven, serverless code execution. Functions can be triggered by all sorts of things like HTTP requests, queue messages, timers, or blob events. Depending on the hosting plan, they can scale automatically and may use consumption-based billing, which is pretty appealing for bursty workloads. If the question says “run code when something happens,” Functions should be high on your list.

Azure Container Instances runs containers without you managing VMs or Kubernetes. It’s really handy for simple, isolated container workloads, batch jobs, or just getting something deployed quickly without a lot of fuss. Azure Kubernetes Service manages the Kubernetes control plane for you, but you still manage node pools, workloads, networking choices, and cluster configuration. AKS is the right choice when you need orchestrated containerised applications, especially if you’re working with microservices.

Azure Container Apps may also appear in current fundamentals coverage. At awareness level, think of it as a managed platform for running containerised apps without dealing with Kubernetes directly — sort of sitting between simple container execution and full Kubernetes orchestration.

Azure Virtual Desktop provides virtual desktops and remote apps from Azure. It is not just “remote desktop in the cloud.” It brings in concepts like workspaces, host pools, app groups, and session hosts. Depending on the design, customers may still manage the session host VMs and user profile handling, often with FSLogix in the mix.

Service Best Fit Management Level Key Clue
Virtual Machines Legacy apps, custom OS control More customer-managed Lift-and-shift, full control
VM Scale Sets Identical scalable VM fleets IaaS with autoscaling Many matching VMs
App Service Web apps and APIs Managed PaaS Host website without server admin
Functions Event-driven code Serverless Trigger-based execution
ACI Simple container execution Managed container runtime No orchestration needed
AKS Container orchestration Managed control plane Kubernetes, microservices
Azure Virtual Desktop Virtual desktops and remote apps Managed service with customer components Desktop delivery

A practical VM deployment usually involves choosing an image, a size, an OS disk type, a VNet/subnet, an NSG, and an availability option such as Availability Set or Zone if supported. A practical App Service deployment usually involves selecting a runtime, App Service Plan, region, scaling settings, and a deployment method. Even at AZ-900 level, it helps to understand that PaaS reduces operational burden but also reduces low-level control.

Scalability means handling more load by adding resources. Elasticity means adjusting resources up and down as demand changes. Functions, App Service, and some container platforms are often more elastic than traditional VMs.

4. Azure Networking Services

Networking in Azure starts with the Virtual Network, or VNet, which is your private network boundary in Azure. Inside a VNet, you create subnets to segment workloads by tier, purpose, or security needs. Good subnet planning matters because many services integrate with VNets, and some need dedicated subnet design.

Network Security Groups, or NSGs, filter inbound and outbound traffic using allow and deny rules applied to subnets or network interfaces. They are stateful, so return traffic for an allowed flow is handled automatically. A classic example is allowing HTTPS into a web subnet while locking down database traffic so only the application subnet can reach it.

VNet peering connects VNets privately over the Azure backbone. That’s useful when separate applications or environments need to talk to each other privately without sending traffic over the public internet.

For traffic distribution, keep the layers clear. Azure Load Balancer is a regional Layer 4 load balancer for TCP and UDP traffic. It uses backend pools and health probes and is a good fit for non-HTTP workloads or simple VM traffic distribution. Application Gateway is a regional Layer 7 web traffic load balancer for HTTP and HTTPS. It supports listeners, routing rules, SSL termination, URL-based routing, and a Web Application Firewall capability. Azure Front Door is a global Layer 7 entry point for web applications. It gives you global routing, application acceleration, SSL offload, health-based failover, and WAF integration. Azure CDN is primarily about caching and delivering static or cacheable content closer to users. Front Door and CDN both improve performance, but they do different jobs, so you really can’t treat them as interchangeable.

Service Scope Layer Best Fit
Load Balancer Regional Layer 4 TCP/UDP balancing for VMs
Application Gateway Regional Layer 7 Web traffic routing, WAF
Front Door Global Layer 7 Global web entry point and failover
CDN Global edge Content delivery Static content caching

VPN Gateway provides encrypted connectivity over the public internet. Common connection types include site-to-site, point-to-site, and VNet-to-VNet connections. ExpressRoute provides private dedicated connectivity between on-premises environments and Azure, often using a connectivity provider and BGP routing. VPN Gateway is usually faster to adopt and lower cost. ExpressRoute is typically chosen for private, predictable, enterprise-grade connectivity.

Azure DNS is a hosting service for DNS domains and records on Azure infrastructure. It is not a traffic acceleration service and not the same thing as internal VNet name resolution. Azure Private DNS is used for private DNS zones, especially with private networking scenarios.

Many Azure services can be exposed publicly or privately. Private Link and Private Endpoints let you access supported Azure services over a private IP inside your VNet rather than through a public endpoint. That is a major security and networking design concept, even at fundamentals level.

At awareness level, also know Azure Bastion for secure browser-based RDP/SSH without exposing VM public IPs, Azure Firewall for centralized network filtering, and DDoS Protection for enhanced protection against distributed denial-of-service attacks.

5. Azure Storage Services

Azure storage starts with the storage account, which is the top-level namespace for several storage services. The core services you’ll usually hear about are Blob Storage, Azure Files, Queue Storage, and Table Storage. For VMs, you also need to know Managed Disks.

Blob Storage is object storage for unstructured data such as images, logs, backups, and media files. Azure Data Lake Storage Gen2 builds on Blob Storage and adds hierarchical namespace capabilities for analytics workloads. Azure Files provides managed file shares using SMB and, in supported cases, NFS. Queue Storage is a simple message queue service for asynchronous communication between application components. For richer enterprise messaging patterns, Azure Service Bus exists, but Queue Storage is the simpler storage-based option. Table Storage is a NoSQL key/attribute store using entities and properties, not a relational database. Managed Disks provide persistent block storage for VM OS and data disks.

Service Access Pattern Best Fit
Blob Storage Object access Backups, media, logs, documents
Azure Files File share Shared SMB/NFS access
Queue Storage Message queue Basic asynchronous messaging
Table Storage NoSQL entity store Simple schema-less structured data
Managed Disks Block storage VM operating system and data disks

Blob Storage and Azure Files are frequently confused. Blob is object storage, not a mounted shared file system. Azure Files is the right answer when the requirement is “shared file access.” Managed Disks are different again: they are for VM-attached storage, not general object or file storage.

Storage accounts also involve configuration choices such as standard versus premium performance, replication, access tier, secure transfer, and network access rules. Blob data can use Hot, Cool, and Archive access tiers. Hot is for frequently accessed data, Cool for less frequent access, and Archive for long-term retention with slower retrieval. Lifecycle management policies can move data between tiers automatically.

For redundancy, use precise wording. LRS stores multiple synchronous copies in a single physical location in the primary region. ZRS stores copies across availability zones in the primary region. GRS replicates data asynchronously to a secondary region. GZRS combines zone redundancy in the primary region with asynchronous geo-replication to a secondary region. RA-GRS and RA-GZRS add read access to the secondary region. Standard GRS and GZRS do not provide direct read access to the secondary unless failover occurs.

Redundancy Primary Protection Secondary Read Access
LRS Single location in primary region No
ZRS Multiple zones in primary region No
GRS Primary region plus secondary region No
RA-GRS Primary plus secondary region Yes
GZRS Zones in primary plus secondary region No
RA-GZRS Zones in primary plus secondary region Yes

Security basics matter here too: Azure Storage supports encryption at rest, shared access signatures for delegated access, firewall rules, and private endpoints for private connectivity. Soft delete, snapshots, and versioning are also common data protection concepts to recognize.

6. Azure Database Services

Database selection in AZ-900 is mostly about workload pattern. Relational databases are typically chosen for structured transactional workloads with defined relationships. NoSQL databases are often chosen for flexible data models, global distribution, or very low-latency access patterns. Neither is universally better; the workload determines the fit.

Azure SQL Database is a fully managed PaaS relational database based on SQL Server technology. It is commonly used for transactional business applications. Azure SQL Managed Instance is also a managed SQL service, but with broader SQL Server compatibility for applications that need more instance-level features. SQL Server on Azure Virtual Machines gives you the most control but also the most management responsibility. For exam purposes, the key distinction is PaaS versus IaaS and compatibility needs.

Azure Database for MySQL and Azure Database for PostgreSQL are managed open-source relational database services. They are the natural fit when the application already depends on those engines.

Azure Cosmos DB is a globally distributed NoSQL database designed for low-latency applications. It supports multiple APIs and data models, including SQL/Core, MongoDB, Cassandra, Gremlin, and Table APIs. At awareness level, know that Cosmos DB uses concepts such as partition keys, consistency levels, and throughput measured in RU/s.

Service Type Best Fit
Azure SQL Database Managed relational PaaS Transactional apps with minimal database admin
Azure SQL Managed Instance Managed relational with broader compatibility SQL migrations needing more SQL Server features
SQL Server on Azure VM IaaS relational Full OS and SQL control
Azure Database for MySQL/PostgreSQL Managed open-source relational Existing MySQL or PostgreSQL workloads
Azure Cosmos DB Managed NoSQL Global low-latency modern apps

Azure SQL Database commonly appears in exam questions about structured relational data, backups, patching reduction, and managed scalability. Cosmos DB appears when the clues are global distribution, NoSQL, low latency, or multi-region application design. If a question says an application already uses PostgreSQL, do not force Azure SQL Database just because the name is more familiar.

7. Identity, Access, Security, and Governance Basics

Microsoft Entra ID, formerly Azure Active Directory, is Azure’s cloud-based identity and access management service. It handles users, groups, applications, authentication, and sign-in. Authentication asks, “Who are you?” Authorization asks, “What are you allowed to do?”

Azure RBAC controls access to Azure resources. Entra ID provides the identity; RBAC provides permissions at scopes such as management group, subscription, resource group, or resource. Access assignments inherit downward, so a role assigned at subscription scope applies to resource groups and resources inside that subscription unless restricted by other controls.

Conditional Access evaluates signals such as user, location, device state, application, and risk, then enforces controls such as MFA, block, or session restrictions. MFA is one of the most important basic security controls to recognize for AZ-900.

Managed identities are also worth knowing at awareness level. They allow Azure resources such as VMs or App Services to authenticate to other Azure services without storing credentials in code.

Governance goes beyond the hierarchy. Azure Policy can enforce rules such as allowed regions, required tags, or permitted SKUs. Resource locks can prevent accidental deletion or modification. Tags help with organization, automation, and cost tracking. In a practical scenario, an operations team might receive the Virtual Machine Contributor role only on a production resource group, while Policy enforces tagging and allowed VM sizes across the subscription. That is least privilege plus governance working together.

At a broader level, this all supports Zero Trust ideas: verify explicitly, use least privilege, and assume breach. AZ-900 stays high level, but those principles sit behind Entra ID, RBAC, MFA, Conditional Access, and Policy.

8. Monitoring and Management Tools

Azure can be managed through the Azure Portal, Azure CLI, Azure PowerShell, and Azure Cloud Shell. Portal is ideal for learning and interactive tasks. CLI and PowerShell are better for repeatable automation. Cloud Shell gives you a browser-based shell environment and can use Azure Files for persistent storage.

A simple CLI example is:

az group create --name rg-demo --location uksouth

That creates a resource group and also reminds you that Azure operations can be scripted and repeated.

Azure Monitor is the core observability platform. It works with metrics, logs, alerts, and dashboards or workbooks. Log Analytics stores and queries log data. Application Insights provides application performance monitoring for web apps and services. Azure Advisor gives best-practice recommendations across reliability, security, performance, cost, and operational excellence. Azure Service Health gives a personalized view of Azure issues and maintenance affecting your subscriptions. Resource Health focuses on the health of a specific resource. Azure Status provides a broad public view of platform status information.

Service Purpose Key Distinction
Azure Monitor Metrics, logs, alerts, observability Tells you what is happening
Application Insights Application telemetry Focuses on app performance
Azure Advisor Recommendations Tells you what to improve
Service Health Subscription-impacting Azure issues Platform events affecting you
Resource Health Specific resource health state Resource-level view
Azure Status Broad Azure platform status information High-level public platform view

A good operational example is this: if a web app is slow, start with Azure Monitor and Application Insights. If Azure suggests rightsizing or shutting down underused resources, that is Advisor. If users report a regional Azure outage, check Service Health and Azure Status. Those distinctions show up often in exam questions.

9. Core Service Selection Framework

When a question feels crowded with service names, reduce it to a few checks:

  1. What is the workload? Web app, VM-based app, event-driven code, containerized service, desktop, database, or storage need.
  2. How much management is required? If full OS control is not required, prefer a more managed service.
  3. What kind of connectivity is needed? Public web access, private hybrid access, or internal-only communication.
  4. What kind of data is involved? Objects, files, relational data, NoSQL data, or messages.
  5. Are there constraints? Compliance, latency, global distribution, identity integration, or disaster recovery.

That framework helps you avoid choosing a familiar service instead of the correct one.

10. Real-World Azure Service Selection Scenarios

Requirement Best Fit
Move a legacy Windows app with minimal code changes Azure Virtual Machines
Host a web app without managing servers Azure App Service
Run code when a blob is uploaded or a queue message arrives Azure Functions
Run a few containers quickly without orchestration Azure Container Instances
Run containerized microservices with orchestration Azure Kubernetes Service
Provide remote desktops and remote apps to users Azure Virtual Desktop
Balance TCP traffic across VM instances in one region Azure Load Balancer
Route web traffic by URL path with WAF protection Application Gateway
Provide a global web entry point with failover and acceleration Azure Front Door
Provide private dedicated connectivity from on-premises to Azure ExpressRoute
Provide encrypted hybrid connectivity over the internet VPN Gateway
Store millions of images or backup files Blob Storage
Provide a shared file share across cloud and on-premises systems Azure Files
Deploy a managed relational database for an order-entry app Azure SQL Database
Build a globally distributed low-latency NoSQL app Azure Cosmos DB
Apply governance across multiple subscriptions Management Groups with Azure Policy

11. Troubleshooting and Diagnostic Basics

AZ-900 is not a deep troubleshooting exam, but Microsoft does expect you to recognize what tool or service category to check first.

VM connectivity issue: If you cannot reach a VM, check whether it has the right IP path, NSG rules, subnet routing, and whether the VM is healthy. If secure admin access is required without public IP exposure, Azure Bastion may be the better design.

Web app unavailable: Check DNS resolution, App Service configuration, deployment status, and Azure Monitor metrics. If the requirement is global failover or web routing, consider whether Front Door or Application Gateway is in the path.

Storage access denied: Check whether the issue is authentication, RBAC, storage account firewall settings, private endpoint use, or SAS/key configuration.

Authentication failure: Decide whether the problem is identity, authorization, or policy. Entra ID handles sign-in. RBAC controls resource permissions. Conditional Access and MFA may block or challenge access based on policy signals.

Azure outage question: Use Service Health for subscription-specific Azure issues, Resource Health for a particular resource, and Azure Status for the broad public view.

12. Top Exam Traps and Memory Anchors

Comparison Memory Anchor
Availability Zones vs Availability Sets Zones = physical separation in a region; Sets = fault/update domain distribution for VMs
Management Groups vs Subscriptions vs Resource Groups Govern many, bill one, organize related resources
VMs vs App Service Need OS control? VM. Need managed web hosting? App Service
App Service vs Functions Host app/API vs run trigger-based code
ACI vs AKS Simple container vs orchestrated containers
Load Balancer vs Application Gateway vs Front Door L4 regional, L7 regional web, L7 global web
VPN Gateway vs ExpressRoute Encrypted internet tunnel vs private dedicated connection
Blob vs Files vs Managed Disks Objects, shares, VM disks
Azure SQL Database vs Cosmos DB Relational transactions vs globally distributed NoSQL
Monitor vs Advisor vs Service Health Observe, improve, platform issues

Also watch for Microsoft-style clue phrases: full control, minimize management, event-driven, globally distributed, shared file access, private connectivity, and govern across subscriptions. Those phrases usually narrow the answer quickly.

13. Final Exam Guidance

For AZ-900, do not try to memorize every feature of every Azure product. Learn the service families, the common comparisons, and the clue words that point to the right answer. Read the requirement first, identify the workload type, then eliminate options that require more management or solve a different problem.

If you want a simple review order, use this: architecture, compute, networking, storage, databases, identity, governance, and monitoring. If you can explain what a service is, what problem it solves, what it is commonly confused with, and why another option is weaker, you are in strong shape for the exam.

One final note: Microsoft updates exam objectives over time, so always compare your study notes with the current AZ-900 skills outline. But the core selection mindset stays the same: understand the requirement, choose the most managed service that still satisfies it, and pay attention to scope, connectivity, data type, and security constraints.