AZ-900 Practice Test Bank: 200+ Questions & Detailed Answers

Section 1.1: What AZ-900 measures (official domains overview)

AZ-900 questions are built around the official skills measured, which Microsoft periodically updates. You should always cross-check the current domain weights on Microsoft Learn, but your study strategy stays stable: master the fundamentals and learn to classify scenarios. Expect the exam to test recognition (“Which service does X?”), conceptual understanding (“What is high availability?”), and governance basics (“Which tool enforces standards?”) more than command-line steps.

At a high level, you will be assessed on: cloud concepts (public/private/hybrid, cloud benefits, shared responsibility); core Azure architecture and services (regions, region pairs, subscriptions, resource groups, compute options); Azure networking and storage fundamentals (VNets, VPN/ExpressRoute concepts, storage types and redundancy); Azure identity, access, and security (Microsoft Entra ID basics, authentication vs authorization, RBAC); and Azure management and governance (cost management concepts, SLAs, support plans, and governance tools like Policy and Blueprints—note Blueprints is less emphasized now, but the governance intent matters).

Exam Tip: Train yourself to answer two questions before choosing an option: “Is this a concept question or a service-identification question?” and “Is the scope subscription-level, resource-group-level, or resource-level?” Many wrong answers are correct facts but at the wrong scope.

• Common trap: Confusing Azure regions (geographic areas) with availability zones (separate datacenters within a region) and with geographies (compliance boundary).
• Common trap: Treating RBAC (who can do what) as the same as Azure Policy (what is allowed to be deployed/configured).
• Common trap: Mixing compute categories: VMs (IaaS) vs App Service (PaaS) vs Functions (serverless) vs Containers (AKS/ACI).

In practice, the exam rewards clean categorization. If you can quickly label a requirement as “identity,” “governance,” “networking,” “storage,” or “compute,” you’ll narrow choices fast and reduce time pressure.

Section 1.2: Registration, scheduling, and exam policies

Registration and scheduling are straightforward, but avoid last-minute surprises. You schedule through Microsoft’s certification dashboard and choose either online proctored delivery or a test center. Both are valid; pick based on your environment and anxiety triggers. Online proctoring is convenient but less forgiving: you must meet room, ID, and system requirements, and violations can end the exam.

For online delivery, prepare a quiet room, clear desk, stable internet, and a compliant computer. Close background apps and disable notifications. For test centers, arrive early with the required ID and follow the center’s rules (storage lockers, no personal items). Read the candidate agreement carefully—especially rules about breaks, talking aloud, and accessing external materials.

Exam Tip: Do a full system check and a “room rehearsal” 24–48 hours before your online exam. The #1 preventable failure mode is a technical/proctoring interruption, not lack of knowledge.

• Common trap: Assuming you can use scratch paper at home. Policies vary; the proctor may require a digital whiteboard instead.
• Common trap: Looking away from the screen repeatedly (notes, second monitor, phone). Proctors may interpret this as a policy violation.
• Common trap: Scheduling when you’re fatigued. AZ-900 is conceptual; mental clarity matters more than “cramming.”

Plan the logistics like an exam objective: your goal is an interruption-free session where you can apply your knowledge calmly and consistently.

Section 1.3: Scoring, passing, and time management

AZ-900 uses scaled scoring. You’ll see a score report at the end, and the passing threshold is typically 700 on a 1000-point scale. Don’t obsess over “points per question,” because the exam can weight questions differently and may include unscored items. Your controllable variable is accuracy on the core concepts and efficient pacing.

Time management is simpler than on role-based exams, but it still matters. Your aim is to keep moving, avoid getting stuck on one ambiguous item, and use review flags strategically. If a question is taking too long, it usually means you’re missing a key cue in the wording (for example, “best describes,” “most cost-effective,” or “minimize administrative effort”). Those phrases define the selection criteria.

Exam Tip: Use a two-pass approach. Pass 1: answer everything you’re confident about and flag uncertain items. Pass 2: resolve flags by eliminating options using scope (tenant/subscription/resource), service model (IaaS/PaaS/SaaS), and governance intent (audit vs enforce).

• Common trap: Reading the answers before fully reading the question. AZ-900 distractors often sound right until you notice a single constraint like “serverless,” “global,” or “within a region.”
• Common trap: Overengineering. If the requirement is basic (e.g., “store objects”), pick the basic service category (Blob storage) rather than a more advanced architecture pattern.

Your pacing goal is consistency: a steady rhythm that leaves time to re-check flagged items without rushing the final third of the exam.

Section 1.4: How to use this test bank (review loops and error logs)

A 200+ question test bank is not for “one-and-done” completion. It’s a diagnostic tool to reveal gaps in your mental model of Azure. The highest scores come from disciplined review loops: attempt, review, log mistakes, restudy, and retest. The goal is not to memorize answer letters; it’s to build fast pattern recognition for exam cues.

Use a simple error log with four columns: (1) domain/topic (e.g., networking, storage redundancy, RBAC vs Policy), (2) what you chose, (3) why it was wrong (misread constraint, confused service, wrong scope), and (4) the rule you’ll use next time. Your “rule” should be a one-sentence decision heuristic, such as: “If the question is about enforcing allowed SKUs/tags, think Azure Policy; if it’s about permissions, think RBAC.”

Exam Tip: Track mistakes by reason, not just by topic. Most AZ-900 misses fall into a few repeatable categories: terminology confusion, scope confusion, and misinterpreting ‘best/most’ qualifiers.

• Loop 1 (baseline): mixed set across all domains to identify weak areas.
• Loop 2 (targeted): focused sets on your weakest two domains until accuracy stabilizes.
• Loop 3 (timed): simulate exam pace to practice calm decision-making.

Finish each loop by restating concepts out loud in your own words (for example: “An availability zone increases resiliency within a region; region pairs support disaster recovery planning”). This converts passive recognition into usable exam recall.

Section 1.5: Exam-style question formats (MCQ, caselets, true/false)

AZ-900 commonly uses multiple-choice questions (single best answer), multi-select (choose two/three), and true/false or yes/no statements. You may also see short scenario “caselets” where a brief description sets context and then asks one or more questions based on it. The format matters because it changes how you eliminate distractors.

For single-answer MCQs, your job is to find the best match, not merely something that is “also true.” For multi-select, treat each option like its own mini true/false: does it satisfy the requirement as stated? Avoid assuming that “more selections means more correct.” On yes/no or true/false, read for absolute words (“always,” “only,” “must”)—these often indicate a false statement unless it’s a definitional fact.

Exam Tip: In scenario questions, underline (mentally) the constraints: cost priority, performance priority, management overhead, compliance boundary, or resiliency goal. Those constraints map directly to Azure choices (e.g., “minimize admin” nudges toward PaaS/serverless; “full control” nudges toward IaaS).

• Common trap: Confusing similar terms in answer options (e.g., “authentication” vs “authorization,” “availability set” vs “availability zone”).
• Common trap: Ignoring the verb: “monitor” points to Azure Monitor; “govern/enforce” points to Policy; “assign permissions” points to RBAC.
• Common trap: Misreading multi-select instructions (choose two vs choose all that apply). Slow down for the instruction line.

Practice with intent: after each question, explain why each wrong option is wrong. That skill is exactly what you need when the exam presents two plausible answers.

Section 1.6: Foundational glossary and quick-start Azure terminology

