Microsoft Azure Fundamentals AZ-900: Understanding Core Azure Services

1. Introduction: What “Core Azure Services” Really Means for AZ-900

If you’re preparing for AZ-900, honestly, the toughest part usually isn’t memorizing the definitions. It’s figuring out which services sound alike on paper but do different jobs in practice. That’s the real exam skill. AZ-900 is not asking you to build production Kubernetes clusters or tune databases at 2 a.m. It’s testing service literacy: what problem a service solves, what cloud model it fits, and which option is the simplest valid answer in a scenario.

The simplest way I’ve found to keep Azure straight is to break it into a handful of buckets: infrastructure and architecture, compute, networking, storage, data, identity and governance, and monitoring. And here’s one exam rule that’s easy to overlook: not every Azure service is available in every region, and pricing can shift depending on the region, performance tier, redundancy option, and consumption model. So anyway, choosing an Azure service isn’t just about checking off features on a list. It’s also about where the service is available, how much resilience you actually need, whether compliance comes into play, and what the cost is going to look like.

2. Azure Infrastructure, Hierarchy, and the Management Plane

An Azure region is a geographic area containing at least one datacenter. It is the broad location where resources run. You usually pick a region based on latency, compliance requirements, disaster recovery planning, and whether the service you want is actually offered there. Not every service or SKU shows up in every region, and that’s a pretty common exam clue.

Availability Zones are physically separate locations within a region, each with independent power, cooling, and networking. A zone is not just “one datacenter.” For AZ-900, the important point is that zones improve high availability inside a single region. If a scenario asks for fault tolerance within one region, think zones or zone-redundant services.

Region pairs matter for resilience planning. Most Azure regions are paired with another region in the same geography, although there are exceptions. Paired regions influence some platform recovery behaviors and some geo-redundant services, but they do not automatically fail over your applications. Customer failover still depends on service capabilities and your architecture.

Azure is also organized logically. The hierarchy is:

Management group → Subscription → Resource group → Resource

A management group helps govern multiple subscriptions and can be nested. A subscription is a billing, access, deployment, and quota boundary. A resource group is a management scope for related resources; it is useful for organization, RBAC, policy, and lifecycle operations, even though resources in the same group do not always have identical lifecycles.

Azure Resource Manager (ARM) is Azure’s management plane. The portal, Azure CLI, PowerShell, and APIs all work through ARM. ARM handles deployment, updates, tags, RBAC, and policy at the resource level. This is different from the data plane, which is how you interact with the service data itself. So, if you’re creating a storage account, that’s a management-plane change. You’re telling Azure what you want through ARM, and ARM is really the control layer working quietly behind the scenes. But when you upload a blob into a container, that’s a data-plane operation. In other words, you’re using the service to handle the actual data, not just set up the resource around it. ARM also supports declarative deployments through ARM templates, and Bicep is the newer Microsoft-recommended authoring experience built on ARM.

3. Core Azure Compute Services

Compute choices mostly come down to one question: how much control do you need versus how much management do you want Azure to take off your hands?

Azure Virtual Machines are IaaS. If a scenario needs full OS control, custom software installs, or a pretty straightforward lift-and-shift from on-premises, Virtual Machines are usually the right fit. That’s the classic VM use case. You’re still on the hook for the guest OS, patching, configuration, and the application stack. Azure does take some work off your plate with things like managed disks, monitoring integration, backup options, and some automated patching features, but it’s definitely not a hands-off service. For AZ-900, remember: OS-level control = VM.

Virtual Machine Scale Sets extend that model by letting you run and autoscale a set of load-balanced VMs. They are commonly used for stateless workloads that need horizontal scaling. “Identical” is directionally true for the exam, but the better mental model is a coordinated fleet of VMs that can scale and be updated together.

Azure App Service is PaaS for hosting web apps, API apps, and related workloads such as WebJobs. This is the managed choice when you want to deploy application code and avoid messing with the underlying OS. It supports custom domains, TLS/SSL, autoscaling depending on the plan, and deployment slots, which are honestly really useful when you want safer releases. The key concept many beginners miss is the App Service Plan, which defines the compute resources behind the app. If the requirement is “host a website or API with less operational overhead,” App Service is the usual fit.

