AZ-900 Core Solutions and Management Tools on Azure

Why This AZ-900 Topic Really Matters

AZ-900’s really checking that you can see two sides of Azure clearly: what the platform actually gives you, and how you keep all of it managed, monitored, secured, and governed. That means understanding both core solutions such as compute, networking, storage, and databases, and management tools such as the portal, CLI, Azure Monitor, Azure Policy, and Cost Management.

The easiest mental model is this: solutions run the workload; tools operate the environment. If you can separate service categories from management categories, you’ll answer a large share of fundamentals questions correctly and build a much better real-world foundation.

Azure Scope, Hierarchy, and Global Infrastructure

Azure has two different structures that beginners often mix together:

• Management hierarchy: Microsoft Entra tenant > management groups > subscriptions > resource groups > resources
• Global infrastructure: regions, availability zones, and region pairs

And no, those aren’t the same thing at all. The management hierarchy is what drives governance, RBAC scope, policy inheritance, and how you keep costs organized. Regions and zones are about where your workloads actually run, and how much resilience you can build into them.

Management groups organize multiple subscriptions so policy and access can be applied consistently at scale. Subscriptions are billing, quota, and governance boundaries. Resource groups are logical containers for resources. Resources are the actual service instances, such as a VM, storage account, or virtual network.

Important AZ-900-safe facts:

• A resource group belongs to one subscription.
• A resource can only live in one resource group at a time — that one trips people up a lot.
• And just because resources are in the same resource group doesn’t mean they have to be in the same region.
• RBAC can be assigned at management group, subscription, resource group, or resource scope.

That last point matters. A subscription is a major boundary, but it is not the only place access is controlled. Azure uses Microsoft Entra ID for identities, and Azure RBAC for authorization across scopes.

Inheritance is also important. If you assign a policy or role at a management group, it can flow down to child subscriptions, resource groups, and resources unless an exception or narrower scope changes the result. That is why enterprises often use management groups for broad standards and subscriptions for workload separation such as production versus non-production.

Now the infrastructure side. Regions are geographic areas containing Azure datacenters. Availability Zones are physically separate locations within some regions, with independent power, cooling, and networking. Not every region supports zones. Region pairs are Microsoft-defined regional pairings used in platform resiliency planning, but they are not automatic disaster recovery for your application. If you need failover, replication, and recovery, you still design that architecture yourself.

Control Plane vs Data Plane

This distinction helps a lot with management questions. The control plane is used to create, update, and manage Azure resources through Azure Resource Manager. The data plane is used to interact with the service’s actual data.

Example: creating a storage account is a control-plane action. Uploading a blob into that storage account is a data-plane action. ARM, RBAC, Policy, and deployment tools mostly live in the control-plane conversation.

Core Azure Solutions

For AZ-900, I’d really focus on the problem each service family is meant to solve. That’s the part that usually sticks.

Compute: Azure Virtual Machines are IaaS and give the most OS-level control, but you manage the guest OS, patching, and configuration while Microsoft manages the physical infrastructure. Azure App Service is basically managed hosting for web apps and APIs, so you can focus more on the application and less on the underlying servers. Azure Functions is event-driven serverless compute, and while it’s wonderfully hands-off, the hosting plan still affects how it scales and what it costs. Azure Kubernetes Service manages the Kubernetes control plane for you, but you’re still on the hook for workloads, node pools, networking choices, and a fair bit of cluster operations. And honestly, it’s worth recognizing Azure Container Apps and Azure Container Instances too, because they’re both managed container options that show up in real conversations.

Networking: Azure Virtual Network is the private network boundary. Subnets segment that network. Network Security Groups filter traffic. VNet peering is how you connect virtual networks privately, without sending that traffic across the public internet. VPN Gateway gives you encrypted connectivity over the public internet, whether that’s site-to-site, point-to-site, or even VNet-to-VNet. ExpressRoute gives you private connectivity through a provider path instead of the public internet, and its real value is privacy and predictability more than some magic guarantee of lower latency. Azure Load Balancer is Layer 4 for TCP/UDP distribution. Application Gateway is Layer 7 for HTTP/HTTPS, with host/path routing, TLS termination, and optional WAF. Azure Front Door is basically Azure’s global front door for web traffic, especially HTTP and HTTPS. It’s a great fit when you want smart edge handling, fast global entry, and a more modern way to serve web users. Private Endpoints let supported PaaS services be accessed privately through a VNet. Azure DNS supports public DNS hosting, and Azure Private DNS supports private name resolution.