AZ-900 is a terminology-heavy exam. If you can fluently define a small set of foundational terms, you’ll immediately improve your accuracy across all domains—cloud concepts, Azure architecture, networking/storage, identity/security, and governance. Think of this as your “quick-start dictionary” for interpreting the question stem correctly.

Start with scope and structure: a tenant (Microsoft Entra ID instance) can contain subscriptions (billing and management boundary). Subscriptions contain resource groups, which contain resources (VMs, storage accounts, VNets). A region is a geographic area with datacenters; an availability zone is a physically separate datacenter location within a region designed for resiliency. Region pairs support disaster recovery planning and platform updates sequencing.

Next, service models: IaaS gives you the most control (you manage OS and above), PaaS reduces management (you focus on app/data), and SaaS is complete software delivered by a provider. For identity and access, authentication proves who you are; authorization determines what you can do. RBAC assigns permissions; Azure Policy enforces or audits compliance rules; resource locks prevent accidental deletion/changes.

Exam Tip: When you see “governance,” ask: is the question about preventing deployments (Policy/locks), controlling access (RBAC), or tracking costs (Cost Management + tagging)? Choose the tool that matches the intent.

• Networking quick cues: VNet (private network in Azure), VPN gateway (encrypted tunnel), ExpressRoute (private connectivity).
• Storage quick cues: Blob (object), Files (SMB), Queue (messaging), Disks (VM disks), redundancy terms like LRS/ZRS/GRS indicate durability and geo-resilience choices.

Build your own glossary sheet as you practice. Every time you miss a question due to a term, add a one-line definition and one “how it appears on the exam” cue. Within a week, you’ll notice questions become easier because the language stops being the obstacle.

Section 2.1: Cloud computing benefits (agility, scalability, elasticity)

AZ-900 frequently tests three benefits that sound similar but have different meanings in scenarios: agility, scalability, and elasticity. Agility is about speed of change—how quickly you can provision resources, experiment, deploy, and iterate. In Azure terms, agility shows up when you can spin up a VM, App Service, database, or container environment in minutes rather than waiting weeks for procurement and installation.

Scalability is the ability to increase (or decrease) capacity to meet demand. It can be vertical (scale up: larger VM size, more CPU/RAM) or horizontal (scale out: more instances). The exam may ask what action supports a growing steady workload—this is typically scalability. Elasticity is a specific flavor of scalability: it emphasizes automatic, dynamic scaling in response to short-term changes (bursts, seasonal traffic), then scaling back down to avoid paying for idle capacity.

Exam Tip: When the scenario includes “unexpected spikes,” “seasonal,” “only on weekends,” or “auto adjust,” think elasticity. When it includes “company is growing,” “steady increase,” or “planned expansion,” think scalability. When it includes “quickly provision,” “rapidly deploy,” “faster time to market,” think agility.

• Agility → rapid provisioning and iteration
• Scalability → capacity changes to meet demand (planned or unplanned)
• Elasticity → automatic scaling with demand fluctuations

Common trap: Treating “elasticity” and “scalability” as interchangeable in all cases. On the exam, elasticity is usually signaled by automation and short-lived demand changes. Also watch for wording that implies cost efficiency—elasticity often pairs with consumption pricing because scaling down reduces cost.

To master cloud vocabulary, practice paraphrasing: “Azure can quickly allocate resources” (agility), “Azure can add more instances as we grow” (scalability), “Azure can automatically add/remove instances during spikes” (elasticity). This skill helps you identify the correct answer even if the exact term is not used verbatim in the prompt.

Section 2.2: CapEx vs OpEx and consumption-based pricing

Another Domain 1 staple is cost language: capital expenditure (CapEx) versus operational expenditure (OpEx), and how cloud changes financial planning. CapEx is upfront investment—buying servers, networking gear, data center space, and long-term licenses. OpEx is pay-as-you-go spending—monthly bills tied to usage, like a utility. Cloud computing generally shifts organizations from CapEx-heavy models to OpEx-heavy models.

Consumption-based pricing means you pay for what you use: compute time, storage consumed, network egress, or service transactions. The exam often tests whether you understand that consumption can reduce waste (no need to overprovision “just in case”), but it also requires monitoring because costs can increase if usage spikes or is mismanaged.

Exam Tip: If the question emphasizes “no upfront costs,” “avoid purchasing hardware,” “pay only for resources used,” or “treat IT like a monthly bill,” the best match is usually OpEx and consumption-based pricing.

• CapEx: upfront purchase, fixed capacity, depreciation over time
• OpEx: ongoing expense, flexible capacity, aligns with consumption
• Consumption: meter usage; supports elasticity and cost optimization

Common trap: Assuming “cloud is always cheaper.” The exam wants you to recognize the cost model shift, not promise savings. A poorly designed solution that runs oversized VMs 24/7 can cost more than on-prem. Another trap is confusing “reserved capacity” (commitment for discount) with CapEx—reserved instances are still OpEx in many accounting contexts because you’re paying for a service commitment, not buying physical assets.

How to identify correct answers: look for language about budgeting and procurement. If the scenario mentions long procurement cycles, depreciation, or buying equipment, that’s CapEx. If it mentions flexible spending, scaling up/down, and billing by usage, that’s OpEx/consumption.

Section 2.3: Cloud service models (IaaS, PaaS, SaaS) and scenarios

AZ-900 expects you to differentiate the cloud service models by who manages what. This is where “master cloud vocabulary” becomes directly testable. In IaaS (Infrastructure as a Service), the provider manages the physical data center, hardware, and virtualization, while you manage the OS, patches, runtime, and your applications. Typical examples include virtual machines and virtual networks.

In PaaS (Platform as a Service), the provider additionally manages the OS and platform components (runtime, middleware, hosting environment). You focus on deploying code and managing application configuration and data. Think “I bring my app; the cloud runs it.” In SaaS (Software as a Service), the provider delivers a complete application; you primarily manage users, settings, and data within the app (e.g., Microsoft 365).

Exam Tip: When you see “I need full control of the OS” or “lift-and-shift an existing server,” pick IaaS. When you see “developers deploy code without managing servers/OS,” pick PaaS. When you see “use a finished application,” pick SaaS.

• IaaS scenario clue: migrate a legacy app that requires custom OS configuration
• PaaS scenario clue: build a web API where the team wants managed scaling and patching
• SaaS scenario clue: adopt email/collaboration without hosting infrastructure

Common trap: Confusing PaaS with “no responsibility.” Even in PaaS, you still own your code, data, identities, and configuration. Another trap is assuming containers automatically mean PaaS; containers can run under IaaS (you manage nodes/VMs) or under PaaS-like services where the platform abstracts infrastructure. On AZ-900, focus on the responsibility boundary: OS management is the key differentiator between IaaS and PaaS; application delivery is the key differentiator for SaaS.

How to identify correct answers quickly: translate the prompt into a management statement. If the customer is patching the OS → IaaS. If the provider is patching the OS/platform but customer deploys code → PaaS. If the provider delivers the entire app → SaaS.

Section 2.4: Cloud deployment models (public, private, hybrid) and multicloud

Deployment models describe where the cloud resources run and who owns the environment. A public cloud is owned and operated by a cloud provider, delivered over the internet, and shared across multiple customers with isolation controls. Azure is a public cloud. A private cloud is a cloud environment dedicated to a single organization—often on-premises—designed to provide cloud-like automation and self-service with more direct control.

