Use this for last-mile review. AZ-900 is mostly a classification exam: is the clue about a cloud concept, an Azure service family, or a management and governance control? The right answer usually stays at the right abstraction level instead of diving into implementation detail too early.
Shared responsibility model: Security split where Microsoft secures the cloud platform while the customer still secures identities, data, configurations, and workloads they control.
Private Endpoint: Private IP path from a VNet to a PaaS service.
RBAC: Azure authorization model that answers who can do what at a given scope.
Fast lane picker
| If the question is really about… |
Focus first on… |
Strongest first move |
| cloud vocabulary or responsibility |
IaaS, PaaS, SaaS, public/private/hybrid |
identify the model before naming the service |
| Azure infrastructure layout |
regions, zones, region pairs, resource hierarchy |
choose the right geography or scope boundary |
| service families |
compute, networking, storage, database, identity |
stay at the product-category level first |
| permissions or compliance |
RBAC, Policy, locks, tags, Cost Management |
decide whether the clue is about access, allowed configuration, or spend |
| billing, discounts, or SLA |
pricing tools, reservations, redundancy, availability math |
translate the cost or uptime clue before choosing a product |
AZ-900 classification order
flowchart TD
A["Read the clue"] --> B["Is it concept, service family, or governance/cost?"]
B --> C["Pick the Azure category first"]
C --> D["Choose the broadest correct service or control"]
AZ-900 answer sequence
Use this when the stem mixes cloud model, service family, governance, or pricing.
flowchart TD
S["Scenario"] --> C["Classify the clue"]
C --> M["Pick the Azure category first"]
M --> G["Check governance or boundary"]
G --> P["Check pricing or SLA fit"]
What to notice:
- AZ-900 usually wants the service family or control category, not deep implementation steps
- the more technical-sounding option is often wrong if the question is still conceptual
- governance and pricing tools appear often because they are easy to confuse with access or resource features
Cloud model chooser
| Model |
You manage |
Provider manages |
Strong exam cue |
| IaaS |
OS, runtime, apps, data |
datacenter, physical hardware, core platform |
need OS control or lift-and-shift |
| PaaS |
apps and data |
OS, runtime, patching, most platform ops |
reduce ops burden |
| SaaS |
your data and access choices |
almost everything else |
use the finished product, not the platform |
| Pair |
Keep this distinction clear |
| public vs private cloud |
provider-hosted shared cloud vs dedicated environment for one organization |
| hybrid vs multicloud |
on-prem plus cloud vs multiple public clouds |
| scalability vs elasticity |
ability to grow vs ability to grow and shrink with demand |
| high availability vs resiliency |
staying up through component failure vs recovering well from failure |
| CapEx vs OpEx |
upfront purchase vs pay-as-you-go operating spend |
Azure boundary map
flowchart TD
MG["Management group"] --> SUB["Subscription"]
SUB --> RG["Resource group"]
RG --> RES["Resource"]
| Boundary |
What it is for |
| tenant |
identity boundary for users, groups, and apps |
| management group |
organize subscriptions for governance at scale |
| subscription |
billing and quota boundary |
| resource group |
lifecycle container for related resources |
| resource |
actual Azure service instance |
Global infrastructure chooser
| Requirement |
Strongest first fit |
Why |
| keep data in a particular country or geography |
choose the right region / geography |
residency and latency start here |
| protect against datacenter failure inside one region |
availability zones |
zone separation improves in-region resilience |
| protect against regional failure |
multi-region pattern / region pair thinking |
cross-region resiliency |
| basic regional deployment decision |
choose the right region first |
latency and compliance often matter before SKU details |
Core Azure service-family chooser
| Requirement |
Strongest first fit |
Why |
| full OS control |
Virtual Machines |
highest control, highest ops |
| managed web app or API |
App Service |
managed hosting and scaling |
| event-driven code |
Azure Functions |
trigger-based compute |
| simple container run |
Container Instances |
low-friction container hosting |
| Kubernetes orchestration |
AKS |
container orchestration layer |
| private network in Azure |
VNet |
core network boundary |
| allow/deny network traffic at subnet or NIC |
NSG |
basic network filtering |
| encrypted internet tunnel to Azure |
VPN Gateway |
internet-based private path |
| private dedicated connectivity |
ExpressRoute |
dedicated enterprise connectivity |
| private IP path to PaaS |
Private Endpoint |
private service consumption |
| global edge routing and WAF/CDN style entry |
Front Door |
global L7 entry |
| regional L7 ingress |
Application Gateway |
app-layer routing in-region |
| simple L4 traffic distribution |
Load Balancer |
TCP/UDP balancing |
Storage and data chooser
| Need |
Strongest first fit |
| object storage |
Blob Storage |
| shared SMB file access |
Azure Files |
| VM block storage |
managed disks |
| global low-latency NoSQL |
Cosmos DB |
| managed relational database |
Azure SQL Database |
| managed open-source relational |
Azure Database for PostgreSQL / MySQL |
Redundancy and storage tier quick rules
| Option |
Protects against |
Quick rule |
| LRS |
local hardware/rack failure |
cheapest, single datacenter |
| ZRS |
zone or datacenter failure |
better in-region resilience |
| GRS |
regional disaster with asynchronous copy |
paired-region protection |
| GZRS |
zone plus regional failure patterns |
strongest mix of zone and region coverage |
| RA-GRS / RA-GZRS |
readable secondary |
adds secondary read capability |
| Blob tier |
Best for |
| Hot |
frequent access |
| Cool |
infrequent access |
| Archive |
rare access and long retention |
Identity, governance, and protection chooser
| Requirement |
Strongest first fit |
Why |
| user or admin permission to manage resources |
RBAC |
authorization model |
| require tags or restrict allowed regions/SKUs |
Azure Policy |
compliance and configuration guardrails |
| prevent accidental deletion or modification |
resource lock |
safety control |
| secure secrets, certificates, or keys |
Key Vault |
secure secret and key storage |
| security recommendations and posture view |
Defender for Cloud |
posture and hardening guidance |
| outage notifications and planned maintenance visibility |
Service Health |
Azure incident visibility |
| cost visibility and budgets |
Cost Management |
spend tracking and alerts |
| Pair |
Keep this distinction clear |
| authentication vs authorization |
prove identity vs decide permission |
| RBAC vs Policy |
who can act vs what configurations are allowed |
| Policy vs lock |
compliance rule vs deletion/change protection |
| Service Health vs Azure Monitor |
Azure platform incidents vs your resource telemetry |
Pricing and cost chooser
| Need |
Strongest first tool or concept |
| estimate a future Azure design |
Pricing calculator |
| compare on-prem vs Azure economics |
TCO calculator |
| analyze spend, set budgets, and alert on overruns |
Cost Management |
| steady predictable usage discount |
reservation |
| flexible compute spend discount |
savings plan for compute |
| fault-tolerant low-priority compute |
Spot |
| Common cost driver |
What usually changes the bill |
| compute |
size, hours, scale pattern, reservation status |
| storage |
amount stored, redundancy, access tier, operations |
| networking |
egress, gateways, load balancing |
| licensing |
OS or SQL licensing, hybrid benefit |
SLA and lifecycle quick rules
| SLA |
Approximate downtime per month |
| 99% |
about 7 hours 18 minutes |
| 99.9% |
about 43 minutes |
| 99.95% |
about 22 minutes |
| 99.99% |
about 4 minutes |
| Stage |
What it implies |
| Preview |
limited SLA and support expectations may apply |
| GA |
normal SLA and support expectations |
Fast scenario pickers
| Scenario clue |
Strongest first answer |
| store connection strings or rotate secrets |
Key Vault |
| require all resources to have tags |
Azure Policy |
| prevent deletion of production resource |
lock |
| private access to PaaS |
Private Endpoint plus correct DNS |
| connect on-prem privately to Azure |
ExpressRoute |
| estimate cost of proposed design |
Pricing calculator |
| compare on-prem total cost to cloud |
TCO calculator |
| find outages and planned maintenance |
Service Health |
| give a team access to manage a resource group |
RBAC at that scope |
Last 15-minute review
| Review this |
Because it fixes… |
| IaaS vs PaaS vs SaaS |
responsibility-model confusion |
| region vs availability zone vs region pair |
infrastructure-boundary confusion |
| management group -> subscription -> resource group -> resource |
Azure hierarchy misses |
| VM vs App Service vs Functions vs AKS |
compute-family distractors |
| RBAC vs Policy vs locks |
governance-control confusion |
| redundancy options and blob tiers |
storage and resilience mistakes |
| pricing calculator vs TCO vs Cost Management |
billing-tool confusion |
What strong answers usually do
- distinguish cloud concepts from Azure-specific services
- choose the broadest correct Azure service family rather than an overly detailed implementation
- separate permissions, compliance, and cost controls cleanly
- remember that AZ-900 is conceptual first, even when product names appear