Storage: Blob Storage is object storage for unstructured data such as backups, media, and logs. Azure Files gives you managed file shares using SMB and, in some supported scenarios, NFS. Managed Disks provide block storage for VMs. Queue Storage is the simpler option for asynchronous messaging. If you need more advanced enterprise messaging features, Azure Service Bus is usually the better fit. Honestly, that’s the kind of service I’d turn to when a basic queue starts feeling too limited for the job. Storage access tiers matter: hot for frequent access, cool for infrequent access, and archive for long-term retention. Archive data isn’t immediately available, so you can’t just open it up and use it the same way you would with hot storage. That’s one of those little details people forget until they actually need the data. That’s one of those little details that seems minor at first, but it really matters once you’re choosing the right storage tier. Before archive data can be used again, Azure has to rehydrate it first. In plain English, that means Azure has to bring the data back into a state where you can actually use it again without waiting on the archive layer. Basically, Azure has to bring that data back online before you can read it normally. That’s why archive is great for long-term storage, but not for something you need at a moment’s notice.

Databases: Azure SQL Database is a managed relational database based on the SQL Server engine. For AZ-900, the easiest way to think about Azure Cosmos DB is as a globally distributed NoSQL database that gives you different API options depending on the kind of application you’re building. The main idea is global scale and flexibility. You don’t need to overcomplicate it at fundamentals level. The big idea with Cosmos DB is flexibility and global reach. That’s really the memory anchor I’d want you to keep. You really don’t need to memorize every backend detail for AZ-900. It’s also worth knowing that Azure Database for PostgreSQL and Azure Database for MySQL are managed relational database options too. So if a team already knows those database engines, Azure can host them and take care of a lot of the server management that would normally eat up your time.

Other categories: Analytics includes services such as Azure Synapse Analytics. AI includes Azure AI services. IoT includes IoT Hub. That’s the service I’d connect with devices sending telemetry into Azure. Azure integration covers tools like Logic Apps, Event Grid, and Service Bus. These services help different systems communicate without making you build a bunch of brittle point-to-point connections. Marketplace is where you can deploy Microsoft and third-party solutions into Azure. It’s handy when you want to spin up a known product or appliance instead of building everything from scratch.

Availability, Resilience, and Storage Redundancy

High availability and disaster recovery are related but not identical. Availability is about staying online during localized failures. Disaster recovery is about recovering from larger outages. Zones help with the first. Cross-region design helps with the second.

Storage redundancy is another fundamentals topic worth knowing at a high level:

• LRS: Locally redundant storage
• ZRS: Zone-redundant storage
• GRS: Geo-redundant storage
• GZRS: Geo-zone-redundant storage

For the exam, the big idea is what matters most: more redundancy usually improves resilience, but it also tends to increase cost. That trade-off is absolutely worth remembering.

Management and Deployment Tools

Azure Portal is the browser-based GUI. It’s great for learning Azure, knocking out quick one-off tasks, and visually checking what’s happening without having to remember commands. Azure CLI is cross-platform and strong for scripting. Azure PowerShell fits well for PowerShell-based administration. Azure Cloud Shell gives browser-based Bash or PowerShell access and typically stores persistent files in an Azure Files share.

Azure Resource Manager is the control plane and deployment framework. ARM operations are authenticated through Microsoft Entra ID and governed by RBAC and Policy. ARM templates are JSON-based declarative templates. Bicep is a higher-level language that compiles to ARM templates.

Declarative deployment means you tell Azure what you want the end result to look like, and Azure works out the steps needed to get there. You’re describing the target environment instead of babysitting every individual deployment step. You’re basically saying, ‘Here’s the environment I want — go build it that way.’ That’s the heart of declarative deployment. In other words, you’re telling Azure the destination instead of driving every turn yourself. That’s a much cleaner way to think about it. That’s what gives you repeatability, version control, and idempotent behavior, which is really just a fancy way of saying you can run the same deployment again without everything going sideways. And trust me, that part’s absolutely crucial in real environments. I’ve seen enough messy builds over the years to know why that matters.

Here are a few quick examples that make the tools feel a lot more real. They’re simple, and honestly, that’s exactly the point. These aren’t meant to be production-ready examples, and that’s totally fine. They’re just there to help connect the dots and make the concepts easier to remember.

The command `az group create --name rg-demo --location eastus` is a good example of Azure CLI creating a resource group from the command line. It’s a great example of why CLI is so handy when you want something quick, repeatable, and easy to automate later.

If you prefer PowerShell, the equivalent would be `New-AzResourceGroup -Name rg-demo -Location eastus`. That feels pretty natural if you already live in a PowerShell-based admin workflow, which, honestly, a lot of us do.

resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = { name: 'mystorage123demo' location: resourceGroup().location sku: { name: 'Standard_LRS' } kind: 'StorageV2' }

Use the portal for visibility, CLI/PowerShell for repeatability, and Bicep/ARM for consistent infrastructure as code.