A hybrid cloud combines public cloud and private/on-prem resources, enabling data and application portability. This model appears on exams when there are regulatory constraints, legacy systems that can’t move, or needs like “keep sensitive data on-prem while using cloud compute for burst capacity.” Multicloud means using multiple cloud providers (e.g., Azure plus another provider) for reasons like vendor risk management, best-of-breed services, or geographic coverage.

Exam Tip: If the prompt says “some resources must remain on-premises” or “integrate on-prem and cloud,” choose hybrid. If it says “use services from multiple providers,” choose multicloud. If it says “cloud provider hosts everything,” choose public cloud.

• Public cloud: fastest to start, broad services, consumption pricing
• Private cloud: dedicated environment, higher control, often higher management overhead
• Hybrid: bridge constraints and modernization; common transitional model
• Multicloud: multiple vendors; adds complexity (identity, networking, governance)

Common trap: Treating hybrid and multicloud as the same. Hybrid is about combining on-prem/private with public cloud; multicloud is about multiple public clouds. Another trap is thinking private cloud equals “more secure” by default. Security depends on controls and operations; the exam generally avoids absolutes and expects you to match the model to requirements rather than claim guaranteed security outcomes.

Use-case mapping is what the exam tests: match constraints (compliance, latency, legacy dependencies) to a deployment model. When you see “cannot move” or “must keep locally,” hybrid or private is likely. When you see “avoid dependence on one vendor,” multicloud is likely.

Section 2.5: Shared responsibility model and security implications

The shared responsibility model is one of the highest-yield concepts in AZ-900 because it explains security and management boundaries across IaaS/PaaS/SaaS. The simplest way to remember it: the cloud provider is always responsible for security of the cloud (physical data centers, hardware, core infrastructure), and the customer is always responsible for security in the cloud (their data, identities, access decisions, and configurations). What changes by service model is how much of the stack the provider manages on your behalf.

In IaaS, customers handle OS hardening and patching, network controls they configure, and application security. In PaaS, the provider manages OS and platform components, but customers still secure their apps, data, and identities. In SaaS, the provider manages nearly everything except user access, data governance, and configuration choices (like MFA enforcement and sharing settings).

Exam Tip: When a question asks “who is responsible” and includes identities, access, or data classification, the answer is often the customer, even in SaaS. When it includes physical security, power/cooling, or host hardware, it’s the provider.

• Always customer: user accounts, access policies, data ownership, endpoint choices
• Shifts to provider (as you go IaaS → PaaS → SaaS): OS, runtime, middleware, application availability
• Always provider: physical facilities, core infrastructure, foundational services

Common trap: Assuming “Microsoft secures everything in Azure.” The exam often tests misconfigurations: public storage access, overly permissive identities, unpatched workloads in IaaS, or poor key management practices. Another trap is forgetting that compliance is shared too—providers offer compliant platforms, but customers must configure workloads and processes to meet their specific regulatory obligations.

How to identify correct answers: determine the service model, then locate the control in the stack. OS-level controls → IaaS customer. App code and data access rules → customer in all models. Physical/host controls → provider. This is a fast, reliable elimination strategy under timed conditions.

Section 2.6: Domain 1 practice questions and detailed answer rationales

This lesson is about how to practice (timed + reviewed) without memorizing phrasing. Domain 1 questions tend to be short, but they’re designed to test precision: two answers may look plausible if you don’t lock onto the scenario clue. Your goal is to build a repeatable method for selecting the best answer and avoiding “near-miss” terms like scalability vs elasticity or hybrid vs multicloud.

During timed practice, use a “keyword scan” first: identify whether the prompt is primarily about (1) cost model (CapEx/OpEx/consumption), (2) management boundary (IaaS/PaaS/SaaS), (3) deployment location (public/private/hybrid/multicloud), or (4) benefit vocabulary (agility/scalability/elasticity). Then answer quickly. If you can’t justify a choice in one sentence (“Because the provider manages the OS, this is PaaS”), mark and move on.

During review, write a rationale for why the correct option fits better than the second-best option. That comparison is where learning happens. For example, if you missed elasticity vs scalability, note the exact phrase that signaled automation or burst behavior. If you missed IaaS vs PaaS, note who patches the OS. If you missed hybrid vs multicloud, note whether on-prem is involved or whether it’s multiple public providers.

Exam Tip: When reviewing, build a personal “trap list.” Common traps include: treating PaaS as “no responsibility,” assuming cloud is always cheaper, confusing hybrid with multicloud, and choosing “private cloud” whenever security is mentioned. On AZ-900, absolute statements (“always,” “never,” “guaranteed”) are often suspicious—prefer answers that match the defined model and responsibility boundary.

• Elimination tactic: cross out options that change the responsibility boundary incorrectly (e.g., saying customer patches OS in SaaS)
• Definition tactic: restate the term in plain language before selecting it
• Scenario tactic: map one clue word to one concept (burst → elasticity; no upfront → OpEx)

This practice approach reinforces the earlier lessons: master vocabulary and shared responsibility, then apply them to service and deployment models. Under exam conditions, speed comes from having these mappings ready so you’re recognizing patterns—not re-deriving definitions from scratch.

Section 3.1: Azure regions, region pairs, and availability zones

Azure’s global infrastructure is the foundation for nearly every Domain 2 question. A region is a geographic area containing one or more datacenters connected by a low-latency network. Many services are deployed to a region, and your choice affects latency, data residency, and available service offerings. The exam frequently tests whether you can distinguish between “deploy to another region” (geographic separation) and “deploy to another zone” (separation within a region).

Availability zones are physically separate locations within a single Azure region. They’re designed to protect against a datacenter-level failure. If a scenario says “high availability within the same region,” or “protect against datacenter failure without leaving the region,” availability zones are a strong match. Not every service supports zonal deployments in every region, but AZ-900 focuses on the concept rather than the matrix.

Region pairs are two regions within the same geography paired for disaster recovery considerations. Microsoft designs these pairs to help with planned updates and to prioritize recovery in widespread outages. Region pairs are about resilience across regions (bigger blast radius) and often relate to services like replication or geo-redundancy where data is copied to a paired region.

Exam Tip: If the stem says “within a country/geo for compliance,” think geography and region pair. If it says “separate datacenters” but still “in one region,” think availability zones. A classic trap is choosing region pairs when the requirement is only to survive a single datacenter outage.

• Region = where you deploy; impacts latency and service availability.
• Availability zone = fault isolation inside a region.
• Region pair = cross-region relationship for broader resilience and recovery prioritization.

On the exam, treat these as layers of resiliency scope: zone (datacenter) < region (metro/area) < geography (country/sovereign boundaries). When you see “business continuity” language, decide whether it’s a local HA need (zones) or a disaster recovery need (another region/region pair).

Section 3.2: Subscriptions, management groups, resource groups, and resources

Azure organizes everything you deploy into a hierarchy that drives governance, billing, and access. At the bottom are resources (a VM, storage account, VNet, database). Resources are grouped into resource groups, which act as a logical container for resources that share a lifecycle—deploy together, manage together, and often delete together. Over resource groups are subscriptions, which define a billing boundary and a scope for quotas/limits. Above subscriptions are management groups, which help you manage multiple subscriptions consistently (common for enterprises).

