AZ-900 — Microsoft Azure Fundamentals Scenario Practice Guide

This independent guide is for candidates preparing for Microsoft Azure Fundamentals (AZ-900). It focuses on how to read scenario-based questions, identify the actual decision point, and choose the best answer from the facts provided.

AZ-900 scenarios are usually not asking you to perform deep implementation work. They are testing whether you can connect a business or technical requirement to the correct Azure concept, service, pricing tool, governance feature, security model, or operational approach. The most efficient habit is to slow down just enough to classify the scenario before comparing the answer choices.

What AZ-900 Scenarios Usually Ask You to Decide

A scenario question often looks like a short business problem, but the answer usually depends on one of these decisions:

• Which cloud model applies? Public, private, hybrid, IaaS, PaaS, SaaS, serverless, or consumption-based computing.
• Which Azure service fits the requirement? For compute, storage, networking, identity, monitoring, governance, or migration.
• Who is responsible for what? Especially under IaaS, PaaS, and SaaS shared responsibility.
• Which security or governance control is appropriate? Identity, role-based access, policy, resource locks, management groups, tags, or compliance tools.
• Which pricing, planning, or support resource should be used? Pricing Calculator, TCO Calculator, Cost Management, SLAs, service lifecycle, or support plans.
• Which operational tool gives the needed visibility? Azure Monitor, alerts, Service Health, Advisor, Log Analytics, or similar management capabilities.

Your job is not to prove that every answer choice is somewhat useful. Your job is to find the answer that most directly satisfies the stated requirement.

A Simple Reading Sequence for AZ-900 Scenarios

Use the same sequence on every scenario, especially during final review.

1. Identify the environment

First, determine where the workload, users, and systems are located.

Look for clues such as:

• Existing on-premises datacenter
• Hybrid connectivity requirement
• Azure-only deployment
• Multiple subscriptions or departments
• Virtual machines, containers, web apps, databases, or storage accounts
• Employees, external users, administrators, or applications
• Need to migrate, modernize, monitor, secure, or reduce cost

This tells you whether the scenario is mostly about cloud concepts, identity, networking, governance, operations, or service selection.

Example:

A company runs line-of-business applications in an on-premises datacenter and wants to extend capacity into Azure during peak periods.

The key environment clue is hybrid. Before choosing an answer, think about hybrid networking, cloud bursting concepts, and connectivity rather than a purely cloud-native architecture.

2. Find the goal or symptom

Next, isolate what the organization is trying to achieve.

Common AZ-900 goals include:

• Reduce hardware management
• Minimize upfront capital expense
• Improve availability
• Estimate migration cost
• Control spending
• Enforce naming, location, or SKU rules
• Limit administrator permissions
• Prevent accidental deletion
• Monitor Azure service outages
• Detect configuration recommendations
• Support compliance reporting
• Choose a database, compute, or storage option

If the scenario includes a problem, name the symptom plainly.

For example:

• “Users cannot access an app” may be an identity, network, or availability issue.
• “The company needs to forecast Azure monthly spend” points toward pricing and cost tools.
• “Administrators must not be able to delete a resource” points toward locks, not just permissions.
• “Only approved regions may be used” points toward governance with policy.

3. Separate hard constraints from preferences

Scenario wording often includes both strict requirements and general preferences. Treat strict requirements as non-negotiable.

Hard constraints sound like:

• “Must”
• “Required”
• “Only”
• “Prevent”
• “Ensure”
• “Minimize administrative effort”
• “Without managing servers”
• “Using the least privilege principle”
• “Retain data for…”
• “Meet compliance requirements”
• “Continue operating during…”

Preferences sound like:

• “Wants”
• “Would like”
• “Prefers”
• “Plans to”
• “Considering”

In AZ-900, a single hard constraint often determines the answer. If an option is technically plausible but violates the stated constraint, it is not the best answer.

4. Determine the answer category before reading too deeply into options

Before you compare the choices, decide what kind of answer the question is asking for.

Ask:

• Is this asking for a service?
• A tool?
• A cloud model?
• A security control?
• A governance feature?
• A pricing or cost resource?
• A monitoring or health feature?
• A support or lifecycle concept?

This prevents you from mixing categories.

Example:

A company wants to estimate the cost of running specific Azure resources before deployment.

The answer category is a pricing estimation tool, not a monitoring tool or a billing analysis tool. That points toward the Azure Pricing Calculator rather than Cost Management.

Interpreting Azure Scenario Facts

AZ-900 questions often use a few facts to point to a specific Azure concept. Learn to translate those facts quickly.

Cloud model clues

Use scenario language to classify the model.

• IaaS: The company needs virtual machines, operating system control, custom software installation, or migration with minimal app redesign.
• PaaS: The company wants to deploy applications without managing the underlying OS, runtime infrastructure, or patching responsibilities.
• SaaS: Users consume a complete application, usually through a browser or client, without managing the application platform.
• Serverless: The workload runs code or logic without managing servers and may scale based on events or demand.
• Hybrid cloud: The organization uses both on-premises infrastructure and cloud resources.
• Public cloud: Resources are provided over the internet by a cloud provider and shared across customers using isolation controls.

The key is responsibility. If the scenario says the organization wants less infrastructure management, move away from IaaS unless another requirement demands VM-level control.

Shared responsibility clues

When a question asks who is responsible for securing or maintaining something, first identify the service model.

General reasoning pattern:

• With IaaS, the customer has more responsibility, including OS configuration, patches, applications, identities, and data.
• With PaaS, the provider manages more of the platform, while the customer still manages application settings, identities, and data.
• With SaaS, the provider manages the application platform, while the customer still manages users, access, data usage, and configuration choices.

Do not answer shared responsibility questions by thinking only about “Azure is secure.” The scenario usually asks which layer remains the customer’s responsibility.

Compute clues

When a scenario mentions running an application, determine how much control and management the customer needs.

• Virtual machines fit when the organization needs OS-level control, lift-and-shift migration, custom server configuration, or traditional workloads.
• Azure App Service fits when the organization wants to host web apps or APIs without managing the underlying servers.
• Azure Functions fits event-driven or serverless code execution where the organization wants to run small units of code based on triggers.
• Containers fit packaged application workloads that need consistent deployment across environments.
• Azure Kubernetes Service fits orchestration of containerized applications when Kubernetes management capabilities are required.

For AZ-900, focus on the broad service match rather than advanced configuration details.

Storage clues

Storage scenarios usually describe the type of data and access pattern.

• Blob storage: Unstructured object data such as images, videos, backups, documents, or logs.
• File storage: Managed file shares accessible through standard file-sharing protocols.
• Queue storage: Message storage for decoupling application components.
• Table storage or NoSQL-style storage: Simple structured non-relational data scenarios.
• Managed disks: Persistent disks attached to Azure virtual machines.

A useful question: “Is the scenario storing files, objects, messages, VM disks, or database records?”

Database clues

Database scenario facts usually point to relational, NoSQL, or migration requirements.

• Azure SQL Database: Managed relational database for SQL workloads without managing the full database server infrastructure.
• SQL Server on Azure Virtual Machines: More control over the OS and SQL Server instance, often for compatibility or lift-and-shift needs.
• Azure Cosmos DB: Globally distributed NoSQL workloads, flexible data models, or low-latency application needs.
• Azure Database services for open-source engines: Managed database options for engines such as MySQL or PostgreSQL.

For fundamentals-level reasoning, identify whether the data is relational, non-relational, or tied to an existing platform requirement.

Networking clues

Networking scenarios often include connectivity, isolation, or access control facts.

• Virtual network: Private network space for Azure resources.
• Subnet: Segmentation inside a virtual network.
• VPN Gateway: Encrypted connection over the public internet between networks.
• ExpressRoute: Private connectivity between on-premises infrastructure and Azure through a connectivity provider.
• Network security group: Controls inbound and outbound traffic to network interfaces or subnets.
• Azure DNS: DNS hosting and name resolution scenarios.
• Load Balancer or Application Gateway: Distribute traffic, depending on whether the scenario is lower-level network traffic or application-layer web traffic.

