AZ-900 Core Solutions and Management Tools on Azure Explained

Here’s a more varied, less formulaic rewrite of the most predictable-sounding parts, while keeping the meaning intact: ---

1. Why This AZ-900 Topic Matters

This AZ-900 topic matters because it ties Azure services to the stuff you actually use to deploy them, corral them, lock them down, watch them, and keep them from getting expensive. Azure isn’t just a shelf of compute, storage, and database products. It’s also the machinery around them — control plane, governance, the whole operating wrapper.

The cleanest way to think about it? Break things into buckets. Core solutions run the workload. Management tools are the bits that deploy, configure, govern, observe, and rein things in. Once that clicks, a lot of AZ-900 questions stop feeling slippery.

2. Azure Architecture, Scope, and Resiliency Basics

Azure sits in a hierarchy, like this:

Management groups → Subscriptions → Resource groups → Resources

Management groups let you herd multiple subscriptions together, which gets useful fast when governance needs to stretch across the enterprise. Subscriptions are where billing and admin boundaries live. Resource groups? More like neat little folders for related services. And resources are the actual things — VMs, storage accounts, databases, the works.

RBAC and Azure Policy can land at management group, subscription, resource group, or resource scope, and the rules generally flow downward. That one shows up a lot on the exam. Put a policy on a management group, and yes, it can ripple through every subscription and resource group beneath it.

Resource groups are not billing buckets. They’re lifecycle-and-organization containers. Also, they’re logical, not tied to a region. You can have resources in the same group living in different places, though in practice teams often keep related pieces in the same region because… well, fewer headaches. A resource can only sit in one resource group at a time, and moving things around is possible only for certain resource types, with a few caveats and annoyances along the way.

Azure Resource Manager is the control plane — the layer you hit when you create, update, or delete stuff through the portal, CLI, PowerShell, or Bicep. The data plane is different. That’s the service itself doing its thing, like serving blobs or running database queries. Easy to blur those together if you’re not watching.

Azure regions are collections of datacenters in a defined geographic area, linked by low-latency networking. Not every Azure service is available in every region, so sometimes you’ll find the options are a little uneven depending on where you’re looking.

Availability zones are separate physical spots inside a region, each with its own power, cooling, and networking. They help with resilience — but only if the service supports them and the workload is built to take advantage.

Region pairs are Microsoft’s built-in resilience-and-update concept for many regions. Handy for recovery planning, sure. But not a magical replacement for your own disaster recovery design. That part still lands on you.

Availability sets are the older VM resilience option, meant to spread VMs across fault and update domains in a datacenter setup. For AZ-900, just remember the shape of it: availability sets are VM-centric, while zones are about separation within a region.

SLA means service-level agreement — basically an availability promise, under certain conditions. One thing AZ-900 likes to test: architecture changes the SLA story. A lone VM won’t look as sturdy as a multi-instance design built for redundancy. And a solution made of several parts can be less available overall than any one piece on its own. Sneaky, but true.

3. Azure Core Solution Categories

Compute

Compute is where the work actually happens.

Azure Virtual Machines are IaaS. You’re on the hook for the OS, patching strategy, software stack, configuration — the whole pile. Good for legacy apps, custom server needs, and anything that wants you to keep the keys.

Azure App Service is PaaS for web apps, API apps, and a few background-job scenarios. It can host code or containers. Microsoft handles a lot of the underlying platform work, so you’re not stuck doing quite as much day-to-day infrastructure babysitting.

Azure Kubernetes Service (AKS) is managed Kubernetes. Azure runs the control plane, but you still have node pools, workloads, networking decisions, cluster operations — the usual Kubernetes business. It’s a strong fit when you need container orchestration for microservices or applications that lean heavily on containers.

Azure Functions is serverless, event-driven compute. It’s especially useful for short-lived jobs that only need to run when something happens, like processing a queue message, transforming a file, or handling a quick automation task. It can run under different hosting plans, including consumption-based ones.

Azure Container Instances gives you quick container execution without dragging in a full orchestrator. Nice for lightweight or bursty jobs. Fast, simple, done.

For scaling, App Service can scale up or out, VM workloads often lean on scale sets, Functions can expand automatically, and AKS scales nodes and containers based on how you’ve designed it. For AZ-900, you don’t need the fine print — just the basic operating model.

Networking

Azure networking is what lets services talk to each other without leaving the doors wide open.

Azure Virtual Network (VNet) is the private network boundary in Azure. Inside it, you carve out subnets to split workloads apart.

