AZ-900 sample questions — 25 answered and explained

Even in SaaS, the customer remains responsible for its information and data.

SaaS hands the provider the most responsibility: the physical layer, the operating system and the application. What never moves is the customer's information and data, along with its devices and its accounts and identities. Patching the OS and updating the app are the provider's jobs in SaaS, and the datacenter network is the provider's in every model.

1. Identify the service type: SaaS, where the provider runs the most.
2. Remove the tasks the provider owns in SaaS: OS, application, physical network.
3. What remains is the customer's data.

Exam tip: Whatever the service type, you keep responsibility for your own data.

In IaaS the customer manages and patches the operating system.

Operating systems are one of the responsibilities that move with the service type. IaaS puts the most responsibility on the customer: the provider covers physical security, power and connectivity, and the customer manages the OS upward. In PaaS and SaaS the provider takes over the OS, which is why "Microsoft" tempts candidates who think of all Azure services the same way.

1. Identify the service type: IaaS virtual machines.
2. Recall that the OS is a layer whose owner varies with the service type.
3. In IaaS that layer, including patching, is the customer's.

Exam tip: IaaS: you patch the OS. PaaS and SaaS: the provider does.

A public cloud is provider-owned and shared by many organizations.

The public cloud is owned and operated by a provider and shared across many customers over the internet, offering the lowest up-front cost. Private is single-tenant, hybrid is a mix, and on-premises is customer-run, so none match a shared provider environment.

1. Note the clues: provider-owned and shared across many organizations.
2. Match shared, provider-owned to public cloud.
3. Eliminate private (dedicated), hybrid (mix), and on-premises (self-run).

Exam tip: The public cloud is provider-owned and shared across many organizations with the lowest up-front cost.

A private cloud is dedicated to a single organization and suits strict compliance requirements.

A private cloud is used by one entity, whether hosted on-site or in a dedicated offsite datacenter, and gives complete control over resources and security, with data not collocated with other tenants. The agency needs all systems on dedicated hardware, so hybrid (part public) and multicloud (several public providers) both break the requirement.

1. Spot the requirement: all systems on dedicated, single-tenant hardware.
2. Match single-organization hardware to a private cloud.
3. Reject models that place any workload on shared public hardware.

Exam tip: Dedicated to one organization for strict compliance points to a private cloud.

A hybrid cloud connects private infrastructure with a public cloud.

Hybrid is the combination of a public and a private cloud in an interconnected environment, letting the organization choose which services stay private. Multicloud is the tempting near-twin, but it means using more than one public cloud provider; this hospital uses one public cloud (Azure) and its own private infrastructure.

1. Count the environments: private infrastructure plus one public cloud.
2. Note they are connected.
3. Distinguish public + private (hybrid) from several public providers (multicloud).

Exam tip: Public + private, connected = hybrid. Several public providers = multicloud.

The public cloud gives the lowest up-front cost and fastest scale.

A startup wanting minimal up-front cost and rapid, very large scale without owning hardware is a natural fit for the public cloud. Private has the highest cost and limited scale, hybrid adds private infrastructure, and on-premises requires buying hardware.

1. Identify the needs: lowest up-front cost, fast very large scale, no hardware.
2. Match those needs to the public cloud.
3. Eliminate models that add cost, hardware, or limited scale.

Exam tip: Lowest up-front cost and fast, very large scale with no hardware points to the public cloud.

Consumption-based pricing removes the need to provision for peak and pay for idle capacity.

Microsoft Learn lists the consumption model's benefits as no up-front hardware costs, no paying for capacity that goes underused, and the ability to add and release resources as demand changes. The retailer's problem is exactly peak-sized, mostly idle hardware; the fixed fee and year-ahead reservation both keep paying for the peak, and a private cloud keeps owning it.

1. Identify the problem: buying for the peak leaves capacity idle.
2. Recall that consumption billing follows actual demand.
3. Reject options that still pay for, or own, peak capacity all year.

Exam tip: Consumption-based billing: scale up for the peak, scale back after, pay only for what you use.

Availability zones protect against a datacenter failure without leaving the region.

Two constraints decide it: survive a datacenter failure, and stay in one region. Spreading VMs across availability zones meets both. A single zone fails with its datacenter, an availability set only protects against rack-level faults inside a datacenter, and the paired region would survive the failure but breaks the one-region policy.

1. Identify the failure scope: one datacenter.
2. Identify the location constraint: stay in one region.
3. Choose the option spanning datacenters but not regions: multiple availability zones.

Exam tip: One datacenter failing, same region: spread across availability zones. Whole region failing: use another region.

A resource lives in exactly one resource group, and groups can't be nested.

Every resource must belong to exactly one resource group, resource groups cannot contain other resource groups, and many resources can be moved between groups. So the account sits in one project's group and can be moved later; sharing it between groups, nesting, or leaving it outside a group are all impossible.