Do not jump to a connectivity product until you know whether the scenario needs private connectivity, internet-based encrypted connectivity, traffic filtering, or traffic distribution.

Security and Identity Reasoning

Security scenarios in AZ-900 are often about choosing the control that matches the level of the requirement.

Start with identity

If the scenario mentions users, groups, authentication, single sign-on, or access to resources, think identity first.

Key reasoning points:

• Microsoft Entra ID is the cloud identity and access management service formerly known as Azure Active Directory.
• Multi-factor authentication strengthens sign-in by requiring more than one verification factor.
• Conditional Access applies access decisions based on conditions such as user, device, location, or risk signals.
• Role-based access control grants permissions to Azure resources based on roles and scopes.
• Least privilege means granting only the permissions required to perform the task.

When a scenario asks who can perform actions on Azure resources, think RBAC. When it asks how users authenticate or access cloud applications, think Microsoft Entra ID features.

Match the control to the enforcement need

Different Azure controls solve different problems:

• Use RBAC to control what users, groups, or service principals can do to Azure resources.
• Use resource locks to help prevent accidental deletion or modification of resources.
• Use Azure Policy to enforce or audit rules for resource configuration.
• Use management groups to organize governance across multiple subscriptions.
• Use tags to label resources for organization, cost tracking, or management.
• Use Microsoft Defender for Cloud for security posture management and security recommendations.

Example:

A company wants to allow a team to restart virtual machines but not delete them.

This is an access permission scenario. The best fit is RBAC with an appropriate role or custom permission model.

Example:

A company wants to prevent accidental deletion of a production resource group, even by users who otherwise have permissions.

This points to a resource lock, because the requirement is specifically to prevent deletion.

Example:

A company wants all new resources to be created only in approved regions.

This points to Azure Policy, because the requirement is governance enforcement across resource deployments.

Governance, Subscriptions, and Resource Organization

AZ-900 scenarios often test whether you can choose the correct organizational layer.

Use this hierarchy mentally:

• Management groups organize multiple subscriptions.
• Subscriptions provide a billing, access, and resource management boundary.
• Resource groups are logical containers for Azure resources.
• Resources are the individual services, such as virtual machines, storage accounts, and databases.
• Tags add metadata for organization, reporting, or cost allocation.

How to reason through organization scenarios

Ask:

1. Is the requirement across many subscriptions?

   • Think management groups, policy assignment at scale, and governance hierarchy.

2. Is the requirement about billing boundary or separating environments?

   • Think subscriptions.

3. Is the requirement about grouping resources with a common lifecycle?

   • Think resource groups.

4. Is the requirement about classifying resources for cost reports or ownership?

   • Think tags.

5. Is the requirement about enforcing allowed configurations?

   • Think Azure Policy.

6. Is the requirement about preventing changes or deletion?

   • Think resource locks.

Cost, Pricing, and SLA Scenarios

Cost questions are usually about choosing the correct planning or analysis tool.

Choose the right cost tool

Use the timing of the scenario:

• Before deployment: Use the Azure Pricing Calculator to estimate costs for planned Azure resources.
• Before migration from on-premises: Use the TCO Calculator to compare on-premises costs with Azure.
• After resources are running: Use Microsoft Cost Management to monitor, analyze, and manage Azure spending.
• For recommendations to reduce cost or improve configuration: Consider Azure Advisor.
• For organizing costs by department, project, or owner: Tags can help support cost allocation and reporting.

Example:

A company wants to estimate the monthly cost of a proposed Azure virtual machine, storage account, and database before creating them.

The answer category is pre-deployment cost estimation. The best fit is the Azure Pricing Calculator.

Example:

A company wants to compare the cost of its existing datacenter with the projected cost of moving workloads to Azure.

The migration comparison clue points to the TCO Calculator.

Read SLA and availability scenarios carefully

