This chapter covers manageability in the cloud — a core concept for the AZ-900 exam. You will learn how Azure provides tools to deploy, monitor, update, and govern resources efficiently. Manageability represents roughly 10-15% of the exam weight across the Cloud Concepts domain (Objective 1.5). Understanding these tools is critical because they differentiate cloud from on-premises: the cloud offers centralized management, automation, and self-service capabilities that reduce operational overhead. We will explore Azure Resource Manager, Azure Monitor, Azure Policy, and automation features like Azure Automation and Update Management.
Jump to a section
Imagine you manage a large hotel. In the old on-premises way, you had to own the building, hire a full maintenance crew, and keep spare keys and light bulbs in a closet. If a guest needed a room upgrade or a meeting space, you had to physically walk to the front desk, check the paper ledger, and maybe even move furniture. That was slow and error-prone. Now, Azure’s manageability tools are like a smart hotel management system. You have a central dashboard that shows every room’s status in real time: which are occupied, which need cleaning, which have reported a leaky faucet. You can set up automatic rules: if a room’s temperature drops below 68°F, the HVAC system adjusts itself. If a guest checks out, the cleaning crew gets an instant notification. You can also use a mobile app to remotely lock a door, adjust the thermostat, or view security camera feeds. The key mechanism is that the system constantly monitors sensors and logs, compares them to your policies, and triggers actions without human intervention. You don’t need to be on-site; you can manage the entire hotel from a tablet anywhere in the world. This is exactly how Azure Resource Manager, Azure Monitor, and Automation accounts work: they provide a unified control plane, continuous telemetry, and policy-driven automation to manage cloud resources at scale.
What is Manageability in the Cloud?
Manageability refers to the tools and processes that allow administrators to control, monitor, and maintain cloud resources with minimal manual effort. In traditional on-premises data centers, managing servers, networks, and storage required physical access, manual configuration, and constant oversight. The cloud shifts this to a software-defined model where everything is accessible via APIs, portals, and command-line tools. Azure’s manageability services solve the business problem of operational complexity: as organizations scale, manual management becomes error-prone and expensive. Azure provides a unified platform to automate deployment, enforce compliance, collect telemetry, and apply updates across thousands of resources.
How Azure Resource Manager (ARM) Works
Azure Resource Manager is the foundational management layer for Azure. Every resource you create — virtual machines, databases, storage accounts — belongs to a resource group. ARM handles all requests through a single control plane. Here’s the step-by-step mechanism:
User sends a request: You use the Azure portal, Azure CLI, PowerShell, or REST API to create, update, or delete a resource.
ARM authenticates and authorizes: ARM checks Azure Active Directory for identity and role-based access control (RBAC) permissions.
ARM validates the request: It checks that the resource name is unique, the location is valid, and the request conforms to any Azure Policy rules.
ARM orchestrates the operation: ARM sends the request to the appropriate resource provider (e.g., Microsoft.Compute for VMs). The resource provider executes the operation and reports back.
ARM returns the result: The user sees the outcome in the portal or CLI output.
This consistent API layer means you can manage resources programmatically using declarative templates (ARM templates or Bicep) that define the entire infrastructure as code. For example, you can deploy a full environment with a single template:
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2021-09-01",
"name": "mystorageaccount",
"location": "eastus",
"sku": {
"name": "Standard_LRS"
},
"kind": "StorageV2"
}
]
}Azure Monitor: The Central Observatory
Azure Monitor collects and analyzes telemetry from Azure resources, on-premises servers, and other clouds. It is the single pane of glass for monitoring performance, availability, and health. Key components:
Metrics: Numerical values collected at regular intervals (e.g., CPU percentage, disk IOPS). Metrics are stored in a time-series database and can trigger alerts.
Logs: Structured or free-form log data from resources (e.g., Windows Event Logs, application traces). Logs are stored in Log Analytics workspaces and can be queried with Kusto Query Language (KQL).
Alerts: Rules that evaluate metrics or logs and trigger actions (email, SMS, webhook, runbook) when conditions are met.
Application Insights: An extension of Azure Monitor for application performance management (APM). It tracks request rates, response times, dependencies, and exceptions.
Example: You create an alert rule that sends an email when a VM’s CPU usage exceeds 90% for 5 minutes. Behind the scenes, Azure Monitor checks the metric every minute, evaluates the condition, and fires the alert when the threshold is crossed.
Azure Policy and Blueprints for Governance
Azure Policy helps enforce organizational standards and assess compliance. It applies rules to resources at scale. For example, you can create a policy that only allows VMs of a specific size (e.g., Standard_DS2_v2) in a subscription. When someone tries to deploy a larger VM, the deployment is denied. Azure Policy works by evaluating resource properties against policy definitions and taking effect before (deny) or after (audit) creation.
Azure Blueprints (now being replaced by Deployment Stacks) allow you to package policies, RBAC roles, and resource templates into a single deployable artifact. This enables repeatable, compliant environments.
Automation: Azure Automation and Update Management
Azure Automation provides a way to automate frequent, time-consuming tasks using runbooks (PowerShell or Python scripts). For example, you can create a runbook that shuts down dev VMs at 7 PM and starts them at 7 AM to save costs. Azure Automation also includes:
Update Management: Manages OS updates for Windows and Linux VMs. It assesses missing updates, schedules installations, and reports compliance.
Change Tracking and Inventory: Tracks changes to software, services, and registry keys.
Desired State Configuration (DSC): Ensures VMs are configured consistently (e.g., install IIS, enable Windows Firewall).
Comparison to On-Premises
On-premises, you manage each server individually via Remote Desktop or SSH. Updates are manual or require a separate tool like SCCM. Monitoring requires setting up a monitoring server (e.g., Nagios) and configuring SNMP. In Azure, all of this is built-in and accessible from a single portal. You can manage thousands of VMs with the same effort as one. The cloud also provides self-service capabilities: developers can provision resources on demand without waiting for IT.
Azure Portal, CLI, and PowerShell Touchpoints
- Azure Portal: The web-based UI. You can navigate to Resource Groups, Monitor, and Automation accounts. For example, to create an alert, go to Monitor > Alerts > New alert rule. - Azure CLI: Cross-platform command-line tool. Example to list all VMs:
az vm list --output table- Azure PowerShell: For Windows-centric environments. Example to start a VM:
Start-AzVM -ResourceGroupName "MyRG" -Name "MyVM"Both CLI and PowerShell can be used in scripts and CI/CD pipelines.
Pricing Models
Most manageability tools are free for basic use. For example, Azure Resource Manager has no additional cost. Azure Monitor has a free tier for metrics and alerts, but storing logs beyond 31 days incurs charges per GB ingested. Azure Automation charges for runbook execution minutes and storage of runbooks. Update Management is included with Azure Automation but requires Log Analytics for assessment data.
Create a Resource Group
In the Azure portal, navigate to Resource Groups and click Create. Enter a name, select a region (e.g., East US), and optionally add tags (e.g., Environment=Production). Azure Resource Manager creates a logical container that will hold all related resources. Behind the scenes, ARM registers the resource group in the subscription and assigns a unique ID. This step is essential because every resource must reside in a resource group. You cannot create a resource without first having a resource group. The default limit is 980 resource groups per subscription, but this can be increased by requesting a quota raise.
Deploy a Virtual Machine with ARM Template
Go to the Azure portal, select 'Deploy a custom template' and upload an ARM template that defines a VM. The template includes parameters like adminUsername and adminPassword. When you deploy, ARM validates the template syntax and checks that the resource provider (Microsoft.Compute) is registered. ARM then orchestrates the creation: it creates the network interface, public IP, virtual network, and VM. The entire deployment is tracked in the resource group's deployment history. You can monitor progress in the portal's 'Deployments' blade. If the deployment fails, ARM rolls back automatically.
Set Up Azure Monitor Alerts
In the Azure portal, go to Monitor > Alerts > Create > Alert rule. Select a scope (e.g., a virtual machine). Choose a condition, such as 'Percentage CPU > 80%' for 5 minutes. Configure an action group: define who gets notified (e.g., email to admin@contoso.com). Azure Monitor then continuously evaluates the metric every minute. When the threshold is breached, the alert fires and triggers the action group. You can also use Log Analytics queries for more complex conditions. Alerts help you proactively respond to issues before they become outages.
Apply an Azure Policy to Enforce Tags
Navigate to Azure Policy > Definitions and create a new policy definition that requires a 'CostCenter' tag on all resources. Assign the policy to a subscription or resource group. When a user tries to create a resource without the tag, the policy denies the request. Alternatively, you can set the policy to 'Audit' to log non-compliant resources without blocking. Azure Policy evaluates resources during creation and periodically (every 24 hours) for existing resources. Compliance results are shown in the Policy dashboard.
Schedule a VM Shutdown with Automation
Create an Azure Automation account. Import a runbook from the gallery (e.g., 'Stop Azure VMs on a schedule'). Link the runbook to a schedule (e.g., every weekday at 7 PM). The runbook uses PowerShell to loop through VMs in a resource group and stop them. Azure Automation executes the runbook on a hybrid worker or in the Azure sandbox. This saves costs by shutting down non-production VMs during off-hours. You can also add a start runbook for 7 AM. This is a common pattern for dev/test environments.
Scenario 1: E-Commerce Platform Monitoring
An e-commerce company runs its website on 20 Azure VMs behind a load balancer. They need to ensure uptime during Black Friday. The operations team uses Azure Monitor to collect metrics (CPU, memory, network) and logs (IIS logs, application traces). They set up alerts for CPU > 90% and error rates > 5%. They also use Application Insights to track user sessions and page load times. During a traffic spike, an alert triggers an automation runbook that scales out the VM scale set by adding two more instances. This auto-scaling prevents downtime. Cost: Azure Monitor logs cost ~$2 per GB ingested; Application Insights has a free tier of 5 GB per month. If they set up alerts incorrectly (e.g., threshold too low), they get paged unnecessarily, leading to alert fatigue.
Scenario 2: Healthcare Compliance with Azure Policy
A hospital migrates patient records to Azure. They must comply with HIPAA, which requires encryption at rest and in transit. They use Azure Policy to enforce that all storage accounts have encryption enabled and that VMs use managed disks. They also enforce that resources are deployed only in approved regions (e.g., East US). When a developer tries to deploy a storage account without encryption, the policy denies the request. The compliance team views the Policy dashboard to see 100% compliance. If they forget to assign the policy to a new subscription, a resource might be created non-compliant, risking audit failure. Azure Policy's 'audit' mode helps catch such mistakes before they escalate.
Scenario 3: Multi-Branch Retail Update Management
A retail chain has 500 stores, each with a local server running inventory software. They use Azure Update Management to assess and install patches. Each store's server has the Log Analytics agent installed. In the Azure portal, the IT team sees a report of missing updates across all servers. They schedule a maintenance window for Sunday 2 AM to install critical patches. The runbook pushes updates to all servers simultaneously. This eliminates the need for IT to visit each store. If the network connection drops during patching, the server might be left in an inconsistent state; Azure Automation can retry the update. The cost is based on Log Analytics data ingestion (~$2.30 per GB) and Automation runbook execution minutes.
Exam Objective: Describe the benefits of cloud manageability (Objective 1.5)
This objective tests your understanding of how Azure provides tools for managing resources efficiently. You should know the purpose of Azure Resource Manager, Azure Monitor, Azure Policy, and Azure Automation. The exam will ask you to identify which service is used for a specific scenario.
Common Wrong Answers and Why
Wrong: 'Azure Policy is used to monitor performance.' Why: Candidates confuse policy with monitoring. Azure Policy enforces rules (e.g., tagging, allowed locations), while Azure Monitor collects telemetry. Remember: Policy = governance, Monitor = observability.
Wrong: 'Azure Resource Manager is a tool for cost management.' Why: ARM is the management layer, not a cost tool. Cost management is done via Azure Cost Management + Billing. ARM handles deployment and orchestration.
Wrong: 'Azure Automation is used to deploy resources.' Why: Automation runs scripts (runbooks) for tasks like patching or shutdown. Deployment is done via ARM templates or Bicep. Automation can be triggered by alerts but is not the primary deployment tool.
Wrong: 'Azure Monitor can block non-compliant resources.' Why: Monitor only observes; it cannot deny actions. Azure Policy denies or audits. A common trick question: 'Which service prevents deployment of VMs without managed disks?' Answer: Azure Policy.
Specific Terms and Values
Resource group: a logical container for resources. Every resource must be in exactly one resource group.
Azure Monitor: collects metrics (numerical) and logs (textual). Metrics are stored for 93 days by default; logs retention is configurable (30 days to 730 days).
Azure Policy: has effects: Deny, Audit, Append, DeployIfNotExists. The default effect is Audit.
Azure Automation: runbook execution time limit is 3 hours for sandbox, unlimited for hybrid workers.
Update Management: uses Log Analytics for assessment; update installations are done via Automation runbooks.
Edge Cases and Tricky Distinctions
Azure Policy vs. RBAC: Policy evaluates resource properties (e.g., size, location). RBAC controls who can perform actions (e.g., who can create VMs). A user with Contributor role can still be blocked by a policy.
Azure Monitor vs. Service Health: Monitor is for your resources; Service Health shows Azure platform outages and planned maintenance.
Azure Automation vs. Azure Functions: Automation runbooks are for IT operations; Functions are for application code. Both can be triggered by alerts, but runbooks are better for long-running tasks.
Memory Trick: 'PAM' for Manageability
Policy: governance and compliance
Automation: runbooks and update management
Monitor: metrics, logs, alerts
When asked which service to use for a manageability scenario, ask: Is it about rules? → Policy. Is it about automated tasks? → Automation. Is it about observing? → Monitor.
Azure Resource Manager (ARM) is the unified management layer for all Azure resources; it handles deployment, authentication, and orchestration.
Azure Monitor collects metrics (numerical) and logs (textual); metrics are retained for 93 days by default.
Azure Policy enforces compliance rules (e.g., require tags, restrict VM sizes) with effects like Deny and Audit.
Azure Automation runs PowerShell or Python runbooks for tasks like VM shutdown and patching; runbooks can run on hybrid workers.
Update Management in Azure Automation assesses and installs OS updates; it requires the Log Analytics agent.
Resource groups are logical containers; each resource must belong to exactly one resource group.
Azure Blueprints (now Deployment Stacks) package policies, RBAC, and templates for repeatable deployments.
The Azure CLI and PowerShell provide command-line management; both are cross-platform and scriptable.
These come up on the exam all the time. Here's how to tell them apart.
Azure Policy
Enforces rules on resource properties (e.g., location, size, tags).
Evaluates compliance continuously and during resource creation.
Effects include Deny, Audit, Append, DeployIfNotExists.
Scoped to management group, subscription, or resource group.
Used for governance and compliance.
Azure RBAC
Controls access to resources based on user identity and role.
Evaluated at authentication time for each operation.
Roles define permissions (e.g., Reader, Contributor, Owner).
Scoped to management group, subscription, resource group, or individual resource.
Used for security and access control.
Mistake
Azure Resource Manager is a separate service you must enable.
Correct
ARM is the underlying management layer for all Azure resources. It is always active and does not need to be enabled. Every deployment goes through ARM.
Mistake
Azure Monitor can automatically fix problems like restarting a VM.
Correct
Azure Monitor only observes and alerts. To take automated action, you must connect the alert to an Azure Automation runbook or a webhook. Monitor alone cannot restart a VM.
Mistake
Azure Policy can be applied to individual resources.
Correct
Azure Policy is assigned at a scope (management group, subscription, or resource group). It cannot be assigned to a single resource directly. However, you can use exclusion scopes to exempt specific resources.
Mistake
Update Management requires no additional setup beyond enabling it.
Correct
Update Management requires the Log Analytics agent to be installed on VMs and a Log Analytics workspace to store assessment data. Without these, it cannot assess missing updates.
Mistake
Azure Automation runbooks can only run in the Azure cloud.
Correct
Runbooks can run on hybrid workers (on-premises servers or other clouds) for managing non-Azure resources. This extends automation to hybrid environments.
Azure Policy enforces rules on resource properties (e.g., allowed locations, required tags) and evaluates compliance. Azure RBAC controls who can perform actions on resources (e.g., who can create VMs). Policy is about 'what' is allowed; RBAC is about 'who' can do it. On the exam, remember: Policy = compliance, RBAC = access.
Use Azure Automation with a runbook that stops VMs. Create an Automation account, import the 'Stop Azure VMs on a schedule' runbook from the gallery, link it to a schedule (e.g., 7 PM daily), and specify the target VMs. The runbook uses PowerShell to stop the VMs. This is a common cost-saving measure for dev/test environments.
Azure Monitor metrics are retained for 93 days by default. You can query metrics in the portal for up to 30 days interactively. For longer retention, you can archive metrics to a storage account or stream them to Log Analytics. Logs retention is configurable from 30 to 730 days.
Yes. Create a policy definition that denies resources if their location is not in the allowed list (e.g., 'eastus' or 'westus'). Assign the policy to the subscription or resource group. When a user tries to deploy a VM in 'northeurope', the deployment is denied. This is a common compliance requirement.
Azure Monitor tracks the performance and health of your own resources (VMs, apps, etc.). Azure Service Health provides information about Azure platform outages, planned maintenance, and service advisories that affect your subscriptions. Service Health is global; Monitor is resource-specific.
When you create a resource, ARM receives the request, authenticates via Azure AD, authorizes via RBAC, validates the request against policies, and then forwards it to the appropriate resource provider (e.g., Microsoft.Compute). The provider creates the resource and reports back. ARM ensures idempotency: if you submit the same template twice, the second time is a no-op if the resource already exists.
A resource group is a logical container that holds related resources for an Azure solution. It allows you to manage, monitor, and secure resources as a group. For example, you can apply policies, assign RBAC roles, and view costs at the resource group level. Each resource must belong to exactly one resource group, and resource groups cannot be nested.
You've just covered Manageability in the Cloud — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.
Done with this chapter?