Operate Your Workload: Backup, Keys, Monitoring, Quota¶
The platform gives you a secure place to run. Keeping your workload healthy is yours (Responsibilities). This page lists the points that teams most often ask about.
Backup and recovery¶
The MCP spoke baseline does not deploy a backup vault or backup policies for you, and doesn't back up your VMs, databases or file shares. Plan this yourself:
- Choose the backup service per resource (for example Azure Backup with a Recovery Services vault, built-in backups of databases, blob versioning and soft delete).
- Decide retention, frequency and geo-redundancy from your classification.
- Test restores regularly. A backup you have not restored is not a backup.
- Write down your recovery procedure and who runs it.
If your platform offers the Managed VM module, VMs deployed with it get a Recovery Services vault, a default policy and failure alerts. See Backup and restore of managed VMs for the defaults and the restore steps.
Your platform may add a backup policy as part of its governance (for example automatic backup of tagged VMs). Ask your platform team. If it does, it should state the default policy, retention and how to opt out (usually an exclusion tag).
From a customer platform
One customer platform deployed a Recovery Services vault per landing zone: geo-redundant, soft delete on, immutable, public access off, encrypted with a customer-managed key, with daily VM and file-share policies (10 days daily, 4 weeks weekly), plus Azure Policy that enrolled every VM and file share without an exclusion tag. That is not part of the MCP product. It shows what a platform can add on top.
Long-term archive¶
Data that you no longer use but must keep for compliance, auditing or reference does not belong in a running workload. Some platforms offer an archive spoke for this: a storage account that no other spoke and no user can reach, protected with vaulted backups. The data is copied to a Backup Vault, which is redundant and geo-replicated across two regions.
A typical retention (an example, set by your platform): a backup every day, kept for 7 days. A monthly backup is kept for 90 days and a yearly backup for 365 days. Soft delete on the vault is on for 14 days. Ask your platform team whether an archive spoke exists, what the retention is and how you get data in.
Patching and updates¶
OS updates of VMs are yours (Responsibilities). Azure Update Manager with maintenance configurations is the usual tool: a tag on the VM selects the schedule, and you check the result afterwards. See Updates and patching of managed VMs for the schedules, the check and the manual procedure. Servers outside Azure can be patched in the same way after onboarding to Azure Arc.
App registration secrets¶
Client secrets of app registrations expire. See App registration secrets for the renewal steps and for the expiry notifications that some platforms provide.
Encryption and customer-managed keys¶
- Data at rest in Azure is encrypted with Microsoft-managed keys by default.
- The spoke baseline creates a Key Vault (RBAC, purge protection, private endpoint) and a storage account that uses a customer-managed key from that Key Vault.
- For your own resources you can use customer-managed keys (CMK) when your classification asks for it. Microsoft Learn describes this per service: storage accounts, VM disks (disk encryption sets), SQL transparent data encryption, and the list of services that support CMK.
- You own key rotation and key access for your resources.
Logging and monitoring¶
How the platform alerts: Monitoring and alerting.
| What | Who | Notes |
|---|---|---|
| Platform health (hub, firewall, gateways) | Platform team | Azure Monitor Baseline Alerts and Service Health alerts, with alert routing to the platform team |
| Your resources' logs | You | Send diagnostic settings to your Log Analytics workspace (the spoke creates one by default). Policy may deploy some diagnostic settings for you. |
| Your application alerts and dashboards | You | Alert rules, action groups and dashboards on your workspace |
| Security recommendations | You, for your subscription | Defender for Cloud and Advisor, if enabled on your platform |
| Cost | You | See Cost and reservations |
A platform can also provide central dashboards (for example firewall logs per spoke, in a managed Grafana). Ask what your platform offers. Logs of hub components such as the Application Gateway can also be made available to you, see Application Gateway logs.
Check the daily ingestion cap
A Log Analytics workspace can have a daily data cap to avoid surprise costs. If logs stop arriving, check the cap on the workspace.
Quota and capacity problems¶
Use this when a deployment fails with QuotaExceeded, OperationNotAllowed, AllocationFailed or
ZonalAllocationFailed, new VMs don't start, or AKS nodes can't scale.
- Read the error and note the scope: subscription, region, resource type, SKU.
- Check quota: portal → your subscription → Usage + quotas, filtered on region and provider. Compare Current usage with Limit.
- Check from the CLI:
az account set --subscription "<subscription-id>" az vm list-usage --location <region> --output table az vm list-skus --location <region> --resource-type virtualMachines --output table - Interpret:
- Usage near the limit: request a quota increase for that subscription, region and resource type.
- Usage below the limit but the deployment fails: the regional or zonal capacity or SKU availability is the problem. Use another SKU, another zone, or (if policy allows) another region.
- Rule out a platform incident: check Azure Service Health and Resource Health.
- Prevent repeats: check quota before large releases, record minimum capacity per environment (vCPUs, IPs, disks), set alerts on usage versus limit, add a quota check to your release checklist.
Region choice is limited to the regions your hub runs in and your policies allow.
Deploying resources¶
Use infrastructure as code (Terraform is the platform's tool; Bicep also works for Azure-only deployments) from your own pipelines with the spoke service principal, ideally with workload identity federation (Use your spoke). In production, avoid manual portal changes.