Domain 1 of 3 · Chapter 2 of 3

Cloud Benefits

High availability vs scalability: the exam's favorite benefit pairing

High availability and scalability sound like the same promise, yet they answer two different questions: one keeps your app online through a failure, the other gives it enough capacity for the load. The AZ-900 objective Describe the benefits of high availability and scalability in the cloud[1] bundles them on purpose, so every scenario hinges on reading which one it is really asking about.

High availability is about uptime

High availability (HA) means an application keeps running and stays reachable with minimal downtime, even when individual components fail. The cloud delivers HA by running your workload on redundant infrastructure so there is no single point of failure. In Azure that typically means spreading instances across availability zones[2], which are physically separate datacenters within a region. If one zone has a power or hardware fault, the others keep serving traffic. Microsoft expresses the HA commitment for many services as a Service Level Agreement (SLA), a published uptime percentage such as 99.9%. The stem signals for HA are about staying online: "survive a datacenter failure," "no single point of failure," "keep the site reachable during an outage."

Scalability is about capacity

Scalability is the ability to adjust the amount of compute, storage, or other resources to match demand. There are two directions, and the exam tests the distinction directly:

Direction Name What changes Example
Up / down Vertical scaling (scale up) The size of a single instance Move a VM to a SKU with more CPU and RAM
Out / in Horizontal scaling (scale out) The number of instances Add more identical VMs behind a load balancer

Scaling up gives one machine more power; scaling out adds more machines. A stem that says "add more web servers to handle more users" is scaling out; "give the database server more memory" is scaling up.

Why they get confused, and how to separate them

Both HA and scalability often involve multiple instances, which is why the exam pairs them. The discriminator is the goal: if the goal is to keep running through a failure, it is high availability; if the goal is to have enough capacity for the load, it is scalability. A site can be highly available but under-scaled (it stays up but is slow), or well-scaled but not highly available (fast, but a zone outage takes it down). The right cloud design usually combines both: multiple instances across zones gives you redundancy and capacity at once.

Read the goal in the stem uptime or capacity? High availability keep running through a failure Scalability enough capacity for the load Scale up more power (vertical) Scale out more machines (horizontal) uptime capacity
Benefit discriminator: the stem's goal picks the answer: stay online is high availability; enough capacity is scalability, splitting into scale up and scale out. Based on the Microsoft Learn module.

Elasticity, reliability, and predictability: automatic capacity, recovery, and forecastable performance and cost

Beyond raw HA and scalability, AZ-900 tests three related benefits: elasticity, reliability, and predictability. They build on the first two but each has a distinct exam fingerprint. The figure below groups the three: elasticity and reliability stand alone, while predictability splits into a performance half and a cost half.

Elasticity = automatic, demand-driven scaling

Elasticity is scalability that happens automatically in response to load. Instead of an administrator manually adding or removing capacity, the platform does it for you as demand rises and falls. In Azure this is delivered by autoscale on services such as Virtual Machine Scale Sets[3] and Azure App Service autoscale[4]. The financial payoff is the pay-as-you-go / consumption-based pricing model[1]: you only pay for what you use, so you avoid over-provisioning for a worst-case peak that rarely occurs. Stem signals for elasticity: "automatically handle unexpected spikes," "scale in when traffic drops," "only pay for the capacity you actually consume."

Reliability = recover from failure and keep working

Reliability is the ability of a system to recover from failures and continue to function. It is one of the five pillars of the Microsoft Azure Well-Architected Framework[5], and the cloud supports it with built-in redundancy, backup, and disaster-recovery options that would be expensive to build yourself. Reliability overlaps with HA but is broader: HA focuses on avoiding downtime, while reliability also covers recovering after something does go wrong (restoring from backup, failing over to another region). Stem signals: "recover from a failure," "resilient," "continue operating after an outage."

Predictability has two halves: performance and cost