When a scenario discusses uptime, regions, redundancy, or availability, identify what is being protected against.

• Availability zones help protect against datacenter-level failures within a region.
• Regions are geographic areas containing Azure datacenters.
• Region pairs are used in Azure’s regional strategy for resilience and recovery planning.
• SLA describes Microsoft’s commitment for service availability under defined conditions.
• Redundancy options affect how data is replicated and protected.

Avoid assuming “more redundancy” is always the answer. Match the requirement:

• Local durability within a region is different from cross-region resilience.
• High availability is different from disaster recovery.
• A single VM availability approach is different from a multi-instance application architecture.

Monitoring, Health, and Management Scenarios

Management scenarios often include a phrase like “view,” “alert,” “recommend,” “track,” or “respond.”

Match the monitoring need

• Azure Monitor: Collects, analyzes, and acts on telemetry from Azure and other environments.
• Alerts: Notify or trigger actions when conditions are met.
• Log Analytics: Used to query and analyze log data.
• Azure Service Health: Personalized view of Azure service issues that may affect your resources.
• Azure status page: Broad public view of Azure service status.
• Azure Advisor: Recommendations for reliability, security, performance, operational excellence, and cost.
• Azure Resource Manager: Deployment and management layer for Azure resources.

Example:

A company wants to be notified when CPU usage on a virtual machine exceeds a threshold.

This is a monitoring and alerting requirement. Think Azure Monitor and alerts.

Example:

A company wants to know whether a Microsoft Azure service issue is affecting its resources in a specific region.

This points to Azure Service Health, because the scenario is about personalized service-impact information.

Example:

A company wants recommendations to improve cost and reliability for existing Azure resources.

This points to Azure Advisor.

Choosing the Most Defensible Answer

A defensible answer is the one that best satisfies the explicit requirement with the least assumption.

Use this checklist when answer choices seem close:

• Does the answer directly satisfy the stated goal?
• Does it respect every hard constraint?
• Is it the correct category of solution?
• Is it appropriate for the stated service model?
• Does it avoid unnecessary operational complexity?
• Does it follow least privilege when access is involved?
• Does it match the timing: planning, deploying, operating, or troubleshooting?
• Does it solve the actual problem rather than a related problem?

Prefer direct matches over broad associations

Some Azure services overlap conceptually, but AZ-900 usually rewards the direct match.

For example:

• If the requirement is estimate planned Azure resource cost, choose a pricing estimation tool, not a monitoring tool.
• If the requirement is enforce allowed regions, choose policy, not tags.
• If the requirement is prevent deletion, choose a lock, not only a naming standard.
• If the requirement is assign permissions to Azure resources, choose RBAC, not only authentication.
• If the requirement is view service incidents affecting resources, choose Service Health, not only general performance monitoring.

A Practical Scenario Walkthrough Method

Use this five-step method during practice.

Step 1: Summarize the scenario in one sentence

Turn the scenario into a plain statement.

Example:

“The company needs to control where resources are deployed.”

That summary points toward governance and policy.

Step 2: Underline the action verb

Action verbs reveal the decision type:

• Estimate
• Compare
• Deploy
• Monitor
• Prevent
• Authenticate
• Authorize
• Encrypt
• Connect
• Migrate
• Scale
• Recommend
• Organize
• Enforce

“Authenticate” and “authorize” are not the same. “Monitor” and “recommend” are not the same. “Estimate” and “analyze current spend” are not the same.

Step 3: Identify the Azure layer

Ask which layer the scenario is about:

• Identity layer
• Network layer
• Compute layer
• Data layer
• Governance layer
• Cost management layer
• Monitoring layer
• Support or service lifecycle layer

This helps you remove unrelated answer choices quickly.

Step 4: Compare answer choices against the constraint

Do not compare answers based on which one sounds most advanced. Compare them against the requirement.

If the question says “without managing servers,” a VM-based answer is usually weak unless the scenario requires VM control.

If the question says “least privilege,” a broad owner-level role is usually weak if a narrower role would work.