Domain 2 questions often probe whether you understand scope. For example, if the scenario is “separate billing for departments,” that’s a subscription decision. If it’s “apply a policy/RBAC consistently across many subscriptions,” management groups become relevant (even if policy/RBAC is Domain 5, the scope concept appears here).

Common trap: believing a resource group is a security boundary. It is not a hard security boundary by itself; it’s a management boundary. Access control is provided by Azure RBAC assignments at a scope (management group, subscription, resource group, or resource). Resource groups help organize and apply controls, but they don’t automatically isolate networks or data.

Exam Tip: Use a “what changes together?” test. If multiple components must be deployed, updated, or removed together, they usually belong in the same resource group. If the question emphasizes “separate cost reporting, quotas, or chargeback,” choose subscriptions.

• Resource: the actual service instance.
• Resource group: lifecycle and management container.
• Subscription: billing + quotas + administrative boundary.
• Management group: multi-subscription governance layer.

Also remember that resources in a resource group can be in different regions (a frequent misconception). The resource group is about management, not geography. If the stem tries to trick you with “resources must be in the same region as the resource group,” eliminate that option.

Section 3.3: Azure Resource Manager (ARM) concepts and templates (intro)

Azure Resource Manager (ARM) is the deployment and management layer for Azure. On AZ-900, you’re expected to recognize ARM as the mechanism behind consistent provisioning, updates, and governance controls applied at scale. ARM enables you to deploy resources declaratively and repeatedly—this is where infrastructure as code begins in Azure’s native tooling.

An ARM template is a JSON-based declarative file that defines the resources you want, their configuration, and dependencies. In exam terms: templates are about repeatability, consistency, and automation. If a scenario mentions “standardize deployments,” “avoid configuration drift,” “redeploy the same environment,” or “deploy using a single definition,” ARM templates (or the concept of IaC) is the right direction.

Common trap: mixing up ARM templates with “scripts that click through the portal.” ARM is declarative: you describe the desired state, and Azure figures out the order based on dependencies. If the stem uses language like “idempotent” (same result every time) or “declarative,” it’s pointing at templates rather than imperative scripts.

Exam Tip: When you see “resources are managed as a group,” think both resource groups (container) and ARM (deployment engine). Many questions combine these: “Deploy an environment into a resource group using a repeatable method.” Your reasoning should tie the two together.

• ARM: control plane for deploying/managing resources.
• Template: declarative description of resources + dependencies.
• Benefits: consistency, automation, repeatability, fewer manual errors.

In the practice set for this domain, be ready to identify ARM as the underlying model even when the question uses phrasing like “Azure’s deployment service” or “resource provisioning layer.” You don’t need to write templates for AZ-900, but you do need to recognize why they matter.

Section 3.4: Compute services overview (VMs, containers, Azure Functions)

Compute questions on AZ-900 are usually selection questions: pick the service that matches operational responsibility and workload style. The big three patterns are virtual machines (IaaS), containers (portable runtime), and serverless functions (event-driven execution).

Azure Virtual Machines (VMs) are the go-to when you need full OS control, custom software, or lift-and-shift compatibility. The trade-off is management: you handle OS updates, patching, and much of the configuration. If the stem mentions “legacy app,” “custom drivers,” “full control,” or “run Windows/Linux with admin access,” VMs are a strong candidate.

Containers package an app and its dependencies but share the host OS kernel. They’re ideal for microservices and consistent deployments across environments. The exam often tests containers as “lighter than VMs” and “portable.” But watch the trap: containers still need an orchestration/hosting option (like AKS) if you need scaling and management beyond a single instance.

Azure Functions are serverless compute for running code in response to events (HTTP requests, timers, messages). You pay primarily for execution and scale automatically. Functions are best when the requirement is “run code on demand” or “event-driven processing” without managing servers.

Exam Tip: Translate requirements into a management model:

• Need OS-level control → VM.
• Need portable packaged app with lighter footprint → containers.
• Need event-driven, minimal ops, pay-per-execution → Functions.

Common trap: picking VMs for simple web APIs because they “can do anything.” AZ-900 prefers the simplest managed service that meets the requirement. If the prompt emphasizes minimal administration and automatic scaling, functions (or platform services in the next section) are typically better than VMs.

Section 3.5: Application hosting (App Service, AKS basics, serverless)

Beyond raw compute, AZ-900 expects you to recognize common application hosting choices. The exam’s framing is often: “host a web app/API quickly,” “scale with demand,” “avoid managing servers,” or “deploy containerized apps.” Your job is to match the requirement to the right level of abstraction.

Azure App Service is a Platform as a Service (PaaS) for hosting web apps, REST APIs, and backends. It’s ideal when you want to deploy code (or a container) and let Azure handle the underlying OS and platform maintenance. If the stem says “host a web application,” “minimize management,” “built-in scaling,” or “managed platform,” App Service is often the best answer.

Azure Kubernetes Service (AKS) is a managed Kubernetes offering for orchestrating containers at scale. The exam typically tests AKS at a conceptual level: it’s for managing containerized workloads, especially microservices, when you need orchestration, rolling updates, and scaling. However, AKS introduces complexity and is not the default choice for a simple site.

Serverless in Azure commonly points to Azure Functions (code) and event-driven designs. If the scenario emphasizes bursts of activity, unpredictable traffic, or “only pay when it runs,” serverless solutions are a strong fit.

Exam Tip: Watch for the “over-engineering” distractor. If the requirement is “deploy a simple web app” with minimal ops, AKS is usually excessive. Choose App Service unless the prompt explicitly needs Kubernetes orchestration, multi-service container management, or a Kubernetes-standard platform.

• App Service: quickest path for web apps/APIs with managed platform features.
• AKS: container orchestration at scale; higher complexity.
• Serverless: event-driven execution; cost aligned to usage.

In decision-making terms (a frequent tested skill), start by asking: “Do I need OS control?” If no, move to PaaS/serverless. Then ask: “Is the unit of deployment a web app vs many containerized services?” That separates App Service from AKS in many exam scenarios.

Section 3.6: Domain 2 practice questions: architecture + compute rationales

This chapter’s practice set is timed because AZ-900 rewards fast pattern recognition. The goal is not just to “know” terms, but to justify choices with crisp rationales. When you review explanations, train yourself to point to the keyword in the stem that drives the answer: “billing boundary” → subscription; “datacenter failure” → availability zones; “repeatable deployment” → ARM templates; “minimal ops web hosting” → App Service; “event-driven” → Functions.

A strong exam strategy is elimination based on scope. If the question is about where (latency/residency/resilience), eliminate answers about management containers (resource group/subscription). If it’s about management and organization, eliminate compute services. If it’s about how to deploy consistently, eliminate hosting options and look for ARM/IaC concepts.

Exam Tip: In compute questions, identify the operational responsibility implied by the stem:

• If the stem mentions patching/OS control, it’s pointing you toward IaaS (VMs).
• If the stem mentions “deploy code” and “managed platform,” it’s pointing to PaaS (App Service).
• If the stem mentions “run in response to events” or “short-lived tasks,” it’s pointing to serverless (Functions).

Common trap: confusing “availability” features with “backup” or “disaster recovery.” Availability zones are about keeping the app running through localized failures; region pairs and cross-region designs address bigger outages. Another trap is treating resource groups as the unit of cost or quota—those are subscription-level concerns.

