Microsoft Azure Fundamentals AZ-900: Core Azure Services Explained
Introduction
Core Azure services are basically the foundation blocks for most Azure solutions, and they’re a big deal in AZ-900. The exam isn’t really about memorizing every little feature. It’s more about knowing what a service does, when you’d use it, and what people often mix it up with. If you can tell apart services like Virtual Machines and App Service, Load Balancer and Application Gateway, or Blob Storage and Azure Files, you’ll be able to answer a lot of questions by reasoning it out instead of just taking a guess.
At a big-picture level, Azure really comes down to a handful of main service families: compute, networking, storage, databases, identity, security, and management. And honestly, in real-world solutions, these services almost never show up alone — they usually work together as part of one bigger design. An app runs on compute, uses networking, stores data, authenticates through Microsoft Entra ID, and gets watched with Azure monitoring tools. Once you start thinking of Azure as connected service categories instead of one giant product catalog, it gets a whole lot easier to make sense of.
Azure Infrastructure, Organization, and Governance Basics
Azure runs in geographies, which contain regions. A region isn’t just some random cluster of datacenters. It’s a group of datacenters placed within a specific geographic area where latency matters. Honestly, picking a region is a lot more than just pointing at a spot on the map. It can change your latency, where your data lives, what compliance rules you’ve got to follow, how much you’ll pay, and sometimes even which services are available to you. Availability Zones are physically separate locations within some regions, each with independent power, cooling, and networking. Zones help with high availability inside a region.
Region pairs support platform resiliency and some replication scenarios, but they do not automatically fail over every workload. Disaster recovery still comes down to the service you’re using and how you set up replication, backup, and failover. That distinction matters for AZ-900: region pairs support resilience planning, but your application architecture determines actual recovery behavior.
Azure also has an organizational hierarchy: Tenant → Management Group → Subscription → Resource Group → Resource. A tenant is your Microsoft Entra ID directory boundary. Management groups organize multiple subscriptions for governance. A subscription is mainly a billing and access boundary. A resource group is basically a neat little folder for resources that belong together. These layers are mainly about organization, governance, RBAC scope, and billing. They don’t create availability by themselves.
For example, a company might place all production subscriptions under one management group, assign a policy requiring tags like Environment=Prod, and grant Reader access at the subscription level while granting Contributor access only to a specific resource group. That is classic Azure governance.
ARM, Control Plane, RBAC, and Policy
Azure Resource Manager, or ARM, is Azure’s deployment and management service. It is commonly described as the control plane: creating a VM, updating a storage account, or deleting a resource group are ARM operations. By contrast, data plane operations are service-specific actions such as reading blob data, querying a database, or pulling messages from a queue.
ARM works with resource providers such as Microsoft.Compute or Microsoft.Storage. It also supports declarative deployment through ARM templates and Bicep, which is Microsoft’s recommended authoring experience for ARM-based infrastructure as code. For AZ-900, know the idea: define the desired state, and Azure deploys it consistently.
Governance is bigger than ARM by itself. Azure RBAC controls who can do what on Azure resources, using roles like Owner, Contributor, and Reader. Azure Policy evaluates and can enforce rules, such as allowing only certain regions or requiring encryption settings. Resource locks help prevent accidental deletion or modification. Tags support cost tracking and organization.
Deleting a resource group usually deletes the resources inside it, but not always as neatly as beginners assume. Locks, dependencies, provider behavior, or soft-delete features can affect the result. So the safe exam idea is: resource groups support lifecycle management, but outcomes can depend on configuration.
A few management examples:
az account showaz group create --name az900-rg --location eastusaz storage account list --output table
Those are ARM management actions, not data access actions.
Azure Compute Services
Compute is where workloads run. The easiest way to choose compute on AZ-900 is to ask: how much do you want Azure to manage versus how much control do you need?
| Service | Best Fit | You Manage | Azure Manages |
|---|---|---|---|
| Virtual Machines | Legacy apps, full OS control | OS, patching, runtime, much of security config | Physical infrastructure |
| VM Scale Sets | Many identical VMs with scaling | VM image and guest OS management | Scaling framework and orchestration of instances |
| App Service | Web apps, APIs, web jobs | Application code and app settings | Platform, OS, much runtime management |
| Functions | Event-driven code | Function code and triggers | Server management and scale behavior by plan |
| ACI | Simple container execution | Container image | Underlying host infrastructure |
| AKS | Container orchestration at scale | Pods, workloads, node pools, cluster ops | Kubernetes control plane management |
Azure Virtual Machines are the closest match to traditional servers. You choose the image, size, disks, network interface, and availability option. Real deployments usually need a VNet or subnet, NIC, NSG, managed disks, and monitoring. For resilience, Azure supports availability sets and availability zones. Availability sets spread VMs across fault and update domains within a datacenter environment; zones spread them across separate physical locations in a region.
VM Scale Sets are for groups of identical VMs that scale in or out. They’re common behind a load balancer and can autoscale based on CPU, memory, or schedule.
Azure App Service is managed hosting for web apps and APIs. It uses an App Service plan that defines pricing tier, scale, and underlying compute. A few exam-friendly features I’d definitely keep in mind are custom domains, SSL/TLS, deployment slots, built-in authentication options, and VNet integration in some scenarios. If you see a question that says, 'host a web app without managing servers,' App Service is usually the first thing that should pop into your head. That’s the classic clue.
Azure Functions is serverless, event-driven compute. Common triggers include HTTP, timer, blob, and queue events. Functions are ideal for automation and background processing. It is fair to think “small event-driven tasks,” but that should not be overstated: different hosting plans and Durable Functions support more advanced and longer-running workflows.
Azure Container Instances runs containers without you managing VMs or Kubernetes. It’s not just for quick jobs either — it can also run containers that stay up for a while. The big thing to remember is that it’s simple and doesn’t involve orchestration. AKS, on the other hand, is managed Kubernetes. Azure takes care of the control plane, but you’re still responsible for the workloads, manifests, networking decisions, scaling behavior, and node pools. AKS is powerful, but it is not “hands-off.”
Azure Virtual Desktop is for delivering desktops and remote apps to users. In real deployments, Azure Virtual Desktop usually has a few pieces working together — session host VMs, host pools, workspaces, application groups, and profile tools like FSLogix. Once you’ve seen it a few times, the whole setup usually starts to make sense pretty quickly. For AZ-900, the main thing to remember is simple: if users need a managed desktop or remote app experience, Azure Virtual Desktop is a much better fit than a regular VM.
Azure Networking Services
Azure Virtual Network is the private networking foundation for many Azure solutions. You define an address space and create subnets to separate tiers like web, app, and database. Not every Azure service must be deployed into your own VNet, though. A lot of PaaS services don’t need to live inside your own VNet right away, and you can still connect them privately later if the design calls for it.
Core network security starts with Network Security Groups (NSGs), which filter traffic to subnets or NICs using allow/deny rules. VNet peering privately connects VNets. Private Endpoints let PaaS services such as Storage or SQL be accessed through private IPs in your VNet. That is often more secure than exposing public endpoints. Public-facing workloads may also use public IP addresses, while private-only workloads stay internal.
| Service | Use It For | Key Distinction |
|---|---|---|
| Load Balancer | TCP/UDP traffic distribution | Layer 4, public or internal, inbound and outbound scenarios |
| Application Gateway | HTTP/HTTPS routing | Layer 7, path-based routing, often with WAF |
| Front Door | Global web entry point | Global Layer 7 routing, acceleration, optional WAF |
Load Balancer is for Layer 4 traffic and uses backend pools, rules, and health probes. Application Gateway understands web traffic and is commonly used when you need path-based routing, TLS termination, or a Web Application Firewall. Front Door is a global Layer 7 entry point for web apps. It does more than a basic CDN and is often used for global routing and performance acceleration. CDN focuses on caching and content delivery at the edge; some real-world scenarios overlap with Front Door, so read exam wording carefully.
For hybrid connectivity, VPN Gateway provides encrypted connectivity over the public internet, while ExpressRoute provides a private dedicated connection path to Azure. A good exam memory cue is this: with ExpressRoute, the private connection path doesn’t go over the public internet. If the requirement says “dedicated private connection,” choose ExpressRoute. If it says “secure connection over the internet,” choose VPN Gateway.
Azure DNS hosts public DNS zones and records. Azure Private DNS supports private name resolution inside VNets. That distinction is often missed by beginners.
Azure Storage Services
Azure storage starts with a storage account, which can contain services such as blobs, files, queues, and tables. By default, storage accounts encrypt data at rest, which basically means the data is protected while it’s just sitting there in storage. And if you want to lock things down even more, you can add firewalls, RBAC, shared access signatures, or private endpoints.
| Storage Type | Best Fit |
|---|---|
| Blob Storage | Unstructured object data like backups, media, logs |
| Azure Files | Managed file shares over SMB or NFS |
| Managed Disks | OS and data disks for VMs |
| Queue Storage | Basic asynchronous messaging |
| Table Storage | It’s a flexible NoSQL store that organizes data with keys and attributes, usually with fields like PartitionKey and RowKey. That makes it a solid fit for simple, scalable data patterns without the overhead that comes with a full relational database. |
Blob Storage supports hot, cool, and archive tiers, plus lifecycle management, versioning, and soft delete. Azure Files is for shared file access and hybrid file scenarios. Managed Disks come in performance tiers such as Standard HDD, Standard SSD, and Premium SSD. Queue Storage is basic messaging for decoupling components; if a question hints at advanced enterprise messaging features, that is where services like Service Bus differ. Table Storage is not a relational database and not just a simple key-value store; it is a schema-flexible NoSQL key/attribute store.
Storage redundancy is highly testable:
| Option | Meaning |
|---|---|
| LRS | Copies within a single physical location in the primary region |
| ZRS | Copies across availability zones in the primary region |
| GRS | Synchronous local copies plus asynchronous replication to a secondary region |
| RA-GRS | GRS plus read access to the secondary region |
| GZRS | ZRS in the primary region plus asynchronous geo-replication |
| RA-GZRS | GZRS plus read access to the secondary region |
High-yield memory aid: Object = Blob, File share = Azure Files, VM disk = Managed Disk.
Azure Database Services
For databases, first decide whether the workload is relational or NoSQL. Relational databases use structured tables and define relationships between different pieces of data, which is why they feel so familiar to most IT folks. That’s the classic database model most people picture right away. NoSQL services are usually more flexible, and they’re often built to scale out instead of only scaling up. That makes them a strong fit when your data shape or traffic pattern isn’t very rigid.
Azure SQL Database is a managed relational database for common application workloads. SQL Managed Instance offers higher SQL Server compatibility and more instance-level features, and it is deployed into a virtual network. SQL Server on Azure VMs is the choice when you need full OS and SQL Server control. Azure Database for MySQL and Azure Database for PostgreSQL are managed services for apps built on those engines. Azure Cosmos DB is a globally distributed NoSQL database with multiple APIs and models, including SQL, MongoDB, Cassandra, Gremlin, and Table.
If the requirement says, 'managed relational database for a typical app,' Azure SQL Database is usually the first service I’d reach for. It’s the cleanest answer in a lot of beginner-level scenarios. If it says “legacy SQL Server compatibility,” think SQL Managed Instance. If it says “global distribution, flexible schema, low latency,” think Cosmos DB.
Identity, Security, Monitoring, and Operations
Microsoft Entra ID provides identities for users, groups, applications, and managed identities. It supports authentication, single sign-on, MFA, Conditional Access, and identities for applications. A key distinction: Entra ID provides the identity system, while Azure RBAC authorizes access to Azure resources.
Managed identities are especially useful for Azure services. For example, an App Service app can use a managed identity to access Key Vault or Storage without hardcoding secrets into the application. That’s a cleaner approach, and honestly, it’s a lot safer too.
Microsoft Defender for Cloud helps with security posture, recommendations, and threat protection. For AZ-900, know it as a core cloud security management service.
Azure Monitor collects metrics and logs. Log Analytics stores and queries log data. Application Insights focuses on app telemetry. Alerts notify you when thresholds or conditions are met. Azure Advisor gives recommendations across reliability, cost, security, and performance. Azure Service Health shows personalized Azure issues affecting your resources, while Azure Status provides broad platform status information.
| Need | Service |
|---|---|
| Who can sign in? | Microsoft Entra ID |
| Who can manage this resource? | Azure RBAC |
| Enforce governance rules | Azure Policy |
| Security recommendations | Defender for Cloud / Advisor |
| Metrics, logs, alerts | Azure Monitor |
| Microsoft outage affecting me | Service Health |
A Real-World End-to-End Example and Common Troubleshooting Patterns
A simple Azure architecture might use Front Door or Application Gateway for web entry, App Service for the application, Azure SQL Database for relational data, Blob Storage for images, Entra ID for authentication, and Azure Monitor for telemetry. That one example covers compute, networking, storage, databases, identity, and operations all at once.
Common troubleshooting patterns are also exam-relevant. If users can’t sign in, start by checking Entra ID, MFA, Conditional Access, and RBAC. If the app is slow but Azure itself looks healthy, check Azure Monitor and Application Insights.on Insights. If a storage account is unreachable, check firewall rules, private endpoints, DNS, and whether public access is disabled. If web traffic is not routing correctly, review DNS, Front Door or Application Gateway configuration, backend health probes, and NSG rules. If the question asks whether Microsoft is having an outage, think Service Health or Azure Status, not Monitor.
AZ-900 High-Yield Service Selection and Exam Tips
Most tested distinctions: Region vs Availability Zone; Resource Group vs Subscription; VM vs App Service vs Functions; Load Balancer vs Application Gateway; VPN Gateway vs ExpressRoute; Blob vs Files vs Disk; SQL Database vs Cosmos DB; Service Health vs Monitor vs Advisor.
Best-fit keywords: “legacy app” = VM; “web app without server management” = App Service; “event-driven” = Functions; “single/simple container” = ACI; “container orchestration” = AKS; “shared file share” = Azure Files; “object storage” = Blob; “private dedicated connection” = ExpressRoute; “global NoSQL” = Cosmos DB.
Exam checklist: identify the workload type, look for trigger words, decide whether the requirement is self-managed or managed, eliminate overengineered answers, and choose the most managed service that still meets the requirement. “Most advanced” is not the same as “best.” Also remember that “private” does not automatically mean ExpressRoute; if the requirement is simply encrypted internet-based connectivity, VPN Gateway fits.
You do not need deep Kubernetes administration, ARM/Bicep syntax memorization, advanced routing design, or SQL tuning internals for AZ-900. You do need strong recognition, accurate comparisons, and the ability to pick the best-fit service from a short scenario.