If the question says “before deployment,” a tool that analyzes existing resource usage is usually weak.

Step 5: Choose the answer that requires the fewest assumptions

A strong AZ-900 answer should not require you to invent extra facts.

For example:

• Do not assume a company needs Kubernetes unless the scenario mentions container orchestration or Kubernetes.
• Do not assume private dedicated connectivity unless the scenario requires it.
• Do not assume a complex governance hierarchy when the requirement is simple tagging.
• Do not assume custom development when a managed Azure service directly fits.

Short AZ-900 Scenario Examples

Use these as reasoning drills, not as memorized question patterns.

Example 1: Governance enforcement

Scenario:

A company has multiple Azure subscriptions. It must ensure that resources are deployed only in approved Azure regions.

Reasoning:

• Environment: Multiple subscriptions
• Goal: Enforce allowed deployment locations
• Category: Governance
• Best fit: Azure Policy, potentially assigned at a scope that covers the relevant subscriptions

Why:

The requirement is enforcement. Tags can label resources, and resource groups can organize resources, but policy is the governance feature designed to audit or enforce rules.

Example 2: Cost planning

Scenario:

A team wants to estimate monthly Azure costs for a planned web app, database, and storage account before creating any resources.

Reasoning:

• Timing: Before deployment
• Goal: Estimate planned Azure cost
• Category: Pricing tool
• Best fit: Azure Pricing Calculator

Why:

The scenario is not asking to analyze existing spend. It is asking to estimate planned resources.

Example 3: Access control

Scenario:

A junior administrator needs permission to start and stop virtual machines but should not be able to manage access for other users.

Reasoning:

• Goal: Grant limited operational permissions
• Security principle: Least privilege
• Category: Authorization for Azure resources
• Best fit: RBAC with an appropriate limited role

Why:

The requirement is about what actions the administrator can perform on Azure resources. That is authorization through role assignment, not just authentication.

Example 4: Server management reduction

Scenario:

A company wants to host a web application in Azure without managing the operating system of the underlying servers.

Reasoning:

• Goal: Host web app
• Constraint: Avoid OS management
• Category: Compute service model
• Best fit: A platform service such as Azure App Service

Why:

A virtual machine would provide control, but it would also require more OS-level management. The stated requirement points toward PaaS.

Example 5: Service impact visibility

Scenario:

An administrator wants to view Azure service incidents that may affect the company’s deployed resources.

Reasoning:

• Goal: View service issues affecting resources
• Category: Health and operations
• Best fit: Azure Service Health

Why:

Azure Monitor is for telemetry and alerts from resources and applications. Service Health is better aligned to Azure service incidents and planned maintenance information relevant to the organization.

Final Review Checklist for Scenario Questions

Before selecting an answer, confirm:

• I know whether the scenario is about cloud concepts, services, security, governance, cost, monitoring, or support.
• I identified the main goal or symptom.
• I separated mandatory requirements from background details.
• I know whether the answer should be a service, tool, feature, or concept.
• I checked whether the scenario is before deployment, during deployment, or after resources are running.
• I applied least privilege for access questions.
• I matched governance requirements to the correct control: policy, lock, tag, role, subscription, or management group.
• I avoided adding facts that the scenario did not provide.
• I chose the option that most directly satisfies the requirement.

How to Practice Efficiently

For each AZ-900 scenario you review, write a three-part note:

1. Decision point: What was the question really asking?
2. Key clue: Which word or phrase determined the answer?
3. Reason: Why was the chosen answer better than the nearest alternative?

Then rotate through focused drills:

• Cloud concepts and shared responsibility
• Azure compute, storage, database, and networking services
• Identity, access, and security controls
• Governance with subscriptions, policies, locks, tags, and management groups
• Pricing, cost tools, SLAs, and lifecycle concepts
• Monitoring, Azure Service Health, Advisor, and management tools

Next, use timed scenario practice or a full mock exam to apply this reading sequence under exam-like pressure. After each missed question, review the scenario facts first, then the answer choices, so your final review builds better decision habits rather than simple memorization.