As you complete the timed set, practice writing a one-sentence rationale in your head before you select an answer. If you can’t justify it with a specific requirement, you’re likely reacting to a familiar product name—exactly what the distractors are designed to exploit.

Section 4.1: Virtual networks, subnets, and IP basics for Azure

Azure Virtual Network (VNet) is the foundational networking container for resources in Azure. In exam terms, VNets provide isolation and private IP addressing so your VMs and other services can communicate internally. A VNet is divided into subnets, which are smaller address ranges used to segment workloads (for example, web tier vs data tier). A frequent AZ-900 pattern is a scenario that needs “segmentation” or “isolation within Azure” — that points to subnets and network security controls applied at the subnet or NIC level.

IP basics show up as terminology checks: private IP addresses are used inside the VNet; public IP addresses are used to reach resources from the internet. You don’t need to calculate CIDR blocks on AZ-900, but you should recognize that VNets use address spaces (for example, 10.0.0.0/16) and subnets carve ranges within that space.

• VNet: private network boundary in Azure.
• Subnet: partition within a VNet; many controls are applied here.
• NIC (Network Interface): attaches a VM to a subnet and can have NSG rules.
• Public IP: internet-routable address; often paired with load balancers or gateways.

Exam Tip: If the question is about “routing traffic between Azure resources privately,” choose VNet/subnet concepts first. If it’s about “restricting inbound/outbound,” think NSG (covered later) rather than subnets alone—subnets organize, NSGs enforce.

Common trap: confusing regions/availability zones with VNets. Regions describe where resources are deployed; VNets describe how resources connect. Another trap is assuming all Azure services must be inside a subnet. Some platform services can integrate with VNets, but the exam usually focuses on the concept: VNets provide private connectivity and segmentation.

Section 4.2: Connectivity services (VPN Gateway, ExpressRoute) and DNS basics

AZ-900 commonly tests hybrid connectivity: connecting an on-premises network to Azure. The two headline services are VPN Gateway and ExpressRoute. VPN Gateway uses encrypted tunnels over the public internet (site-to-site VPN) to connect networks. ExpressRoute provides private connectivity through a connectivity provider, typically offering more consistent performance and potentially lower latency because it does not traverse the public internet in the same way.

How to identify the right answer: if the scenario emphasizes “encrypted tunnel over the internet,” “quick setup,” or “cost-effective,” VPN Gateway is the likely choice. If it emphasizes “dedicated private connection,” “high reliability,” “consistent throughput,” or “compliance requirements that avoid internet transit,” ExpressRoute is the better match.

Exam Tip: When you see “private connection to Microsoft cloud services” and “does not go over the public internet,” that is ExpressRoute language. When you see “IPsec/IKE” or “tunnel,” that is VPN Gateway language.

DNS basics are often lightly tested but easy points. DNS resolves names to IP addresses. Azure provides DNS services; questions typically check that you understand DNS is required for name resolution and that you can use Azure’s DNS offerings to host zones/records. Do not overthink DNS in AZ-900: it’s usually a “what does DNS do?” or “which service can host DNS zones?” style objective.

Common trap: mixing up content delivery with connectivity. CDN improves content delivery to users; it does not replace VPN Gateway or ExpressRoute for private network connectivity. Another trap is thinking ExpressRoute automatically encrypts traffic like a VPN. ExpressRoute is private connectivity; encryption may be layered but is not the defining exam characteristic.

Section 4.3: Network security basics (NSG, firewall concepts, DDoS Protection intro)

Network security questions in Domain 2 typically ask you to choose the correct control for filtering traffic. A Network Security Group (NSG) is the most common answer: it contains inbound and outbound security rules that allow/deny traffic based on IP, port, and protocol. NSGs can be associated with subnets or individual network interfaces. If you see “allow HTTP (80) but deny everything else” or “restrict RDP/SSH,” NSG is your first stop.

Firewalls are broader concepts: they can provide centralized policy control, logging, and more advanced filtering than basic allow/deny at the subnet/NIC level. In AZ-900, you’re not expected to design full architectures, but you should recognize the difference: NSGs are distributed rule sets tied to subnets/NICs; firewall services represent centralized traffic control and inspection.

DDoS Protection is another common term check. Distributed Denial of Service attacks attempt to overwhelm services with traffic. Azure offers DDoS Protection to help mitigate these attacks at the platform level. In exam scenarios, the key trigger is “protect against volumetric attacks” or “DDoS mitigation.”

• NSG: Layer-4 style filtering rules (ports/protocols) for subnets/NICs.
• Firewall concept: centralized traffic policy and inspection; often described as perimeter control.
• DDoS Protection: mitigates large-scale traffic attacks against public endpoints.

Exam Tip: If the question is specifically about “controlling inbound/outbound traffic to a VM or subnet,” pick NSG. If it is about “protecting a public-facing app from DDoS attacks,” pick DDoS Protection. Avoid selecting “encryption” options—DDoS is about availability, not confidentiality.

Common trap: confusing NSG with RBAC. NSG controls network traffic; RBAC controls who can manage Azure resources. If the scenario mentions “users,” “permissions,” or “roles,” it’s identity/authorization (Section 4.5), not networking.

Section 4.4: Storage services (Blob, Disk, Files, Queues, Tables) and redundancy

Storage is heavily scenario-driven on AZ-900: you must match the data type to the Azure storage service. Blob Storage is for unstructured object data (images, video, backups, logs). Disk Storage is for VM disks—think “OS disk” and “data disk.” Azure Files provides managed file shares, commonly associated with SMB access and lift-and-shift file share scenarios. Queues support asynchronous messaging patterns. Tables provide NoSQL key-attribute storage (a simple structured store, not a relational database).

Redundancy options are another high-yield area. You’ll see acronyms like LRS, ZRS, and GRS/RA-GRS. At a conceptual level: LRS replicates within a single datacenter in a region; ZRS replicates across availability zones within a region; GRS replicates to a paired region (geo-redundant). RA-GRS adds read access to the secondary region.

Exam Tip: If the scenario mentions “disaster recovery” or “regional outage,” think geo-redundancy (GRS/RA-GRS). If it mentions “zone failure” resilience within a region, think ZRS. If cost is emphasized and no high availability requirement is stated, LRS is often the intended answer.

• Blob: object storage for unstructured data and backups.
• Disk: block storage for VM workloads.
• Files: managed file shares (often SMB), shared access patterns.
• Queues: message buffering and decoupling components.
• Tables: simple NoSQL key-value/attribute storage.

Common trap: choosing “Files” for VM disks because it “sounds like storage.” VM disks map to Disk Storage (block storage). Another trap is assuming redundancy equals backup. Replication improves durability/availability but is not the same as point-in-time backup and restore. On AZ-900, replication choices are about resiliency, not versioned recovery.

Section 4.5: Identity services (Microsoft Entra ID, RBAC intro, MFA concepts)

Identity is where many candidates lose points by mixing authentication and authorization. Microsoft Entra ID (formerly Azure Active Directory) is the cloud identity provider used for authentication (verifying who you are) for users, groups, and apps across Microsoft cloud services. If a question asks about “sign-in,” “user accounts,” “single sign-on,” or “managing identities,” Microsoft Entra ID is central.

Role-Based Access Control (RBAC) is about authorization (what you can do) in Azure. RBAC assigns roles (such as Reader, Contributor, Owner) at a scope: management group, subscription, resource group, or resource. Expect scenario phrasing like “grant a user permissions to manage a resource group but not the entire subscription.” That is RBAC scope thinking.