Azure Functions is event-driven serverless compute. It is ideal for triggered execution such as HTTP triggers, timer triggers, blob triggers, or queue triggers. Functions can run on Consumption, Premium, or Dedicated hosting, so “serverless” does not mean the service never uses provisioned infrastructure in any form; it means the abstraction is event-driven and operationally reduced. If the question says “run code when something happens,” think Functions.

Azure Container Instances (ACI) lets you run containers without managing VMs or an orchestrator. It’s a really good fit for short-lived jobs, isolated workloads, bursty demand, or simple batch processing.

Azure Kubernetes Service (AKS) is managed Kubernetes. Azure handles the control plane, but you’re still on the hook for the workloads, node pools, networking choices, and day-to-day cluster operations. So it’s managed, but not magically managed. AKS makes sense when the scenario clearly needs orchestration features like self-healing, rolling updates, service discovery, or managing multiple containers as one coordinated platform. If you don’t need that, it’s probably more than you need.

A quick decision guide:

Need OS access? VM. Need a scalable VM fleet? VM Scale Sets. Need managed web/API hosting? App Service. Need triggered code? Functions. Need one container quickly? ACI. Need orchestrated containers? AKS.

4. Core Azure Networking Services

Networking questions are easier when you separate private networking, traffic filtering, hybrid connectivity, and application delivery.

Azure Virtual Network (VNet) is your private network boundary in Azure. It contains an address space and can be divided into subnets, which segment workloads such as web, app, and database tiers. In real environments, subnet planning matters because IP ranges, routing, and service delegation all depend on it, but for AZ-900 the main point is simple: VNet = private Azure network; subnet = segment inside it.

VNet peering connects VNets privately over the Azure backbone. This is a core concept when separate Azure networks need to communicate without going over the public internet.

Network Security Groups (NSGs) filter traffic with allow and deny rules based on source, destination, port, protocol, and priority. They can be associated with subnets or network interfaces. NSGs are not the same as Azure Firewall; think of them as basic network traffic filtering controls.

Azure Firewall is a managed network security service for more centralized and advanced traffic control. Web Application Firewall (WAF) protects web applications at Layer 7 and is available with services such as Application Gateway WAF and Front Door WAF. Exam trap: NSG filters network traffic, Azure Firewall is a broader managed firewall service, and WAF is specifically for web application protection.

VPN Gateway provides encrypted connectivity over the public internet. That’s exactly why it fits site-to-site and point-to-site VPN scenarios so well. ExpressRoute provides private dedicated connectivity through a connectivity provider. If the scenario says “private dedicated connection,” choose ExpressRoute. If it says “secure tunnel over the internet,” choose VPN Gateway.

Private Link/private endpoints let Azure PaaS services be accessed through a private IP in your VNet, reducing public exposure. This is increasingly important in Azure networking and security questions. Pair it with Azure Private DNS when private name resolution is needed. By contrast, Azure DNS is a DNS hosting service for public and private DNS domains and records using Azure infrastructure; it is not a generic label for all DNS resolution in Azure.

Once you get into traffic distribution, beginners often start mixing these services up, so it’s worth keeping the distinctions straight:

Azure Load Balancer is a regional Layer 4 service for TCP/UDP traffic. It can handle both public and internal load balancing, and it’s useful for inbound and outbound scenarios.

Application Gateway is a regional Layer 7 load balancer for HTTP/HTTPS traffic, with features like URL-based routing and optional WAF capability.

Traffic Manager is DNS-based global traffic distribution. It is not a proxy in the request path.

Azure Front Door is a global Layer 7 entry point for HTTP/HTTPS applications with acceleration, routing, health probing, and optional WAF. It is more than “edge delivery”; it is a global application delivery service.

5. Core Azure Storage Services

The cleanest way to remember Azure storage is by data type. Also remember that a storage account is the parent resource that can provide services such as blobs, files, queues, and tables. Managed Disks are separate VM storage resources.