Network Security Groups (NSGs) filter inbound and outbound traffic at the subnet or NIC level. If a question is about allowing or blocking VM traffic, NSG should be floating around in your head.

Public endpoints expose services to the internet. Private endpoints keep connectivity private through a VNet for supported services, which trims down public exposure nicely.

VPN Gateway gives you encrypted connectivity over the internet between Azure and another network, often on-premises.

ExpressRoute gives private connectivity to Microsoft cloud services through a provider, so the primary path skips the public internet. Important wrinkle: private doesn’t automatically mean encrypted. If encryption is needed, that may still have to be layered on.

VNet peering links VNets so resources can talk privately. Common move when applications or environments are split across different networks.

Azure Load Balancer handles traffic at the network layer. Application Gateway works at the application layer and can include web application firewall features. Quick memory trick: Load Balancer for raw traffic distribution, Application Gateway for web-aware routing. Tiny phrase, big exam usefulness.

Storage

Azure storage usually hangs off a storage account.

Blob Storage is object storage for unstructured stuff like backups, images, logs, and media.

Azure Files gives you managed file shares over SMB and, in some cases, NFS.

Queue Storage helps applications decouple with message queues.

Table Storage is Azure’s schemaless NoSQL key/attribute store.

Azure Disk Storage sits underneath managed disks for VM OS and data drives.

Then there are the knobs: access tiers and redundancy. Hot, cool, archive — all about balancing cost against how often you need the data. Redundancy options include LRS, ZRS, GRS, and GZRS. You don’t need to engineer storage strategy in AZ-900, but you do need to know durability and cost move together in slightly annoying ways.

Databases

Azure SQL Database is a fully managed PaaS relational database. You’ve got a lot less infrastructure to look after than you would if you were running SQL Server on your own virtual machine.

Azure SQL Managed Instance is another managed SQL option, often chosen when you need more SQL Server compatibility than Azure SQL Database normally gives you.

SQL Server on Azure Virtual Machines gives the most control — and, unsurprisingly, the most responsibility. Azure can still help with things like backup and availability, but you’re responsible for a lot more than you would be with a managed database service.

Azure Cosmos DB is a globally distributed, multi-model NoSQL database built for low latency and elastic scale.

A simple rule of thumb is this: if the question sounds like it wants less administrative overhead, you’re probably looking at a managed database service. If it leans toward full server control, think database on a VM.

4. Deployment and Management Tools

Azure resources are deployed and managed through Azure Resource Manager.

Azure Portal is the browser-based GUI — the friendly one, the one people start with.

Azure CLI is cross-platform and built for automation.

Azure PowerShell fits naturally if you already live in PowerShell.

Azure Cloud Shell is a browser-based shell with authenticated Azure access. You can use either the Azure CLI or PowerShell in Cloud Shell, and your persistent files are typically stored in an Azure Files share. Convenient little setup, honestly.

ARM templates and Bicep support Infrastructure as Code. Bicep is the cleaner, higher-level language that gets compiled down into ARM template JSON and then deployed through Azure Resource Manager. It’s declarative and idempotent — say what you want, and redeploy it consistently. Nice when you don’t want surprises.

Simple CLI example:

az group create --name rg-web-prod --location eastus

Simple deployment example:

az deployment group create --resource-group rg-web-prod --template-file main.bicep

Short Bicep example:

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

Storage account names have to be globally unique, between 3 and 24 characters long, and made up only of lowercase letters and numbers. So yes, a deployment can fail if that storage account name is already taken by someone else.

Azure Marketplace is where Microsoft and third parties list solutions, VM images, and managed apps. It speeds things up, though some offers bring their own licensing costs on top of Azure charges. And, of course, the bill has a habit of keeping things interesting if you’re not watching it closely.

Azure Arc stretches Azure management and governance to on-premises, edge, and multicloud resources.

5. Governance, Identity, and Security Foundations

Microsoft Entra ID handles identity and authentication for users, groups, service principals, and managed identities. In Azure, these identities are what you lean on for access control.

RBAC decides who gets to do what. You can assign it at management group, subscription, resource group, or resource scope, and it usually flows downward.

Azure Policy decides what is allowed or required. It can deny, audit, append, deploy certain settings, and trigger remediation. It can also enforce tagging standards, which is one of those things that sounds dull until it saves a mess.

Tags are metadata like Environment=Prod or Department=Finance. Useful for organization and cost reporting — though reporting gets messy if tags are missing or charges don’t map cleanly to tagged resources. Naturally.

Resource locks keep people from accidentally wrecking things. CanNotDelete stops deletion. ReadOnly stops modification. And yes, locks override RBAC in practice unless someone with the right access removes the lock first.