MFA (Multi-Factor Authentication) strengthens sign-in security by requiring more than one factor (something you know, have, or are). For exam purposes, MFA is the go-to answer when the scenario says “additional verification,” “second factor,” or “reduce risk of compromised passwords.”

Exam Tip: If the prompt contains “assign permissions,” pick RBAC. If it contains “sign in” or “identity provider,” pick Microsoft Entra ID. If it contains “second verification method,” pick MFA. Many distractors intentionally swap these terms—slow down and classify the requirement: identity (authN) vs permissions (authZ).

Common trap: thinking RBAC is an Entra feature only. RBAC uses Entra identities, but RBAC is an Azure authorization system applied to Azure resources and scopes. Another trap is over-selecting MFA when the requirement is actually “least privilege” (RBAC) rather than “stronger sign-in.”

Section 4.6: Domain 2 practice questions: network/storage/identity rationales

This chapter’s practice set is designed to simulate the exam’s pacing: timed selection first, then careful review with rationales. The goal is not memorization—it’s pattern recognition. During review, force yourself to articulate the “trigger phrase” that determined the service choice. For networking, triggers include “private network boundary” (VNet), “segment tiers” (subnets), “filter ports” (NSG), “hybrid connectivity” (VPN Gateway/ExpressRoute), and “name resolution” (DNS). For storage, triggers include “unstructured objects” (Blob), “VM OS/data disk” (Disk), “shared file share” (Files), “decouple with messaging” (Queues), and “simple NoSQL store” (Tables), plus resiliency triggers for LRS/ZRS/GRS.

For identity, the review focus is separating sign-in from permissioning: Microsoft Entra ID for authentication and identity management, RBAC for permissions at scope, and MFA for stronger authentication. When reviewing incorrect answers, ask: was the distractor a neighboring concept (e.g., firewall vs NSG, replication vs backup, Entra vs RBAC)? Those are the most common AZ-900 traps.

Exam Tip: In timed mode, eliminate two options quickly by category. Example method: (1) Is the requirement networking, storage, or identity? (2) Within that category, is it connectivity vs security vs resiliency? (3) Match the simplest service that satisfies the requirement—AZ-900 rarely expects “most advanced,” it expects “most appropriate.”

Finally, build your own “one-line rationale” habit: every time you pick an answer, write a sentence such as “NSG controls inbound/outbound rules at subnet/NIC” or “GRS replicates to a secondary region for regional outage resilience.” If you can generate that sentence under time pressure, you are aligning with what the exam tests: correct service identification and correct conceptual reasoning.

Azure governance is about applying consistent rules at scale. The exam frequently tests your understanding of scope and inheritance. The hierarchy is: Management groups (optional) → Subscriptions → Resource groups → Resources. A governance rule applied at a higher scope can be inherited by lower scopes, which is why management groups matter in larger organizations with many subscriptions.

Azure Policy is the primary governance enforcement engine. A policy definition describes a rule (for example, “Allowed locations,” “Require a tag,” “Disallow public IPs”). You then create a policy assignment at a scope to apply it. The exam often asks whether a tool can deny noncompliant deployments or simply report them. Policy can do both depending on effect: common effects include Deny (blocks creation/update), Audit (reports noncompliance), and DeployIfNotExists (helps remediate by deploying a missing setting/resource).

Initiatives (also called policy sets) bundle multiple policies into one package. If a question describes “apply a group of policies to meet a standard,” initiatives are the best fit. This commonly appears with “baseline” governance or compliance posture—one assignment, many related requirements.

Exam Tip: If the scenario says “standardize across multiple subscriptions,” select management groups as the scope strategy. If it says “ensure only compliant resources are created,” select Azure Policy with a Deny effect rather than RBAC.

Common trap: Confusing policy with monitoring. Policy evaluates resource properties for compliance. Monitoring tools (Azure Monitor) track performance/health signals; they don’t inherently prevent a deployment from happening.

AZ-900 expects you to separate three different control planes: authorization (RBAC), configuration enforcement (Policy), and change protection (Locks). Many exam questions provide a short sentence like “prevent deletion” or “restrict creation of certain SKUs,” and the correct answer is usually one of these three.

Azure RBAC (Role-Based Access Control) answers: “Who can do what on which scope?” Roles like Owner, Contributor, and Reader are assigned to a security principal (user, group, service principal, managed identity) at a scope. Permissions inherit downward. RBAC does not validate configuration rules like “must be in region X”—that’s a policy job.

Azure Policy answers: “What can be deployed, and must it meet a rule?” You can give someone Contributor rights (RBAC allows the action), but a policy can still block the action if the resource violates a rule. This is a common two-layer governance pattern: RBAC grants ability, policy constrains allowed shapes of resources.

Resource locks answer: “Even if you have permission, can you delete/change this resource?” The two lock types are CanNotDelete (deletion blocked) and ReadOnly (writes blocked). Locks apply at a scope and inherit downward, similar to RBAC and policy. Locks are not a compliance engine and do not replace RBAC—an authorized user may still be blocked by a lock.

Exam Tip: If the question says “ensure admins can’t accidentally delete a critical resource group,” choose CanNotDelete lock, not policy. Policy prevents creation/update that violates rules; it’s not designed as a deletion guardrail.

Common trap: Selecting RBAC to “restrict VM sizes.” RBAC cannot restrict SKU choice; it only controls operations like create/update/delete. SKU/region/tag rules are classic policy territory.

Cost questions in Domain 3 test whether you know the tools that analyze, alert, and optimize spending. Start with the mindset: Azure cost control is part forecasting and part governance. You will typically see the following building blocks in questions: tags, budgets, Azure Advisor, and high-level pricing calculators (including TCO thinking).

Tags are name/value pairs applied to resources and resource groups. They enable chargeback/showback and reporting, such as grouping costs by “Department=Finance” or “Environment=Prod.” The exam often frames tags as “organize resources for billing” or “track costs by project.” Tags themselves don’t enforce policy; they’re metadata. However, you can combine them with Policy (for example, “Require a CostCenter tag”) to standardize tagging.

Budgets (in Cost Management) allow you to set thresholds for spending and trigger alerts. The exam checks that budgets are about alerting (and sometimes automation via action groups), not automatically stopping services by default. When you see “notify when spending reaches 80%,” budgets should jump out.

Azure Advisor provides recommendations across categories like cost, security, reliability, operational excellence, and performance. For cost, it often recommends right-sizing VMs, shutting down underutilized resources, or purchasing reserved instances where applicable (even if RI details are not deep in AZ-900, the concept of cost optimization is fair game).

TCO basics (Total Cost of Ownership) compares on-prem vs cloud costs, incorporating hardware, licensing, facilities, and operations. On AZ-900, expect conceptual questions: TCO helps justify migration by modeling savings, not manage daily spend. For daily cost tracking, use Cost Management; for “what will it cost if we move,” think TCO/price calculators.

Exam Tip: If a question asks “which feature helps allocate cost by department,” pick tags. If it asks “which feature sends alerts when costs exceed a threshold,” pick budgets. If it asks “which tool gives cost-saving recommendations,” pick Azure Advisor.

Common trap: Choosing Advisor for cost allocation. Advisor recommends; it does not categorize your billing by team. That’s tags and reporting.