1. Recall: one resource, one resource group.
2. Recall: no nested resource groups and no resources outside a group.
3. Moving between groups is allowed, so pick the one-group-but-movable option.

Exam tip: A resource is in exactly one resource group at a time; groups don't nest, but resources can move.

Separate subscriptions give separate invoices.

The subscription is the billing boundary, so splitting the environments into two subscriptions splits the invoices. The tempting near-twin is one subscription with tags or resource groups: that helps you analyze costs, but it is still one subscription's bill. Regions and management groups do not change the billing boundary.

1. The goal is separate invoices, not separate cost reports.
2. Billing follows the subscription.
3. Anything that keeps one subscription keeps one bill.

Exam tip: Separate cost reports: tags or resource groups. Separate invoices: separate subscriptions.

Each subscription and management group has exactly one parent.

A management group tree allows only one parent per subscription (and per management group), so the subscription must be moved, and inheritance then follows its new parent. Dual membership and copies aren't possible, and the root group passes down only what is assigned at the root, not what a sibling group like Marketing holds.

1. Recall: one parent per subscription.
2. Inheritance flows only from a subscription's own ancestors.
3. So moving changes which group's settings it inherits.

Exam tip: One parent per subscription: to inherit a different management group's settings, move the subscription.

Region pairs receive planned updates sequentially to limit the impact of a faulty update.

Microsoft staggers planned system updates across region pairs to minimise the impact of a bug or faulty update and to avoid downtime for solutions designed to use both regions together. The distractors sound like resilience features but are false: pairs give no automatic failover, capacity is not shifted between them, and replication is not what sets the update order.

1. Recall what update sequencing protects against: a faulty update.
2. Updating one region at a time keeps the other healthy if an update goes wrong.
3. Reject claims of automatic failover or shared capacity, which pairs do not provide.

Exam tip: Region pairs are updated one region at a time so a bad update can't take both down.

Sovereign regions include Azure Government and Azure operated by 21Vianet.

Sovereign regions are separate instances of Azure isolated from the global cloud: Azure Government in the US and Azure operated by 21Vianet in China. The distractors all sound isolated or national (dedicated hardware, an on-premises Azure extension, a public region in one country) but each still belongs to the global public cloud or to the customer.

1. Recall the sovereign examples: Azure Government and Azure operated by 21Vianet.
2. Dedicated hardware or a national public region is still the global cloud.
3. An on-premises Azure extension is hybrid, not a sovereign region.

Exam tip: Sovereign = a separate Azure cloud (Azure Government, Azure operated by 21Vianet), not isolated hardware in a public region.

Availability zones are separate datacenters within a region that protect against datacenter failure.

Zones are physically separate datacenters inside one region and keep an app running if one datacenter fails, so those two statements are correct. Region-pair disaster recovery, sovereign compliance isolation, and resource grouping describe different concepts entirely.

1. Recall the zone definition: separate datacenters in one region.
2. Recall the zone purpose: survive a single datacenter failure.
3. Reject region-pair, sovereign-region, and resource-group descriptions.

Exam tip: Zones are separate in-region datacenters that guard against a datacenter failing.

Region pairs give sequential updates and a target for some services' geo-replication.

Two behaviours hold for region pairs: Microsoft rolls planned updates out to one region of a pair at a time, and some services such as geo-redundant storage replicate to the pair. Pairs are almost always within one geography, many newer regions are not paired at all, a pair is two regions rather than two zones, and simply deploying to a paired region does not give automatic failover.

1. Recall the pair benefits: sequential updates, recovery prioritisation, same-geography residency.
2. Recall that only some services replicate to the pair automatically.
3. Reject the cross-geography, zones-as-pair and automatic-failover claims.

Exam tip: Region pairs: updates one at a time and some services replicate to the pair, but no automatic failover for your app.

Resource groups are logical containers with delete-as-a-unit behavior and can span regions.

Deleting a resource group removes everything inside it, and the resources it holds can live in different regions because the group is logical. It is not the billing boundary (that is the subscription), cannot be nested inside another resource group, and does not organize subscriptions (that is a management group).

1. Recall that a resource group is deleted as a single unit.
2. Recall that its resources can span regions.
3. Reject billing, nesting, and subscription-organizing claims.

Exam tip: Resource groups delete as a unit and can hold resources from different regions.

Subscriptions are access and quota boundaries, and an account can have many.

A subscription is a billing and access control boundary where some limits and quotas are enforced, and organizations commonly create several subscriptions to separate environments, departments or projects. Management groups sit above subscriptions, subscriptions are not tied to a region, and a subscription can hold many resource groups.

1. Recall the subscription's boundaries: billing, access, quotas.
2. Recall that accounts routinely have several subscriptions.
3. Reject the reversed hierarchy, the regional claim, and the single-group claim.

Exam tip: Subscriptions bound billing, access and quotas, span regions, and an account can have many.