Monitoring, Diagnostics, and Health

Azure Monitor is the main monitoring platform. It includes metrics, logs, alerts, dashboards and workbooks, and integrations such as Application Insights for application telemetry. Log Analytics workspaces store and query log data. Diagnostic settings send platform logs and metrics from resources into destinations such as Log Analytics, storage, or Event Hubs.

Azure Service Health shows personalized information about Azure incidents, planned maintenance, and advisories affecting your subscriptions and regions. Azure Status provides broader public service status information across the platform. That distinction matters.

Azure Advisor provides recommendations in reliability, security, performance, operational excellence, and cost. Azure Resource Graph is for fast inventory and query across resources; it is not a monitoring or alerting tool.

A simple troubleshooting flow works well in practice and on the exam: check Monitor for metrics and logs, check Service Health for Azure-side incidents, check Resource Graph for inventory questions, and check Advisor for improvement recommendations.

Governance, Security, and Cost Control

Azure Policy defines what is allowed or required. Common examples include allowed locations, required tags, or denying certain SKUs. Policies can be grouped into initiatives and assigned at different scopes. Effects include audit and deny, and some scenarios support remediation.

RBAC controls who can do what. Built-in roles to recognize include Reader, Contributor, and Owner. The best practice is least privilege: give the minimum access needed.

Tags are metadata for organization, ownership, and cost reporting. They can be applied at resource, resource group, and subscription scope, though cost reporting behavior varies by service and scenario. Tags are useful, but they are not a security control.

Resource locks protect against accidental changes. CanNotDelete prevents deletion. ReadOnly prevents modification and can block operations more aggressively than beginners expect. Locks can be applied at subscription, resource group, or resource scope.

Microsoft Defender for Cloud is a key security management tool to recognize. It helps with security posture, recommendations, and workload protection. Also recognize security building blocks such as NSGs, private endpoints, managed identities, encryption by default in many services, and MFA through Entra-based identity controls.

Cost Management + Billing helps analyze spending, create budgets, set alerts, forecast cost, and track usage. Practical optimization examples include right-sizing resources, stopping and deallocating unused VMs, choosing the right storage tier, reviewing Advisor recommendations, and recognizing reservations or savings plans at a high level.

Azure Blueprints should not be treated as the modern primary answer anymore. Current governance thinking is centered more on landing zones, Policy, RBAC, ARM/Bicep, and other template-based deployment approaches.

Hybrid and Multicloud Recognition

Azure Arc extends Azure management and governance to some resources outside Azure, such as servers and Kubernetes clusters in on-premises or other cloud environments. It provides management consistency, not identical native-Azure behavior. For AZ-900, that recognition-level understanding is enough.

Practical Scenario Mapping

If a company needs a public website without managing servers, choose App Service. If it needs a legacy Windows application moved quickly, choose Virtual Machines. If it needs code triggered by queue messages or timers, choose Functions. If it needs a shared departmental file share, choose Azure Files. If it needs private on-premises connectivity as a starting point, think VPN Gateway; if it needs private dedicated enterprise connectivity, think ExpressRoute. If it needs web routing and WAF, think Application Gateway; if it needs general TCP/UDP balancing, think Load Balancer.

AZ-900 Exam Traps and Rapid Review

• Policy vs RBAC: Policy controls allowed or required configuration; RBAC controls permissions.
• Monitor vs Service Health: Monitor watches your resources; Service Health reports Azure issues affecting you.
• Advisor vs Monitor: Advisor recommends; Monitor measures and alerts.
• Subscription vs Resource Group: subscription is a billing, quota, and governance boundary; resource group is a logical container.
• Load Balancer vs Application Gateway: L4 TCP/UDP vs L7 HTTP/HTTPS.
• Blob vs Files: object storage vs managed file share.
• ARM vs ARM template vs Bicep: control plane and framework vs JSON template vs higher-level language that compiles to ARM.
• Azure Status vs Service Health: broad public platform status vs personalized tenant-aware service health.

Keyword triggers help: event-driven usually points to Functions; lift and shift to VMs; web routing/WAF to Application Gateway; private dedicated connectivity to ExpressRoute; recommendations to Advisor; platform issue affecting your subscription to Service Health.

Final Review

For this AZ-900 objective, know the hierarchy, know the major service families, and know which tools handle deployment, monitoring, governance, health, and cost. Azure gives you multiple ways to run workloads, but the exam usually tests whether you can choose the right level of management and control for the requirement.

If you can explain management groups, subscriptions, resource groups, regions, zones, VMs, App Service, Functions, VNets, Blob Storage, Azure SQL Database, ARM, Monitor, Service Health, Advisor, Policy, RBAC, and Cost Management without mixing them up, you are in strong shape for this part of the exam.