Monitoring questions often try to mix performance monitoring with platform incident awareness. AZ-900 expects you to distinguish “your resource telemetry” from “Azure platform status.” The core tools are Azure Monitor and Azure Service Health (plus practical admin entry points like the portal, CLI, PowerShell, and ARM/Bicep, though the exam emphasizes concepts more than syntax).

Azure Monitor is the umbrella service for collecting and acting on telemetry: metrics and logs. Metrics are numeric time-series signals (CPU %, requests/sec) and are typically lightweight and near real-time. Logs (often via Log Analytics) are richer, query-based event and diagnostic records. Azure Monitor supports alerting, dashboards, and integrations. In scenario terms: “alert when CPU exceeds 80%,” “analyze logs to troubleshoot,” and “visualize performance trends” all point to Azure Monitor.

Azure Service Health communicates issues and maintenance events affecting Azure services and regions. It includes service issues, planned maintenance, health advisories, and can be filtered to your subscriptions/resources. If the question asks “was there an Azure outage impacting my region?” or “get alerts about planned maintenance,” Service Health is your match.

Exam Tip: Ask yourself: is the signal coming from your workload (Monitor) or from Microsoft’s platform status (Service Health)? This single distinction resolves many practice-test items.

Common trap: Picking Azure Monitor to learn about global service outages. Monitor can show your app symptoms, but platform incidents are communicated through Service Health (and the broader status pages). Another trap is assuming Service Health replaces application monitoring; it does not provide CPU, memory, or app logs.

Management tooling is also indirectly tested: you may see references to the Azure portal (GUI), Azure Cloud Shell, Azure CLI, Azure PowerShell, and infrastructure as code (ARM templates/Bicep). The exam isn’t testing commands—it’s testing that Azure can be managed consistently and automated, supporting the chapter lesson on control and standardization.

This section is heavily scenario-driven: “Which SLA applies?” “Where do I find compliance documentation?” “What support plan is needed?” The exam expects you to know what an SLA is, how service lifecycle affects availability commitments, what “compliance” means in Azure, and the broad levels of support plans.

SLAs (Service Level Agreements) define Microsoft’s uptime commitments for specific services, usually expressed as a percentage over a billing month, and the corresponding service credits if Microsoft fails to meet it. A key exam concept is that SLA depends on architecture: adding redundancy (for example, multiple instances, availability zones) typically improves availability compared to a single instance. You don’t need exact percentages for every service, but you must understand that “design for high availability” and “SLA applies per service” are core ideas.

Service lifecycle matters because not every offering carries the same guarantees. In general: Preview features may have limited or no SLA and are not recommended for production. General Availability (GA) services are production-ready and covered by standard SLAs. If a question hints “preview,” be cautious: pick the option that notes limited support/SLA rather than production guarantees.

Compliance on AZ-900 is about knowing that Azure provides extensive compliance offerings and documentation. The key resource is the Microsoft Trust Center (and related compliance documentation/offerings) for standards and reports. Questions often ask where to find information about certifications, regulations, and privacy commitments.

Support plans are differentiated by response times, scope, and features. While the exam may not demand every plan detail, you should recognize that Basic includes billing support and access to documentation, while paid plans (like Developer, Standard, Professional Direct) provide technical support with faster response times and additional guidance. The right answer is usually driven by “need 24/7 technical support” vs “billing-only.”

Exam Tip: If the question says “production workload” and the option mentions “preview,” eliminate it unless the question is specifically about preview characteristics. Also, SLAs are about Microsoft’s service availability—not about your code quality or your internal help desk.

Your practice set for Domain 3 should be approached as a pattern-recognition drill: identify the governance goal, map it to the correct tool, then confirm scope and limitations. When reviewing answers, don’t just note what was correct—note which keyword in the scenario forced that choice. This is how you convert timed practice into reliable exam performance.

How to identify correct answers (tool mapping): If the scenario is about standardizing configurations (allowed regions, required tags, disallowed public endpoints), your default should be Azure Policy (and initiatives for bundles). If it’s about permissions (“allow the help desk to restart VMs but not delete them”), it’s RBAC. If it’s about accidental deletion/change protection even for authorized admins, it’s resource locks. If it’s about cost thresholds and notifications, it’s budgets. If it’s about optimization recommendations, it’s Azure Advisor. If it’s about performance telemetry and alerts, it’s Azure Monitor. If it’s about Azure platform incidents and maintenance, it’s Service Health.

Common review traps you should actively correct: (1) Assuming budgets “stop spending.” Budgets alert; you must pair alerts with processes/automation to act. (2) Treating tags as security controls. Tags help reporting; policy enforces. (3) Treating Service Health as an application monitoring tool. It reports Azure issues; it doesn’t replace metrics/logs. (4) Forgetting scope inheritance: a policy assigned at a management group can affect every subscription beneath it.

Exam Tip: In timed mode, underline the verb in your head: “prevent,” “allow,” “notify,” “recommend,” “monitor,” “protect from deletion,” “inform about outage.” Each verb maps to one primary Azure feature. Your reviewed mode should focus on writing that mapping into memory so you don’t overthink multi-choice distractors.

Finally, remember what AZ-900 is testing here: not deep implementation, but correct conceptual selection. If you can consistently pick the right governance control and state what it does and what it doesn’t do, you’re ready for Domain 3.

Before you sit a full mock, ensure your attempt is representative of the real exam objectives. AZ-900 questions rotate across six recurring domains: (1) cloud concepts (models, benefits, core terminology), (2) Azure architecture and services—regions/resources/compute, (3) Azure architecture and services—networking/storage, (4) identity/access/security basics, (5) management and governance—cost/SLAs/support, and (6) governance features—Policy and RBAC.

Your full mock blueprint should intentionally “touch” each domain multiple times so you can trust the results. During Mock Exam Part 1, you are validating baseline readiness: can you consistently choose the best answer when two options sound correct? During Mock Exam Part 2, you’re validating improvement after remediation and making sure earlier gains were not accidental.

• Cloud concepts: public/private/hybrid, IaaS/PaaS/SaaS, shared responsibility, elasticity, high availability, disaster recovery, scalability vs. elasticity, CapEx vs. OpEx.
• Core architecture/services: regions, region pairs, subscriptions, management groups, resource groups, Azure Resource Manager (ARM), compute options (VMs, containers, serverless).
• Networking/storage: VNets, subnets, NSGs, VPN Gateway vs. ExpressRoute, public vs. private endpoints; storage accounts, blob vs. file vs. queue vs. table, redundancy options.
• Identity/security: Entra ID (Azure AD), MFA, Conditional Access, Zero Trust, Microsoft Defender for Cloud basics, security baseline ideas.
• Management/governance: Cost Management, pricing factors, SLAs, service lifecycle, support plans.
• Policy/RBAC: role assignments, scopes, built-in roles, policy vs. initiative, governance intent.

Exam Tip: If your mock results show you “never see” a topic (e.g., region pairs or storage redundancy), your mock isn’t blueprint-aligned. Fix the blueprint before you interpret the score.

Common trap: treating the mock like trivia. The exam tests recognition of correct Azure terminology and fit-for-purpose service selection. Your blueprint must include items where the correct choice is about scope (subscription vs. resource group), governance control (Policy vs. RBAC), or availability design (zone vs. set)—the usual differentiators in real questions.

