Am I Ready for AZ-900? A Practical Readiness Checklist
Use this AZ-900 readiness checklist to decide whether to book, wait, or repair one weak area before Microsoft Azure Fundamentals.
Work through the guides and lessons behind this exam, then take the assessment to locate the weak areas still costing you points.
Recognize cloud computing by on-demand access, shared provider infrastructure, scaling, and usage-based cost.
Decide whether Microsoft or the customer owns the task by checking the layer and service model.
Pick the deployment model from ownership, access, control, cost, and placement details.
Use ownership, timing, and demand details to separate CapEx, OpEx, and pay-as-you-go cloud pricing.
Use serverless for event-driven code with minimal server management while keeping code and access responsibilities clear.
Separate staying online, adding capacity, and reacting automatically to demand.
Separate failure recovery, steady performance, and planned spending.
Separate built-in cloud protection, customer responsibility, governance guardrails, and auditability.
Learn the AZ-900 cloud manageability details for automation, templates, management channels, monitoring, and adjacent tool traps.
Use IaaS when the requirement needs infrastructure control, OS responsibility, or lift-and-shift compatibility.
Use PaaS when custom app or database work needs a managed platform instead of server administration.
Use SaaS when the learner needs a ready-made application rather than a platform or infrastructure to build on.
Separate deployment location, residency area, paired-region resilience, and sovereign cloud requirements.
Use zones for datacenter-level resilience inside a supported region; use other answers for residency or cross-region recovery.
Use resource groups when related Azure resources need shared lifecycle and scoped administration.
Use subscriptions for billing/access containers and management groups for inherited governance across subscriptions.
Pick the lowest Azure scope that covers the requirement and remember that governance inherits downward.
Pick virtual machines, containers, or functions by control needs, portability, and event-driven work.
Match the VM option to the need: one server, many identical VMs, datacenter resilience, zone resilience, or virtual desktops.
Match app hosting to the management model: managed web app, managed container host, or full VM control.
Separate packaged runtime, container orchestration, and event-triggered code.
Use scope details to tell a private network, a segment inside it, and VNet-to-VNet connectivity apart.
Separate encrypted internet VPN tunnels, user VPN access, private provider circuits, and adjacent networking services.
Separate public names, private VNet-only names, and networking features that DNS does not provide.
Separate internet-reachable service access from private IP access through Private Link.
Match the data shape first: objects, shared files, messages, or simple NoSQL table data.
Match hot, cool, cold, and archive tiers to access frequency, retrieval needs, and cost tradeoffs.
Match the redundancy option to the failure scope: datacenter, zone, region, or secondary read access.
Match the transfer job: command-line copy, graphical browsing, file sync, migration discovery, or offline bulk transfer.
Separate cloud identity from managed legacy domain compatibility needs.
Separate sign-in convenience, proof of identity, passwordless access, and outside-tenant collaboration.
Use sign-in conditions for Conditional Access and resource permissions for Azure RBAC.
Separate security philosophy, layered defense, and cloud security-posture management.
Find the resource setting, usage pattern, location, or bandwidth detail that changes the bill.
Separate estimating future Azure cost from analyzing and controlling running Azure spend.
Separate cost analysis, budget thresholds, alert notifications, and optimization recommendations.
Use tags for owner, environment, app, and cost-center labels used in organization and reporting.
Use catalog, classification, lineage, and compliance needs to identify Microsoft Purview.
Separate a single compliance rule, a grouped standard, access authorization, resource protection, and data governance.
Use locks for management-operation protection, and keep compliance rules in Azure Policy.
Separate browser-based management, hosted shell access, cross-platform CLI commands, and PowerShell object workflows.
Use Azure Arc when resources outside Azure need Azure-style management and governance.
Use repeatable declarative deployment details to identify IaC, ARM templates, or Bicep.
Use recommendations, telemetry, and service-health details to pick the right monitoring or guidance tool.
Separate personalized tenant health from public Azure-wide status.
Follow the monitoring workflow: collect a signal, query logs, and trigger an alert.
Separate app telemetry and request failures from central log queries and workspace analysis.