Blob Storage is object storage for unstructured data such as images, backups, logs, media, and documents. It supports access tiers like Hot, Cool, and Archive, which trade off access cost versus storage cost. Blob Storage also supports lifecycle management, static website hosting, and access controls such as private containers and shared access signatures.

Azure Files provides managed file shares using familiar file-sharing protocols such as SMB, and in some scenarios NFS. It is the right answer when multiple systems need a shared file share rather than object access.

Queue Storage is simple message queuing within Azure Storage, useful for decoupling producers and consumers. It is not the same as a full enterprise messaging service such as Service Bus.

Table Storage is a schemaless NoSQL key/attribute store using PartitionKey and RowKey. It is for simple structured nonrelational data, not relational SQL workloads.

Managed Disks provide block storage for Azure VMs. Think OS disks and data disks, with different performance tiers and snapshot capabilities.

Storage redundancy is extremely testable:

LRS replicates data synchronously three times within a single primary region in one physical location. ZRS replicates across availability zones in a region. GRS replicates to the paired region asynchronously. RA-GRS adds read access to the secondary endpoint at all times. GZRS combines zone redundancy in the primary region with geo-replication to the paired region. RA-GZRS adds read access to that secondary endpoint.

A practical memory aid: LRS = local low-cost durability, ZRS = zone resilience, GRS = regional disaster recovery, RA-* = readable secondary, GZRS = strongest combined zone + geo option in this list.

6. Azure Database and Data Platform Services

Database questions on AZ-900 are usually about choosing the right data model and management approach.

Azure SQL Database is a managed relational database service. It’s a good fit for structured data, SQL queries, and the kinds of patterns you’d expect in traditional business applications. Microsoft handles much of the patching, backups, and high availability behind the service.

Azure SQL Managed Instance is also a managed relational option, but it is designed for higher SQL Server compatibility than Azure SQL Database. For AZ-900, just know it exists as another managed SQL choice between a simple database service and running SQL Server on a VM.

Azure Database for MySQL and Azure Database for PostgreSQL are managed open-source relational database services. Current Azure positioning emphasizes the Flexible Server deployment model. For exam purposes, the cue is application compatibility: if the workload is built for MySQL or PostgreSQL, these are the managed relational options to consider.

Azure Cosmos DB is globally distributed NoSQL. It supports multiple APIs and data models, including SQL API and APIs compatible with MongoDB, Cassandra, Gremlin, and Table scenarios. It also offers multiple consistency levels, which is one reason it appears in globally distributed application designs. The simple exam distinction is still the most important one: structured relational data = SQL family; globally distributed flexible NoSQL = Cosmos DB.

7. Identity, Access, Governance, and Security Basics

Microsoft Entra ID, formerly Azure AD, is Microsoft’s cloud-based identity and access management service used across Azure, Microsoft 365, SaaS apps, and custom applications. It handles identities and authentication. Single Sign-On (SSO) improves usability by letting users sign in once for multiple applications. Multi-Factor Authentication (MFA) strengthens sign-in security. At awareness level, Conditional Access applies access decisions based on conditions such as user, device, location, or risk.

Azure RBAC handles authorization to Azure resources. Assignments can be made at management group, subscription, resource group, or resource scope, and permissions inherit downward. That inheritance is important. Identity answers “who are you?” RBAC answers “what can you do?”

Governance is broader than permissions. Azure Policy helps enforce or audit rules such as allowed regions, required tags, or permitted SKUs. Resource locks help prevent accidental deletion or modification. Tags support organization and cost reporting. These are common AZ-900 governance concepts and they are different from identity and RBAC.

A useful exam distinction: Entra ID = identity, RBAC = permissions, Policy = compliance rules, Locks = accidental change protection.

8. Monitoring and Management Tools

The Azure Portal, Azure CLI, PowerShell, and Cloud Shell are really just different ways of reaching the same ARM management plane. The interface changes, but underneath it all, you’re still working through the same control plane. The portal is visual, beginner-friendly, and honestly the easiest place to start when you're still learning your way around. CLI and PowerShell are better when you want automation, repeatability, or the ability to do the same thing consistently over and over. Cloud Shell gives you browser-based CLI or PowerShell without local installation. In practice, you usually authenticate first using the appropriate sign-in command for the selected tool.