AZ-900 is not a speed contest, but it is a time-managed exam. Build pacing discipline during Mock Exam Part 1 and Part 2: answer straightforward items in one pass, flag uncertainty, and avoid “time sinks” on a single confusing scenario. The objective is stable performance under time constraints, not perfection on the first read.

Use a three-pass method. Pass 1: answer immediately if you can justify the choice in one sentence using Azure terms (e.g., “RBAC grants permissions; Policy enforces standards”). Pass 2: revisit flagged items and eliminate distractors using domain knowledge. Pass 3: sanity-check only the remaining uncertain items; do not reopen everything.

• Set a per-question target (roughly 60–90 seconds). If you exceed it, flag and move.
• Flag questions where two options both seem plausible; these are the highest ROI for later review.
• Do not change answers without a specific reason (new insight, misread keyword, or corrected concept).

Exam Tip: On governance questions, hunt for the “scope word” early: management group, subscription, resource group, resource. Many distractors differ only by scope, and the correct answer is the one that can apply at the needed scope.

Common trap: re-reading the entire question repeatedly. Instead, identify the decision axis: identity vs. network vs. storage; availability vs. performance; permissions vs. compliance. Then choose the service that matches that axis. Also watch for negative phrasing (“not,” “cannot,” “least”)—flag these immediately to avoid careless errors.

Your score improves fastest when you learn how AZ-900 distractors are constructed. Distractors typically exploit (1) service name similarity, (2) confusion between “configure access” and “enforce compliance,” and (3) mixing architectural terms (region vs. availability zone vs. datacenter). When reviewing your answer key, do not just note the correct letter—write the “why this, not that” rule.

Use elimination in a consistent order. First, remove options that violate the shared responsibility model (e.g., claiming Microsoft manages what customers manage, or vice versa). Next, remove options that mismatch the requirement type: authorization (RBAC) vs. policy enforcement (Azure Policy) vs. authentication (Entra ID). Finally, remove options that are correct facts but not the “best fit” for the described scenario.

• RBAC: “who can do what” (permissions) at a scope.
• Azure Policy: “what is allowed” (standards/compliance) via deny/audit/modify.
• NSG: traffic filtering at subnet/NIC level; not a routing service.
• VPN Gateway vs. ExpressRoute: internet-based encrypted tunnel vs. private dedicated connectivity.
• Availability Set vs. Availability Zone: fault/update domains vs. physically separate zones in a region.

Exam Tip: If two options are both true, the exam is asking for the one that most directly satisfies the requirement. Look for requirement keywords like “enforce,” “prevent,” “private,” “dedicated,” “SLA,” or “cost predictability.”

Common trap: picking a familiar service because it “sounds secure.” For example, “MFA” improves authentication assurance, but it does not replace RBAC (authorization). Similarly, “encryption” is not the same as “network isolation.” Your elimination should be driven by the control category: identity, network, data, or governance.

Your Weak Spot Analysis should classify misses into three buckets: knowledge gaps (you didn’t know), precision gaps (you knew but confused similar concepts), and process gaps (misread, rushed, changed a correct answer). Remediation is different for each. Knowledge gaps require re-study; precision gaps require comparison tables; process gaps require improved pacing and keyword discipline.

Remediate by domain so you can map progress to exam outcomes:

• Cloud concepts: revisit IaaS/PaaS/SaaS responsibilities, elasticity vs. scalability, CapEx vs. OpEx, and benefits like global reach and consumption-based pricing.
• Regions/resources/compute: re-check region pairs, resource groups vs. subscriptions, ARM, and when to choose VMs vs. containers vs. serverless.
• Networking/storage: drill VNet basics, NSG role, VPN vs. ExpressRoute, storage types and redundancy (LRS/ZRS/GRS) at a conceptual level.
• Identity/security: clarify Entra ID, MFA, Conditional Access, and baseline security posture concepts.
• Cost/SLAs/support: understand what an SLA measures, factors affecting cost (region, egress, SKU, reservations), and what support plans provide.
• Policy/RBAC: practice “permission vs. compliance” distinctions and scope inheritance.

Exam Tip: The fastest remediation tool is a two-column “confusable pairs” list (RBAC vs. Policy, VPN vs. ExpressRoute, Zone vs. Set, Blob vs. Files). Review it daily until you can state the difference without hesitation.

Common trap: retaking mocks without changing inputs. If you miss “policy vs. RBAC” today and don’t explicitly practice that distinction, your next attempt may improve only by memorization. Ensure each weak spot has a targeted fix (a note, a mini-table, or a rule) before Mock Exam Part 2.

In the final 24–48 hours, switch from broad study to rapid recall. The exam is vocabulary-heavy, and high-yield review means you can define a term, state its purpose, and name one common “not this” distractor. Use this review sheet before Mock Exam Part 2 and again the morning of the exam.

• Cloud models: public, private, hybrid; services: IaaS/PaaS/SaaS; shared responsibility boundaries.
• Core structure: management groups → subscriptions → resource groups → resources; ARM as deployment/management layer.
• Geography: region, region pair, availability zone, datacenter; resiliency implications.
• Compute: VM (most control), containers (lightweight), serverless (event-driven, pay-per-execution).
• Networking: VNet/subnet; NSG filtering; VPN Gateway vs. ExpressRoute; DNS conceptually; peering as private VNet connectivity.
• Storage: storage account; blob/file/queue/table; redundancy: LRS/ZRS/GRS (know the idea, not deep math).
• Identity & security: Entra ID, MFA, Conditional Access; Zero Trust mindset; Defender for Cloud as security posture management.
• Governance: RBAC (permissions) vs. Policy (enforce standards); initiatives group policies; tagging for cost organization.
• Cost & support: TCO mindset, Cost Management basics, SLAs and service credits concept, support plan scope.

Exam Tip: When you see “ensure resources comply” or “prevent deployment unless…” think Azure Policy. When you see “allow user X to manage Y” think RBAC. When you see “private dedicated connection” think ExpressRoute.

Common trap: overfocusing on product names and missing the action verb. Train yourself to underline the verb mentally (enforce, grant, connect, store, deploy, monitor). The verb usually points to the correct domain and narrows the service choice.

Your Exam Day Checklist prevents preventable losses. Most candidates who fail AZ-900 were “close,” and close is often a workflow issue: fatigue, rushing, or misreading. Treat exam day as execution, not study.

• Logistics: confirm start time/time zone, test center route or online proctoring requirements, ID readiness, and a quiet environment. If online, verify camera, microphone, and allowed workspace rules.
• Mindset: aim for calm consistency. Expect a few unfamiliar phrasings; the exam tests concepts, not memorized sentences.
• During the exam: use the three-pass approach; flag “two-plausible-answer” items; watch for negatives (“NOT,” “least”). Keep moving.
• Final minutes: review only flagged items. Do not reopen a question you were confident on unless you found a concrete mistake.

Exam Tip: If you feel stuck, force a domain decision first (cloud concept vs. governance vs. identity vs. networking). Once you’ve chosen the domain, most distractors become obviously out-of-scope.

Post-exam steps matter for long-term growth and future certifications. If you pass, document which domains felt hardest—those become your foundation for AZ-104 or security tracks. If you don’t pass, record your weak domains immediately (while the experience is fresh), then rebuild your plan: targeted remediation, a new mock with blueprint coverage, and a tighter pacing strategy. The goal is controlled improvement, not repeated attempts.