Managed identities let Azure resources authenticate to other services without stuffing credentials into code. Very handy when an app needs secure access to Key Vault or storage.

Microsoft Defender for Cloud gives you security posture recommendations and workload protection guidance. For AZ-900, I’d just think of it as a security management and recommendation tool.

Key Vault stores secrets, keys, and certificates. If the question sounds like, “where should we store sensitive application secrets,” this is usually the service you’re meant to pick.

Shared responsibility still matters. With IaaS, the customer carries more. With PaaS, Microsoft handles more of the platform. With SaaS, your burden shrinks even further. AZ-900 often hides that idea inside other questions instead of asking it straight out.

6. Monitoring, Health, Troubleshooting, and Cost Management

Azure Monitor gathers metrics, logs, alerts, and ties into Application Insights and Log Analytics workspaces when you need to dig deeper.

Log Analytics workspace is the main storage spot for many Azure Monitor log scenarios.

Activity Log records subscription-level control plane events like resource creation, deletion, or policy failures. The paper trail, basically.

Azure Service Health shows personalized Azure service incidents and planned maintenance that could hit your subscriptions. Azure Status gives the broad public view. Resource Health zooms in on one resource at a time.

Azure Advisor hands out recommendations for reliability, security, performance, operational excellence, and cost.

Azure Resource Graph lets you query resources across subscriptions at scale with Kusto-style syntax.

Sample Resource Graph query:

Resources | where type =~ 'microsoft.compute/virtualmachines' | project name, location, resourceGroup

When troubleshooting, try this mental checklist:

• Need metrics, logs, or alerts for your workload? Use Azure Monitor.
• Think Azure itself may be having a rough day? Check Service Health or Azure Status.
• Only one resource is acting up? Look at Resource Health.
• Deployment got blocked? Check Activity Log, RBAC, Policy, or locks.

Cost Management + Billing tracks actual and forecasted spend after deployment. Budgets and cost alerts help keep surprise bills from sneaking up on you. The Pricing calculator estimates cost before you deploy, while the TCO calculator helps compare cloud and on-premises setups. Advisor can also point out cost-saving opportunities, and it’s worth recognizing reservation-based or savings-style purchasing options at a high level.

7. End-to-End Practical Example

Picture a small web app. The team creates a production subscription, then a resource group called rg-web-prod. From there, they deploy App Service for the front end, Azure SQL Database for relational data, and Blob Storage for file uploads. The app uses a managed identity, which lets it reach Key Vault without hardcoded secrets sitting in the code.

They place the environment in a region close to their users and check whether the needed services actually exist there — because yes, that matters. Tags like Environment=Prod and Owner=WebTeam go on the resources. RBAC gives developers contributor access in dev, but only narrow production rights. Azure Policy enforces approved regions and required tags. A CanNotDelete lock protects critical storage. Azure Monitor watches failed requests, Service Health is there for platform incidents, and Cost Management tracks spend by tag. That’s the Azure lifecycle in the wild: deploy, govern, secure, monitor, optimize. Rinse, repeat.

8. AZ-900 Exam Traps and Rapid Review

If the question says:

• Only approved locations are allowed → Azure Policy
• Who can create or delete resources → RBAC
• Prevent accidental deletion → Resource lock
• Need repeatable deployments → ARM/Bicep
• Need recommendations to improve cost or reliability → Advisor
• Need to know whether Azure has a regional issue → Service Health or Azure Status
• Need workload metrics and alerts → Azure Monitor
• Need a private dedicated connection to Azure → ExpressRoute
• Need encrypted connectivity over the internet → VPN Gateway
• Need a web app without managing servers → App Service
• Need full OS control → Virtual Machines
• Need container orchestration → AKS

Common confusion areas: Policy is not RBAC. Service Health is not Azure Monitor. Resource groups are not billing boundaries. Zones are not region pairs. Azure SQL Database is not SQL Server on a VM. Blob Storage is not Azure Files.

Don’t get lost in deep syntax or Kubernetes internals for AZ-900. The test wants service purpose, category, and comparison language. That’s the game.

9. Final Thoughts

Azure fundamentals gets a lot simpler when you stop thinking of Azure as a giant product list and start seeing it as a managed ecosystem. Core solutions run workloads. Management tools handle deployment, access, compliance, observability, and cost. If you can keep subscription vs. resource group straight, Policy vs. RBAC, Monitor vs. Service Health, and VM vs. App Service, you’re in good shape for AZ-900 — and, honestly, for basic cloud fluency too.