Predictability means you can rely on the system to behave the way you expect, and the exam splits it cleanly in two:

  • Performance predictability keeps the user experience consistent as load changes. It is achieved with the same mechanisms as scalability and HA: autoscale[4] to add capacity on demand and load balancing[6] to distribute traffic evenly so no single instance is overwhelmed. Signal: "consistent response times during a traffic surge."
  • Cost predictability lets you forecast and track spending accurately. Azure provides Microsoft Cost Management[7] for monitoring and analyzing real spend and the Pricing Calculator[8] for estimating a planned deployment; for on-premises-versus-Azure TCO comparison, Microsoft has retired the standalone Total Cost of Ownership (TCO) Calculator[9] and that analysis now runs through the Azure Migrate business case[10] feature. Signal: "forecast next quarter's bill," "estimate the monthly cost before deploying."

Keep cost predictability separate from cost savings: predictability is about forecasting and visibility, while the CapEx-to-OpEx shift and pay-as-you-go pricing are the savings benefit.

Elasticity automatic scaling that tracks demand Reliability recover from failure and keep working Predictability Performance consistent under load Cost forecastable spend
The three further benefits as a taxonomy: elasticity, reliability, and predictability, with predictability splitting into performance and cost.

Security, governance, and manageability benefits

The last cluster of AZ-900 benefit objectives covers security and governance and manageability. Each maps to specific Azure capabilities the exam expects you to name. The figure below groups the three: security and governance stand alone, while manageability splits into management of the cloud and management in the cloud.

Security benefit: defense in depth on a shared responsibility model

The cloud improves security through defense in depth: multiple overlapping layers of protection (physical, identity, network, application, data) so that breaching one layer does not compromise the whole system. It operates under the shared responsibility model[11]: Microsoft secures the physical datacenters and the underlying platform, while you remain responsible for your data, identities, devices, and access configuration. Azure's centralized security tooling is a key benefit: Microsoft Defender for Cloud[12] continuously assesses your security posture (a Secure Score), surfaces recommendations, and provides threat protection across resources. The benefit framing: you inherit Microsoft's massive, continuously updated security investment rather than building all of it yourself.

Governance benefit: enforce standards consistently at scale

Governance is the ability to apply organizational standards and stay compliant across many resources without manual, per-resource effort. Azure provides:

Tool What it does
Azure Policy[13] Audits and enforces rules (for example, "only allow approved regions" or "require a tag") and can flag or block non-compliant resources
ARM templates[14] / Bicep Define infrastructure as code so every deployment is repeatable and identical
Azure Blueprints[15] Package policies, role assignments, and templates into a repeatable, compliant environment baseline

The governance benefit is consistency and compliance at scale: a stem about "ensure every team's resources follow company standards" or "deploy a compliant environment repeatedly" points here.

Manageability benefit: management OF the cloud and IN the cloud

The manageability objective[1] divides into two complementary ideas, and the exam likes to ask which a feature belongs to:

  • Management of the cloud: the platform manages itself for you, automatically. This includes autoscale, automatic resource provisioning, automatic recovery (self-healing) of unhealthy resources, and continuous monitoring of resource health. You benefit without doing the work.
  • Management in the cloud: the tools you use to manage and configure your resources. These include the Azure portal[16] (graphical web interface), Azure CLI[17] and Azure PowerShell[18] (command-line and scripting), the Azure mobile app, and infrastructure-as-code via ARM/Bicep templates. AZ-900 expects you to know what these tools are and when you would use each: the portal for ad-hoc, visual work; CLI/PowerShell for automation and scripting; templates/IaC for repeatable deployments, but it never asks you to write the actual commands or template syntax.
Security defense in depth, shared responsibility Governance enforce standards at scale Manageability Of the cloud platform manages itself for you In the cloud tools you use to manage resources
The security, governance, and manageability benefits as a taxonomy, with manageability splitting into management of and in the cloud.

Exam-pattern recognition: matching a scenario to the right benefit

Benefit questions on AZ-900 are scenario-to-benefit matching. The stem describes a goal in business language; the options are benefit names that all sound positive. You win by spotting the signal word and knowing why each near-miss is wrong. Below are the recurring patterns and the traps the exam reuses.

The signal-word cheat sheet

If the stem emphasizes... The answer is... Not...
Staying online through a failure / outage High availability Scalability
Adding more instances for more users Scalability (scale out / horizontal) High availability
A bigger / more powerful single machine Scalability (scale up / vertical) Scale out
Automatically following demand, pay for use Elasticity (autoscale) Manual scaling
Recovering and continuing after a failure Reliability Just "availability"
Consistent performance under variable load Performance predictability Cost predictability
Forecasting or tracking the bill Cost predictability Scalability
Layered protection / centralized threat tools Security (defense in depth) Governance
Enforcing standards / compliance across resources Governance Security
The platform managing itself automatically Manageability (management of the cloud) Management in the cloud
Portal / CLI / PowerShell / templates to configure Manageability (management in the cloud) Management of the cloud

