AZ Landscape common mistakes
AZ Landscape · Understand the traps and how to avoid them.
On any question that mentions availability zones, assumes the named region supports zones and that a zone equals a single datacenter, then selects a zone-redundant SKU without checking regional coverage.
Zone coverage is region-specific, and study material usually presents zones abstractly as 'separate physical locations', so the region-support check never enters the reasoning.
What to do instead
Before committing to a zone-redundant design, name the region in the stem and confirm it supports zones and that the specific service offers zonal or zone-redundant SKUs. Keep a written hierarchy: geography > region pair > region > availability zone > datacenter.
For any 'host this application' scenario, defaults to Virtual Machines and then adds patching, hardening, and cluster maintenance tasks to the design, even when the stem says the team has no OS administration capacity.
The VM is the most familiar model, and the scenario gets read as 'where can this run' instead of 'which operational responsibilities must be avoided'.
What to do instead
Underline the constraint words first (no OS patching, no cluster operations, per-second billing, legacy dependencies, GPU needs), then choose the lowest-management hosting model that still satisfies them: App Service or Container Apps for web workloads, AKS only when node-level control is an explicit requirement.
Selects the Functions Consumption plan for a workload that must join a virtual network, avoid cold starts, or run longer than the default execution timeout.
Consumption is listed first and is the cheapest option in most summaries, so cost dominates over networking and duration limits.
What to do instead
Memorize the three hosting trade-offs: Consumption (scale to zero, short timeout, no VNet integration), Premium (pre-warmed instances, VNet integration, longer duration), Dedicated/App Service plan (runs on existing plan capacity). Match the plan to the constraint stated in the stem.
Designs a hub-and-spoke topology with VNet peering only, then expects spokes to reach each other transitively or to share the hub's VPN/ExpressRoute gateway.
Peering is described as 'connected networks', while non-transitivity and gateway transit are treated as footnotes rather than design rules.
What to do instead
State explicitly that peering is non-transitive. For spoke-to-spoke traffic, add a firewall or NVA in the hub with user-defined routes; for shared connectivity, enable 'use remote gateway' on the spoke peerings, or use Azure Virtual WAN to get transitive routing by design.
Chooses site-to-site VPN when the requirement specifies private connectivity with predictable latency or high bandwidth, and also assumes an ExpressRoute circuit provides general internet access by default.
Both options fall under 'hybrid connectivity', and VPN is cheaper and faster to deploy, so it becomes the reflexive answer.
What to do instead
Map requirement to option: encrypted tunnel over the public internet = VPN Gateway; private dedicated circuit with a connectivity SLA = ExpressRoute, usually paired with a VPN for failover. Remember ExpressRoute requires Microsoft peering and route filters for Microsoft 365 and other Microsoft traffic, and gives no internet breakout by itself.
Treats GRS as a readable copy in the secondary region and selects it when the application must read from the secondary during an outage, or selects the Archive tier for data read monthly without accounting for rehydration time and cost.
The redundancy letters and access tier names are skimmed quickly, and redundancy plus access tiers get memorized as two disconnected lists.
What to do instead
Recite the ladder LRS, ZRS, GRS, GZRS and note that only RA-GRS and RA-GZRS permit secondary reads before failover. Separately memorize archive rehydration latency and the early-deletion penalties on cool, cold, and archive tiers, and check both dimensions against the stem.
Assigns a role at resource group or resource scope for a requirement that must apply across the whole subscription, or answers directory-administration tasks (creating users, resetting passwords) with Azure RBAC roles.
Azure RBAC and directory roles both use the word 'role' and appear side by side in the portal, and scope selection feels like a minor detail rather than the deciding factor.
What to do instead
Apply a two-question test: is the action on Azure resources (use Azure RBAC, scope = management group, subscription, resource group, or resource) or on the directory itself (use Microsoft Entra roles)? Then pick the narrowest scope that still covers every target resource named in the stem.
States that a budget prevents or stops spending, and assumes tags applied to a resource group flow down to its resources for cost reporting.
Budgets resemble hard spending limits in other platforms, and tag inheritance feels intuitive, so neither limitation gets tested until the exam.
What to do instead
Say plainly that budgets only raise alerts and can trigger action groups; hard caps require quotas, policies, or automation. For tags, apply them on each resource or use an Azure Policy that inherits tags from the resource group, and note that tags are not inherited by default for cost allocation.
Answers data and integration scenarios by naming the most familiar service, usually Synapse or Databricks, regardless of whether the stem describes ingestion, orchestration, transformation, or serving.
These services overlap heavily and their marketing descriptions blur, so candidates pattern-match on the word 'data' instead of on the pipeline stage being described.
What to do instead
Classify the stem by pipeline stage before choosing: ingest and move = Data Factory; SQL warehouse = Synapse dedicated SQL pool; Spark and ML = Databricks; streaming = Event Hubs or Stream Analytics; search and retrieval = AI Search. Choose by stage, not by brand familiarity.
Uses Azure Backup and Azure Site Recovery interchangeably, and answers RTO/RPO questions by picking whichever recovery product sounds more robust rather than by converting the stated numbers into a requirement.
Both are recovery products with overlapping wording, and RTO and RPO are read as near-synonyms instead of two separate targets.
What to do instead
Fix the distinction: Backup gives point-in-time data restore (typically minutes-to-hours RPO, hours RTO); Site Recovery replicates and fails over whole VMs or a region (minutes RTO). Write the stem's RTO and RPO next to each option before choosing, and reject any option that cannot meet the tighter of the two.