Azure Monitor is the main observability platform. It works with metrics, logs, alerts, dashboards, and workbooks. Log Analytics is used for log collection and querying, and Application Insights focuses on application telemetry such as request rates, failures, and response times.

Azure Service Health gives personalized information about service issues, planned maintenance, and health advisories affecting your subscriptions and resources. This helps answer, “Is Azure having a platform problem?”

Azure Advisor gives recommendations in Reliability, Security, Performance, Operational Excellence, and Cost. This helps answer, “What should we improve?”

A simple troubleshooting flow: if users say the app is slow, check Azure Monitor and Application Insights. If multiple services look impacted in one region, check Service Health. If leadership asks how to reduce waste or improve architecture, check Advisor.

9. Practical Service Selection and Exam Traps

Here are the high-value comparisons that show up over and over:

VM vs App Service vs Functions: VM for OS control, App Service for managed web/API hosting, Functions for triggered execution.

ACI vs AKS: ACI for simple container runs, AKS for orchestration.

Blob vs Files vs Disks: Blob for objects, Files for shared file access, Disks for VMs.

VPN Gateway vs ExpressRoute: encrypted internet tunnel versus private dedicated connection.

Load Balancer vs Application Gateway vs Traffic Manager vs Front Door: Layer 4 regional, Layer 7 regional, DNS-based global, and Layer 7 global.

SQL Database vs Cosmos DB: relational versus globally distributed NoSQL.

Entra ID vs RBAC vs Policy: identity versus permissions versus governance rules.

Five fast exam-style scenarios:

1. “We need to host a web API and do not want to manage servers.” Use App Service, not VMs, because the requirement is managed hosting.

2. “We need secure connectivity from a branch office to Azure over the internet.” Use VPN Gateway, not ExpressRoute, because the scenario does not require a private dedicated circuit.

3. “We need a globally distributed NoSQL database with flexible schema.” Use Cosmos DB, not Azure SQL Database.

4. “We need to expose a web app globally with HTTP/HTTPS routing and optional WAF.” Use Front Door if the scenario is global, or Application Gateway if it is regional. That distinction matters.

5. “We need private access from a VNet to a PaaS service without using a public endpoint.” Think Private Link/private endpoint, often with Private DNS.

10. Quick Knowledge Drill

Match the requirement to the service:

OS control → Virtual Machines
Managed web app → App Service
Event-driven code → Functions
Single container job → ACI
Container orchestration → AKS
Private Azure network → VNet
Traffic filtering on subnet/NIC → NSG
Private dedicated hybrid link → ExpressRoute
Public DNS hosting → Azure DNS
Private access to PaaS → Private Endpoint
Object storage → Blob Storage
Shared file share → Azure Files
VM disk storage → Managed Disks
Relational managed database → Azure SQL Database
Globally distributed NoSQL → Cosmos DB
Identity → Entra ID
Permissions → RBAC
Enforced governance rules → Azure Policy
Prevent accidental deletion → Resource Lock
Platform outage information → Service Health
Optimization recommendations → Advisor

11. Conclusion

The AZ-900 version of Azure is really about clean distinctions. Regions and zones are about placement and resilience. ARM is the management plane. VMs give control, App Service reduces platform management, Functions are triggered, and AKS is for orchestration. VNets isolate networks, NSGs filter traffic, VPN Gateway and ExpressRoute solve different hybrid problems, and Front Door is not the same thing as Traffic Manager. Blob is objects, Files is shares, Disks are for VMs. SQL services are relational; Cosmos DB is globally distributed NoSQL. Entra ID handles identity, RBAC handles permissions, and Policy handles governance rules.

If you study by asking three questions for every service, you’ll be in good shape: What problem does it solve? What is the simplest correct use case? What tempting wrong answer is the exam trying to distract me with? That mindset is much more effective than memorizing product names in isolation.