The three traps the exam reuses

  1. Up vs out. "Scale up" (vertical, bigger instance) and "scale out" (horizontal, more instances) are offered as competing options. If the stem mentions adding servers/instances or a load balancer, it is scale out; if it mentions a larger VM size or more CPU/RAM on one machine, it is scale up.

  2. Availability vs scalability. Because both use multiple instances, the exam offers them together. Anchor on the goal: staying up through a failure = availability; enough capacity for demand = scalability.

  3. Predictability split. A single "predictability" answer can be wrong if the stem is really about the other half. "Consistent response times" is performance predictability (autoscale, load balancing); "forecast the monthly cost" is cost predictability (Cost Management, Pricing Calculator). Read whether the consistency is about performance or spend.

Boundary checks

  • Security vs governance. Security is protecting resources (defense in depth, Microsoft Defender for Cloud); governance is standardizing and enforcing rules (Azure Policy, Blueprints). "Block deployments outside approved regions" is governance, not security.
  • Of vs in the cloud. Autoscale and self-healing happening automatically = management of the cloud; you opening the portal or running a CLI command = management in the cloud.

Master the signal-word table and these three traps and you can answer essentially every benefit question on recognition rather than recall.

High availability vs scalability vs elasticity vs reliability vs predictability

BenefitWhat it promisesAzure mechanismStem signal
High availabilityMinimal downtime despite failuresAvailability zones, redundancy, load balancing"stay online," "survive a datacenter outage"
ScalabilityAdjust capacity to match demandScale up (vertical) or scale out (horizontal)"add more servers," "a bigger VM"
ElasticityAutomatic, demand-driven scalingAutoscale (VM Scale Sets, App Service)"automatically handle spikes," "pay for what you use"
ReliabilityRecover from failure and keep runningWell-Architected reliability pillar, backup/DR"recover from failure," "resilient"
PredictabilityConsistent performance and forecastable costAutoscale + load balancing; Cost Management, calculators"consistent response times," "forecast the bill"

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

High availability means staying online through component failures

High availability (HA) keeps an application running and reachable with minimal downtime even when individual components fail, and the cloud achieves it with redundant infrastructure that removes single points of failure. On AZ-900 the fingerprint is "stay online," "survive an outage," or "no single point of failure." HA is about avoiding downtime, not about handling more load.

Trap Confusing high availability with scalability: both use multiple instances, but HA is about staying up, scalability is about having enough capacity.

4 questions test this
Availability zones give HA inside one region

Availability zones are separated groups of datacenters within a single region, each with independent power, cooling, and networking, so if one zone fails the others keep serving, typically within ~100 km of each other for low-latency replication. A resource is zone-resilient only once it spans two or more zones, and many Azure SLAs require a multi-zone deployment to reach their highest uptime tier. Use them for in-region HA; they do not protect against a full-region outage.

Trap Assuming a single availability zone is redundant: one zone is one logical group of datacenters, and zonal (single-zone) deployment carries no cross-zone protection.

7 questions test this
Scalability is having enough capacity for demand

Scalability is the ability to add or remove resources so capacity matches workload demand. It is distinct from high availability: scalability is about having enough capacity, HA is about staying online. A stem about handling more users or growing load points to scalability.

Trap Picking high availability when the stem is about growing load, since HA targets staying online through failures while scalability targets having enough capacity for demand.

2 questions test this
Scale up is vertical, scale out is horizontal

Scaling up (vertical) adds power to a single instance (moving a VM to a SKU with more CPU and RAM) and is capped by the largest hardware available, sometimes needing a restart. Scaling out (horizontal) adds more identical instances behind a load balancer and is the cloud-preferred path because it has no fixed ceiling. Shorthand: "bigger machine" = up, "more machines" = out.

Trap Confusing scaling up with scaling out, since up resizes a single instance vertically while out adds more identical instances horizontally.