Budgets in Cost Management raise alerts when spend reaches thresholds you set.

A budget defines a spending amount for a scope such as a subscription or resource group, and its alert conditions email recipients when actual spend reaches a percentage you choose, such as 80 percent. Credit alerts are generated automatically for Enterprise Agreement prepayment balances, cost analysis views only display data, and Advisor recommendations suggest savings without tracking a threshold.

1. Identify the need: an email at a custom percentage of an amount.
2. Match a threshold you define to a budget with an alert.
3. Rule out credit alerts (EA prepayment), saved views and recommendations.

Exam tip: Want a warning at a spending threshold you choose? Create a budget with an alert.

Pricing calculator: estimate before deployment. Cost Management: actual spend after deployment.

The two tools sit at opposite ends of the deployment timeline. The pricing calculator models a configuration you enter and provisions nothing; Cost Management reads real usage to analyze, budget and alert on spend. The reversed statement swaps them, and the two "both" statements give each tool the other's data source.

1. Anchor on timing: before versus after deployment.
2. Assign estimating to the calculator and reporting to Cost Management.
3. Reject the reversed and the same-for-both statements.

Exam tip: Estimate with the pricing calculator; track real spend with Cost Management.

Consumption drives cost: you pay for how much you run during the billing cycle.

Under pay-as-you-go you pay for what you use in each billing cycle, and a deallocated VM stops accruing compute charges, so the VM that runs all night consumes more. Maintenance is the tempting near-twin, but it describes resources that keep billing after you stop needing them, such as disks left after a VM is deleted; both VMs here are still in use. Geography and subscription type are the same for both.

1. List what is identical: size, region, subscription.
2. Find the variable that differs: hours running before deallocation.
3. Distinguish running time (consumption) from leftover resources (maintenance).
4. Choose consumption.

Exam tip: More running time means more consumption, and more cost.

Azure savings plan for compute: a flexible hourly-spend commitment across eligible compute services.

A savings plan commits you to a fixed hourly amount of compute spend for one or three years, and Azure applies the discounted price to eligible compute usage wherever it runs, including different VM families and Container Instances. A reservation is also a one- or three-year commitment, but to specific capacity, so it stops matching when the workload changes shape. Spot and pay-as-you-go carry no commitment discount.

1. Note the constraints: steady spend, shifting services, commitment discount wanted.
2. Narrow to the two commitment options.
3. Pick the one that follows usage across services: the savings plan.

Exam tip: Steady spend that shifts between compute services: savings plan for compute.

Tags let cost analysis allocate spend when the resource hierarchy does not match ownership.

Cost analysis can group by subscription, resource group, service, region or tag. Here the subscription and the resource groups are both shared, so neither boundary matches a department. A consistent CostCenter tag on each resource gives cost analysis the ownership dimension it needs. Budgets alert on a scope's spend but do not split it between owners.

1. Check whether an existing boundary matches ownership: subscriptions and resource groups are shared.
2. Recall that cost analysis can also group by tag.
3. Apply a consistent tag that carries the department.

Exam tip: When groups and subscriptions are shared, tags are what allocate cost to owners.

Subscription type is a cost factor: some subscriptions include usage allowances or credit.

Subscription type affects cost because some subscription offers carry usage allowances; the Azure free account, for example, includes credit for the first 30 days and some products free for 12 months. The workloads and region are identical, so consumption and geography do not differ. Maintenance is about leftover resources that keep billing, and Azure Marketplace adds vendor billing rather than credit.

1. Note what is identical: region and workload.
2. Identify what differs: credit and free products attached to the offer.
3. Match offer-level allowances to subscription type.

Exam tip: Allowances and credit attached to the offer are the subscription-type cost factor.

Right-sizing matches resource size to actual need and removes wasted capacity.

Very low utilization means you are paying for capacity you do not use. Reservations, savings plans and a cheaper region all lower the price of that capacity, but only resizing removes it, which is what the stem asks for. Committing to a reservation before right-sizing would lock in the waste for the term.

1. Recognize the symptom: long-running VMs with very low utilization.
2. Separate lowering the price of capacity (commitments, cheaper region) from removing it.
3. Pick resizing to fit the actual load.

Exam tip: Right-size first, then commit: discounting oversized VMs still pays for waste.

Region and outbound data transfer are cost factors; tags, resource groups and inbound transfer are not.

Region changes the rate for the same service, and data leaving Azure (egress) is billed. Data arriving from the internet is the near-twin that catches candidates: inbound transfer is generally free. Tags and resource groups are free organizational constructs and do not change price.

1. Recall the factors: resource type, consumption, maintenance, geography, network traffic, subscription type, Marketplace.
2. Split network traffic by direction: outbound billed, inbound generally free.
3. Select region and outbound transfer; reject free metadata and containers.

Exam tip: Region and egress cost money; tags, resource groups and inbound data do not.