20 questions test this
Elasticity is automatic, demand-driven scaling

Elasticity is scaling that happens automatically as load rises and falls, with no manual intervention, delivered through autoscale on services like Virtual Machine Scale Sets and the Web Apps feature of Azure App Service. Autoscale is horizontal only: it adds and removes instances, never resizes one, and triggers on metrics (CPU, queue length) or a schedule. The signal is "automatically handle spikes" or "scale in when traffic drops."

Trap Treating autoscale as vertical scaling: it scales out and in by instance count, it does not give a single machine more CPU or memory.

25 questions test this
Consumption pricing means you pay only for what you use

The consumption-based (pay-as-you-go) model charges you only for the resources you actually consume, with no upfront capital outlay, so elastic autoscaling lets you avoid provisioning (and paying) for a rare worst-case peak. This is the financial benefit that pairs with elasticity: capacity follows demand, and so does the bill.

Trap Treating consumption pricing as a capital expense, since pay-as-you-go is an operational expense (OpEx) with no upfront CapEx outlay.

12 questions test this
Reliability is recovering from failure, not just avoiding it

Reliability is a system's ability to be resilient (withstand faults), recoverable (restore within agreed targets after a disruption), and available, one of the five pillars of the Azure Well-Architected Framework. It is broader than HA: reliability also covers recovering through backup and regional failover after a failure, not only staying up. The five pillars are Reliability, Security, Cost Optimization, Operational Excellence, and Performance Efficiency.

Trap Equating reliability with high availability alone, when reliability also covers recovering through backup and failover after a disruption, not just avoiding downtime.

3 questions test this
Performance predictability uses autoscale and load balancing

Performance predictability keeps the user experience consistent as load changes, achieved with autoscale (add capacity on demand) and load balancing (spread traffic so no single instance is overwhelmed). The signal is "consistent response times during a traffic surge." It is the performance half of predictability, distinct from cost predictability.

Trap Answering cost predictability when the stem is about consistent response times under load, which is the performance half, not the spend-forecasting half.

Cost predictability uses the Pricing Calculator and Cost Management

Cost predictability is forecasting and tracking spend accurately, using the Pricing Calculator (a free, unauthenticated tool to estimate a planned deployment before anything is provisioned) and Microsoft Cost Management (track and analyze actual spend after deployment, with budgets and alerts). On-premises-vs-Azure TCO comparison now runs through the Azure Migrate business case feature. Signal: "estimate monthly cost before deploying" → Pricing Calculator; "forecast and track the bill" → Cost Management.

Trap Reaching for the Total Cost of Ownership (TCO) Calculator: Microsoft has retired the standalone TCO Calculator, and on-prem-vs-Azure cost analysis now lives in Azure Migrate.

2 questions test this
Predictability splits into performance and cost

AZ-900 tests predictability as two distinct halves: performance predictability (consistent experience under load) and cost predictability (forecastable, trackable spend). A single "predictability" answer can be wrong if the stem is actually about the other half: read whether it is about performance or spend before answering.

The cloud's security benefit is defense in depth

Defense in depth layers multiple overlapping protections (physical, identity, network, application, data) so breaching one layer does not compromise the whole system. As a cloud benefit it means you inherit Microsoft's continuously updated security investment across the lower layers rather than building every layer yourself.

The shared responsibility model splits security duties by deployment type

Under the shared responsibility model Microsoft always secures the physical hosts, network, and datacenters, while you always retain responsibility for your data, identities, accounts, and access management, regardless of whether the workload is IaaS, PaaS, or SaaS. Responsibility for the OS, network controls, and applications shifts toward Microsoft as you move IaaS → PaaS → SaaS. Cloud security is a benefit because Microsoft owns the layers you cannot.

Trap Assuming the cloud provider is responsible for securing your data and identities, when those always stay your responsibility across IaaS, PaaS, and SaaS.

3 questions test this
Defender for Cloud centralizes security posture and threat protection

Microsoft Defender for Cloud continuously assesses your posture and rolls it into a Secure Score that rises as you remediate its recommendations, and adds threat protection across Azure, hybrid, and multicloud resources. Its free Foundational CSPM tier covers Secure Score and recommendations; paid Defender plans add workload threat protection (CWPP). It is the centralized tooling that operationalizes the cloud's security benefit (formerly Azure Security Center).

Trap Confusing Defender for Cloud with Microsoft Sentinel, when Defender assesses posture and Secure Score while Sentinel is the cloud-native SIEM for security event analytics.

The governance benefit is enforcing standards at scale

Governance is applying organizational standards and staying compliant across many resources without manual, per-resource effort. The AZ-900 signal is "ensure every team follows company standards" or "deploy a compliant environment repeatedly": about standardizing and enforcing rules, not about protecting against attackers (that is security).

Trap Picking security when the stem is about enforcing company standards, since governance standardizes and enforces rules while security protects against attackers.

Azure Policy audits and enforces organizational rules

Azure Policy enforces organizational standards and assesses compliance at scale (for example "allow only approved regions" or "require a tag") evaluating resources against business rules and applying effects that audit (flag) or deny (block) non-compliant ones. It is the governance enforcement service the exam pairs with compliance and consistency scenarios. Group related policies into an initiative to assign them as one unit.

Trap Picking Azure RBAC for compliance: RBAC controls who can perform actions, while Azure Policy controls whether the resulting resource state is allowed.

Templates and IaC deploy compliant baselines repeatably

ARM templates (and Bicep) define infrastructure as code so a compliant configuration deploys identically every time, delivering governance by making standard setups reproducible. Azure Blueprints packaged policies, role assignments, and templates into a reusable environment baseline, but it is a Preview service deprecating July 11, 2026. Microsoft directs customers to Template Specs and Deployment Stacks, and Azure Policy is the current AZ-900 governance enforcement tool.

Trap Reaching for Azure Blueprints as the current governance tool, when it is a deprecating Preview service and Azure Policy is the present-day enforcement service.

10 questions test this
Security protects; governance standardizes

Security is about protecting resources (defense in depth, Defender for Cloud); governance is about standardizing and enforcing rules (Azure Policy). "Block deployments outside approved regions" is governance, not security: a common AZ-900 discriminator that hinges on whether the stem is about threat protection or about consistency/compliance.

Manageability splits into 'of' and 'in' the cloud

Manageability has two halves the exam distinguishes: management of the cloud (the platform manages itself for you: autoscale, automatic provisioning, self-healing, monitoring) and management in the cloud (the tools you use to configure and operate resources). Read which side a stem is testing before choosing.

Management OF the cloud is the platform working for you

Management of the cloud is the platform doing work automatically on your behalf: autoscale, automatic resource provisioning, self-healing (automatic recovery of unhealthy resources), and continuous monitoring of resource health. You get the benefit without performing the work: it is the automated, platform-side half of manageability.

Trap Confusing management of the cloud with management in the cloud, since 'of' is the platform acting automatically for you while 'in' is the tools you operate yourself.

1 question tests this
Management IN the cloud spans portal, CLI, PowerShell, and IaC

Management in the cloud is the toolset you use to operate resources: the Azure portal (graphical web UI) for ad-hoc work, Azure CLI and Azure PowerShell for command-line scripting and automation, the Azure mobile app, and ARM/Bicep templates for repeatable infrastructure as code. Match the tool to the job: portal for one-off changes, CLI/PowerShell for automation, templates for reproducible deployments.

Trap Treating autoscale or self-healing as management in the cloud, when those are management of the cloud and 'in' is the tooling you operate yourself.

Cost predictability is not the same as cost savings

Cost predictability is forecasting and tracking spend reliably; it is distinct from the cost savings benefit (the CapEx-to-OpEx shift and pay-as-you-go pricing). Match "forecast the bill" or "track where spend goes" to the cost tools, not to a generic "the cloud is cheaper" claim.

Trap Choosing cost savings when the stem is about forecasting and tracking spend, since that is cost predictability rather than the CapEx-to-OpEx savings benefit.

Availability and scalability are distinct benefits

Because both often use multiple instances, AZ-900 offers high availability and scalability as competing answers. Anchor on the goal: staying up through a failure = availability; having enough capacity for demand = scalability. Good designs combine them, but the exam tests them as separate benefits.

Scale sets build every VM from one base image

Virtual Machine Scale Sets create all instances from the same base OS image and configuration, eliminating configuration drift and letting you manage hundreds of identical VMs without per-machine setup. They are also the foundation for autoscale, illustrating the manageability benefit of treating many machines as one managed pool.

6 questions test this
ARM deploys independent resources in parallel

Azure Resource Manager orchestrates a template by deploying resources that have no dependencies in parallel while still creating interdependent resources in the correct order. This parallel orchestration finishes multi-resource deployments faster than running serial, imperative commands, and you trigger it with a single command.

5 questions test this
ARM templates are declarative, version-controlled IaC

ARM templates use declarative syntax: you state the desired end state of your resources and Azure works out how to reach it, instead of writing step-by-step commands. Because the template is code (a JSON file), teams store it in source control to version, review, and roll back infrastructure changes like application code.

Trap Calling ARM templates imperative, when declarative syntax states the desired end state rather than the step-by-step commands to reach it.

13 questions test this
ARM templates are idempotent

ARM templates are idempotent: deploying the same template repeatedly yields the same resource types in the same state. If a resource with the specified properties already exists, no change is made. This gives repeatable, consistent results, so identical infrastructure can be reproduced across dev, test, and production from one template.

7 questions test this
ARM templates integrate with CI/CD pipelines

ARM templates plug into continuous integration and continuous deployment tools such as Azure Pipelines and GitHub Actions, automating release pipelines for fast, reliable infrastructure updates. This supports the agility benefit: responding quickly to changing requirements by shipping infrastructure changes through the same automated pipeline as code.

6 questions test this
Azure Backup recovers data from the cloud

Azure Backup backs up Azure VMs, files, Azure Files, databases, and on-premises workloads into a Recovery Services vault, guarding against accidental deletion, corruption, and ransomware. It runs at cloud scale with no on-premises backup infrastructure to maintain, automatically managing backup storage on a pay-as-you-use model. It is the recovery side of reliability: restoring data, distinct from availability's goal of avoiding downtime.

Trap Confusing Azure Backup with Azure Site Recovery, when Backup restores data from a vault and Site Recovery replicates and fails over workloads to keep them running.

5 questions test this
Geo-redundant storage copies data to a far-away paired region

Geo-redundant storage (GRS) first replicates data within the primary region, then copies it asynchronously to a secondary paired region hundreds of miles away, protecting against a full regional outage or disaster. GRS is the default and recommended option for a Recovery Services vault. Choose it when data must survive the loss of an entire region; contrast with LRS (one datacenter) and ZRS (across zones in one region).

Trap Relying on locally redundant storage (LRS) for disaster recovery. LRS keeps all copies in a single datacenter and won't survive a regional outage.

6 questions test this
Cost Management analyzes spend at no separate charge

Microsoft Cost Management is a native suite of FinOps tools to analyze, monitor, and optimize Azure spend, available to anyone with billing, subscription, resource-group, or management-group access at no additional charge to use the tooling itself. Its Cost analysis breaks spend down by service, location, subscription, resource group, or tag so you can see exactly where costs originated, and it supports budgets and cost alerts.

Trap Reaching for the Pricing Calculator to track actual spend, when that tool only estimates planned cost before deployment and Cost Management analyzes spend after deployment.

7 questions test this

Also tested in

References

  1. https://learn.microsoft.com/en-us/training/modules/describe-benefits-use-cloud-services/
  2. https://learn.microsoft.com/en-us/azure/reliability/availability-zones-overview
  3. https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview
  4. https://learn.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-overview
  5. https://learn.microsoft.com/en-us/azure/well-architected/reliability/
  6. https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview
  7. https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/overview-cost-management
  8. https://azure.microsoft.com/en-us/pricing/calculator/
  9. https://azure.microsoft.com/en-us/pricing/tco/calculator/
  10. https://learn.microsoft.com/en-us/azure/migrate/concepts-business-case-calculation
  11. https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
  12. https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction
  13. https://learn.microsoft.com/en-us/azure/governance/policy/overview
  14. https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/overview
  15. https://learn.microsoft.com/en-us/azure/governance/blueprints/overview
  16. https://learn.microsoft.com/en-us/azure/azure-portal/azure-portal-overview
  17. https://learn.microsoft.com/en-us/cli/azure/what-is-azure-cli
  18. https://learn.microsoft.com/en-us/powershell/azure/what-is-azure-powershell