Identity & governanceAccess governance impact
Best match
Access review vs Privileged Identity Management
Choose Access review whenUse access reviews when the requirement is to ask owners or reviewers whether users should keep access.
Choose Privileged Identity Management whenUse PIM when the requirement is just-in-time privilege, activation approval, time-bound roles, or privileged-role audit evidence.
Access reviews verify whether access should continue; PIM governs activation and lifetime of privileged roles.
Decision details
Question: Do you need to periodically recertify access, or control how privileged access is activated?
Key differences
- Access reviews answer whether access remains appropriate.
- PIM answers how privileged access is granted and activated.
- The two often work together for sensitive roles.
Common mistake
Using PIM as a substitute for periodic access recertification, or using reviews without fixing standing privilege.
Check before deciding
- Separate recertification from activation.
- Identify the role, scope, reviewer, and activation requirement.
- Review audit evidence before making permanent access changes.
ContainersRegistry access impact
Best match
ACR admin user vs managed identity pull
Choose ACR admin user whenUse managed identity pull when an Azure workload can authenticate to ACR with scoped role assignment and no shared password.
Choose Managed identity pull whenUse the ACR admin user only for narrow break-glass or legacy scenarios where identity-based pull is not available.
ACR admin user enables broad registry username/password access; managed identity pull uses Azure identity and RBAC for secretless image access.
Decision details
Question: Should image pulls use a broad registry credential or a scoped Azure identity?
Key differences
- Managed identity can be scoped, rotated by platform lifecycle, and audited through role assignments.
- ACR admin user is a registry-wide credential and can become a shared secret.
- Kubernetes, Container Apps, App Service, and VM image pulls each have different identity wiring steps.
Common mistake
Leaving the ACR admin user enabled because it fixed a pull failure once, then spreading the same credential across environments.
Check before deciding
- Check current registry auth settings and role assignments before enabling or disabling admin user.
- Verify the workload identity has AcrPull at the right scope.
- Test image pull with a non-production revision, pod, or deployment before production rollout.
ContainersCluster / workload impact
Best match
ACR tag vs digest
Choose ACR tag whenUse a tag when humans and pipelines need a readable release label such as latest, prod, or v1.2.3.
Choose digest whenUse a digest when the deployment must prove the exact image bytes that are running.
A tag is a mutable human-friendly reference; a digest is a content-addressed identifier for an image manifest.
Decision details
Question: Do you need a human-friendly image label or an immutable reference to exact image content?
Key differences
- Tags can be moved to point at different image content.
- Digests identify immutable image content and are better for evidence, rollback, and supply-chain checks.
- Production investigations should record both the tag used and the resolved digest.
Common mistake
Deploying by a mutable tag and later being unable to prove what image actually ran during an incident.
Check before deciding
- Resolve the image digest before rollout and capture it in release evidence.
- Check running pods, revisions, or web app containers for the resolved image reference.
- Avoid using latest for production unless the pipeline records immutable provenance elsewhere.
MonitoringAlerting / notification impact
Best match
Action group vs Alert rule
Choose Alert rule whenUse an alert rule to define scope, signal, condition, threshold, evaluation frequency, and severity.
Choose Action group whenUse an action group to define recipients, webhooks, automation, ITSM, or other actions triggered by one or more alerts.
An alert rule decides when a signal should fire; an action group decides who or what gets notified or triggered.
Decision details
Question: Are you defining the condition that detects a problem, or the notification/action path after detection?
Key differences
- Alert rules detect; action groups notify or trigger response.
- One action group can be reused by many alert rules.
- Bad action groups create noise even when alert logic is correct.
Common mistake
Troubleshooting alert noise only by changing thresholds, while the real problem is a shared action group or receiver configuration.
Check before deciding
- List alert rules and their linked action groups.
- Confirm receivers, escalation path, and suppression rules before enabling.
- Test notification routing with non-production scope where possible.
DataBusiness continuity impact
Best match
Active geo-replication vs failover group
Choose Active geo-replication whenUse active geo-replication when the design needs readable secondaries or independent database-level replication control.
Choose Failover group whenUse failover groups when the design needs coordinated failover, multiple databases, and stable read/write listener endpoints.
Active geo-replication creates readable secondary databases; failover groups coordinate failover and listener-style endpoints across databases.
Decision details
Question: Do you need individual database replicas, or grouped failover with application-friendly endpoints?
Key differences
- Geo-replication is database-centric.
- Failover groups organize failover behavior and endpoints.
- Application connection strings and RTO/RPO goals often decide the better answer.
Common mistake
Creating replicas but forgetting that the application also needs a failover connection strategy.
Check before deciding
- Identify databases, replicas, failover groups, and listener endpoints.
- Confirm RPO/RTO and application connection behavior.
- Test failover in a controlled window before relying on it.
AI + dataAI solution organization
Best match
AI Foundry project vs Azure AI services resource
Choose AI Foundry project whenUse an AI Foundry project when the exam scenario is about building, evaluating, or coordinating model, prompt, agent, and app assets.
Choose Azure AI services resource whenUse an Azure AI services resource when the scenario is about endpoint access, keys, network rules, identity, region, quota, or billing.
AI Foundry projects organize development assets and collaboration; Azure AI services resources expose service endpoints, keys, identity, networking, and billing boundaries.
Decision details
Question: Are you organizing an AI development workspace or controlling the deployed service endpoint that apps call?
Key differences
- A project is a workspace-level organizing concept; a service resource is the deployable Azure control-plane boundary.
- Resources carry keys, endpoints, managed identity, private endpoints, and diagnostic settings.
- Projects help learners reason about app lifecycle, but production security still lives at the resource, identity, and network layers.
Common mistake
Assuming a project setting secures all deployed endpoints. Exam scenarios often separate development workspace choices from resource-level access and network controls.
Check before deciding
- Identify whether the question is asking about development organization or runtime endpoint control.
- Check service resource keys, identity, network rules, and deployments before release.
- Open the AI services runbook before changing keys, networking, or model deployments.
AI + dataSearch ingestion path
Best match
AI Search indexer vs manual ingestion
Choose AI Search indexer whenUse an indexer when the source is supported and scheduled pull/indexing behavior fits the data refresh pattern.
Choose Manual ingestion whenUse manual ingestion when the content requires custom transforms, event-driven updates, non-supported sources, or strict app-controlled indexing.
Indexers pull content from supported data sources; manual ingestion pushes prepared documents into an index from app or pipeline code.
Decision details
Question: Should the search service crawl/pull from a data source or should your application push indexed documents?
Key differences
- Indexers depend on data-source credentials, skillsets, schedules, and indexer status.
- Manual ingestion shifts transformation, retries, and error handling into app/pipeline code.
- Exam questions often reveal the answer through data-source support, refresh cadence, or required transformations.
Common mistake
Debugging query relevance while ignoring indexer failures or stale source-to-index refresh status.
Check before deciding
- Check indexer status and error messages before changing index schema.
- Confirm whether the source is supported by an indexer.
- Use manual ingestion when transformations or event timing require app ownership.
ContainersCluster / workload impact
Best match
AKS system vs user node pool
Choose AKS system whenUse the system node pool for critical cluster services and add-ons required for the AKS control experience.
Choose user node pool whenUse user node pools for application workloads, scaling profiles, GPU/spot nodes, isolation, or workload-specific sizing.
System node pools host critical cluster components; user node pools are meant for application workloads and specialized capacity.
Decision details
Question: Is the node pool meant to keep AKS system components healthy, or to run application workloads?
Key differences
- System pools protect cluster operations; user pools carry app workload capacity.
- Scaling or tainting the wrong pool can break DNS, ingress, monitoring, or critical add-ons.
- User pools let teams separate cost, autoscale behavior, OS image, SKU, and workload placement.
Common mistake
Running most application pods on the system pool, then making node pool changes that affect cluster reliability.
Check before deciding
- List node pools, modes, taints, labels, and current pod placement before changes.
- Check system add-on health and pending pods before scaling or upgrading pools.
- Plan workload movement and surge capacity before changing production node pools.
ContainersCluster identity impact
Best match
AKS Workload Identity vs Managed Identity
Choose AKS Workload Identity whenUse AKS Workload Identity when individual pods or service accounts need scoped Azure access without node-level secrets.
Choose Managed Identity whenUse managed identity directly when the Azure resource itself can hold the identity and pod-level federation is not needed.
AKS Workload Identity federates Kubernetes service accounts to Entra identities; managed identity is the Azure identity used by resources or cluster components.
Decision details
Question: Does a Kubernetes workload need its own Azure identity, or is the identity attached at the Azure resource level enough?
Key differences
- Workload Identity maps Kubernetes service accounts to Azure identity through federation.
- Managed identity is the Azure identity object, but AKS workloads still need a safe way to assume it.
- The blast radius depends on service account binding, federated credential setup, and assigned Azure roles.
Common mistake
Granting broad identity permissions to the cluster or node path instead of the specific workload that needs access.
Check before deciding
- List service accounts, federated credentials, and role assignments before enabling access.
- Use the smallest Azure scope and role that satisfies the workload.
- Test token acquisition and resource access from a non-production pod before rollout.
AI + dataAI access control
Best match
API key vs managed identity for AI service access
Choose API key whenUse API keys when the service path or SDK requires key-based access and key storage/rotation is controlled.
Choose Managed identity whenUse managed identity when the app and service support identity-based access and you can scope roles without storing secrets.
API keys are shared secrets for service access; managed identity uses Azure identity and RBAC where supported for secretless access.
Decision details
Question: Should the app call the AI service with a stored key or Azure identity?
Key differences
- Keys are simple but can leak and must be rotated.
- Managed identity reduces secret handling but requires role assignment and supported service integration.
- Exam scenarios often mention Key Vault, app settings, identity, or least privilege as clues.
Common mistake
Putting an AI service key directly in app settings or code because it made the first demo work.
Check before deciding
- Check whether the target AI service supports identity-based access for the operation.
- If keys are used, store them in Key Vault and rotate them.
- List role assignments and app identity before changing access.
NetworkingReachability impact
Best match
API Management vs Application Gateway
Choose API Management whenUse API Management when the job is publishing APIs, applying API policies, managing subscriptions, versioning, and developer access.
Choose Application Gateway whenUse Application Gateway when the job is regional HTTP routing, TLS termination, backend pools, path rules, and WAF protection.
API Management governs APIs with products, subscriptions, operations, and policies; Application Gateway routes web traffic and can apply WAF controls.
Decision details
Question: Do you need API product management and policies, or Layer 7 ingress and WAF routing?
Key differences
- API Management understands APIs, operations, products, subscriptions, policies, and developer portals.
- Application Gateway understands listeners, routing rules, probes, backend pools, and WAF at the application ingress layer.
- They can be used together: gateway for ingress/WAF, APIM for API governance.
Common mistake
Expecting Application Gateway to replace API lifecycle management, or using APIM as a generic WAF/load balancer.
Check before deciding
- Draw the request path from client to backend before choosing.
- Check TLS, private networking, WAF, authentication, API policies, and subscription-key needs.
- Review existing routes, products, policies, and backend health before changing exposure.
App hostingConfiguration and secret handling impact
Best match
App Configuration vs Key Vault secret
Choose App Configuration whenUse App Configuration for non-secret application settings, feature flags, central configuration, and refresh behavior.
Choose Key Vault secret whenUse Key Vault secrets for sensitive values such as passwords, tokens, connection strings, and certificates that need secret access controls.
App Configuration stores application settings and feature flags; Key Vault secrets store sensitive values that need secret-management controls.
Decision details
Question: Is the value application configuration/feature state, or a sensitive secret that requires secret lifecycle controls?
Key differences
- App Configuration organizes app settings and feature flags.
- Key Vault stores secrets, keys, and certificates with sensitive-access controls.
- Apps often use both: App Configuration references Key Vault for secret values.
Common mistake
Putting secrets directly into general configuration because it is convenient for deployment.
Check before deciding
- Classify the value before storing it.
- Use managed identity to read secrets instead of embedding credentials.
- Review access policies/RBAC and diagnostic settings before production.
App hostingHosting / scale impact
Best match
App Service plan vs Functions hosting plan
Choose App Service plan whenUse an App Service plan when hosting web apps, APIs, and containers that need app service features, scaling, and predictable web hosting behavior.
Choose Functions hosting plan whenUse a Functions hosting plan when the workload is event-driven and plan choice affects scale, cold start, networking, and execution limits.
App Service plans allocate web app compute; Functions hosting plans determine event-driven compute scale, cold-start, networking, and runtime behavior.
Decision details
Question: Are you hosting a long-running web app/API, or event-driven functions with plan-specific scaling behavior?
Key differences
- App Service plan capacity is shared by App Service apps.
- Functions plans include Consumption, Premium, and Dedicated choices with different scaling and networking behavior.
- A Function App can run on an App Service plan, but that is not the same as the Functions Consumption or Premium model.
Common mistake
Treating all Functions deployments as serverless consumption, then missing Premium plan, VNet, and cold-start requirements.
Check before deciding
- Review runtime, scaling, networking, and cost requirements.
- List app settings and deployment source before moving plans.
- Use deployment runbooks before production slot or scale changes.
App hostingDeployment impact
Best match
App Service slot swap vs direct production deployment
Choose Slot swap whenUse a deployment slot when you need warm-up, validation, sticky settings, quick rollback, or lower-risk production cutover.
Choose Direct production deployment whenUse direct production deployment only for low-risk changes where rollback, warm-up, and configuration drift are already controlled elsewhere.
Slot swap stages a release in a deployment slot and swaps traffic; direct production deployment changes the live app path immediately.
Decision details
Question: Can the release be warmed, tested, and swapped, or is a direct production deployment acceptable?
Key differences
- Slot swap changes routing between slots; direct deployment changes the active production app in place.
- Slots need attention to sticky app settings, connection strings, health checks, and warm-up behavior.
- Direct deployment is simpler but leaves less room to catch startup, dependency, or configuration failures before users see them.
Common mistake
Swapping without checking slot-specific settings, then sending production traffic to an app with staging secrets, wrong endpoints, or cold startup failures.
Check before deciding
- Compare app settings, connection strings, runtime stack, and health checks between slots.
- Warm and test the target slot before swap; record the rollback path.
- Use Activity Log and deployment logs to capture who changed what and when.
App hostingDeployment impact
Best match
App Service vs Azure Functions
Choose App Service whenUse App Service for web apps, APIs, containers, or long-running app processes that need a stable hosting surface.
Choose Azure Functions whenUse Azure Functions when work is trigger-driven, event-based, scheduled, or naturally split into small units of execution.
App Service is application hosting; Azure Functions is event-driven serverless execution with triggers and bindings.
Decision details
Question: Is this a continuously hosted web/API app, or event-driven code that should run on triggers?
Key differences
- App Service centers on sites, plans, slots, runtime stacks, and always-on application hosting.
- Functions centers on triggers, bindings, scale plans, host settings, and execution duration.
- App Service usually gives simpler web-app control; Functions can reduce idle cost but adds trigger, cold-start, and plan-choice concerns.
Common mistake
Choosing Functions for a normal web app because it sounds cheaper, then fighting cold starts, long execution, and trigger complexity.
Check before deciding
- Identify request pattern, execution duration, state needs, and deployment workflow first.
- Check runtime stack, scaling plan, VNet/private access, and observability needs before choosing.
- If moving between platforms, map secrets, managed identity, custom domains, and CI/CD separately.
App hostingDeployment impact
Best match
App Service vs Static Web Apps
Choose App Service whenUse App Service when the app needs server-side runtime control, custom containers, background processes, slots, or richer networking options.
Choose Static Web Apps whenUse Static Web Apps for static front ends, JAMstack-style sites, branch environments, and simple integrated API/back-end patterns.
App Service hosts dynamic web apps and APIs on App Service plans; Static Web Apps focuses on static front ends, preview environments, and integrated backend APIs.
Decision details
Question: Do you need a server-side app platform, or mostly static front-end hosting with managed build and routing?
Key differences
- App Service hosts dynamic server workloads; Static Web Apps optimizes static assets, routes, auth, and preview environments.
- App Service exposes more plan, runtime, networking, and deployment-slot controls.
- Static Web Apps can simplify front-end delivery but may not fit complex server-side hosting or custom network requirements.
Common mistake
Putting a dynamic app into Static Web Apps and later discovering that runtime, private networking, or deployment needs belong in App Service.
Check before deciding
- Confirm whether the workload serves static files, dynamic server code, APIs, or containers.
- Check custom domain, auth, API, and environment requirements before migrating.
- Review deployment tokens, GitHub workflow, and backend links before production changes.
NetworkingReachability impact
Best match
Application Gateway vs Front Door
Choose Application Gateway whenUse Application Gateway for regional Layer 7 load balancing, private backend integration, and WAF close to the VNet/application region.
Choose Front Door whenUse Front Door for global edge entry, anycast routing, acceleration, global failover, and edge WAF behavior.
Application Gateway is regional HTTP load balancing; Front Door is global edge routing with endpoints, origins, routes, caching, and WAF policies.
Decision details
Question: Is the entry point regional and VNet-oriented, or global edge-facing?
Key differences
- Application Gateway is regional; Front Door is a global edge service.
- Application Gateway often sits near private backends; Front Door fronts global public entry and origin routing.
- DNS, TLS, WAF policy, health probes, and origin exposure differ significantly.
Common mistake
Choosing based only on WAF without deciding where traffic should enter: global edge or regional network boundary.
Check before deciding
- Map client locations, origin regions, private/public origin requirements, and failover needs.
- Inspect current listeners, origins/backends, probes, TLS, and WAF policies.
- Test health probe and failover behavior before changing production routing.
NetworkingTraffic filtering impact
Best match
Application Security Group vs Network Security Group
Choose Application Security Group whenUse an Application Security Group to group VM NICs by application role so NSG rules can target them cleanly.
Choose Network Security Group whenUse a Network Security Group to define inbound and outbound security rules on subnets or NICs.
An Application Security Group groups VM NICs for rule targeting; an NSG is the actual traffic-filtering control applied to subnets or NICs.
Decision details
Question: Are you grouping application NICs for rule targeting, or defining the actual network allow/deny rules?
Key differences
- ASGs are labels/targets; NSGs are the rule enforcement point.
- NSGs attach to subnets or NICs and evaluate priority-based rules.
- ASGs can make NSG rules more readable but do not filter traffic by themselves.
Common mistake
Creating ASGs and assuming traffic is filtered without confirming NSG rules reference them.
Check before deciding
- List NIC ASG membership and NSG associations before changing rules.
- Check effective security rules on the VM/NIC to see what is actually applied.
- Review rule priority, direction, source, destination, and port before allowing exposure.
Backup & resilienceResilience / availability impact
Best match
Availability zone vs Availability set
Choose Availability zone whenUse availability zones when supported services need regional-zone separation and the architecture can handle zone-aware networking, storage, and failover behavior.
Choose Availability set whenUse availability sets for classic VM availability grouping where zone placement is not required or not supported by the deployment pattern.
Availability zones separate resources across datacenter zones in a region; availability sets spread VMs across fault and update domains inside a datacenter placement model.
Decision details
Question: Do you need zone-level regional resiliency, or only VM fault/update-domain separation for a single workload tier?
Key differences
- Zones are a regional resiliency feature; availability sets are a VM placement feature.
- Zones usually affect network, storage, and cross-zone latency design; availability sets mostly affect VM fault/update-domain placement.
- Newer architectures often prefer zones where service and region support are available; availability sets still appear in VM-focused scenarios.
Common mistake
Assuming an availability set protects against a full zone failure. It does not provide the same regional-zone isolation as availability zones.
Check before deciding
- Check whether the region and target service support zones.
- List VM, disk, public IP, load balancer, and app dependencies before choosing a resiliency model.
- Open related backup and VM runbooks before changing production placement.
CostGovernance / optimization impact
Best match
Azure Advisor recommendation vs Policy compliance
Choose Advisor recommendation whenUse Advisor recommendations to find cost, reliability, performance, operational, and security improvement opportunities.
Choose Policy compliance whenUse Policy compliance when resources must be evaluated against required organizational rules and effects.
Advisor recommendations suggest improvements; Policy compliance reports whether resources meet assigned governance rules.
Decision details
Question: Are you looking at optimization guidance, or checking compliance against assigned rules?
Key differences
- Advisor is recommendation-driven; Policy is assignment/evaluation-driven.
- Advisor findings are not the same as policy non-compliance.
- Policy can deny, audit, append, modify, or deploy settings depending on effect.
Common mistake
Treating Advisor cleanup as mandatory compliance remediation without checking business owner, exemption, and policy requirements.
Check before deciding
- Separate recommendation triage from compliance remediation.
- Check resource owner, tag, and impact before acting.
- Use related runbooks to collect evidence before changes.
AI + dataResponsible AI control
Best match
Azure AI Content Safety vs Prompt Shields
Choose Content Safety whenUse Content Safety when the scenario is detecting or filtering harmful user/model content categories.
Choose Prompt Shields whenUse Prompt Shields when the scenario is about prompt injection, jailbreaks, or malicious instructions in user/input documents.
Content Safety classifies harmful content; Prompt Shields help detect prompt-injection or jailbreak-style attacks against AI systems.
Decision details
Question: Are you filtering harmful content or defending the prompt/tool flow from malicious instructions?
Key differences
- Content Safety focuses on content category risk; Prompt Shields focus on attack patterns against instructions and grounding.
- Production systems may need both, plus human review and logging.
- Prompt-injection risk becomes more important when agents, tools, or retrieval are involved.
Common mistake
Assuming content moderation alone protects agent tools or system prompts from malicious retrieved text.
Check before deciding
- Classify the threat: harmful content, prompt injection, data leakage, or unsafe tool action.
- Log and review blocked/flagged cases before loosening controls.
- Test with adversarial prompts and retrieved content, not only normal happy-path prompts.
AI + dataSearch / generation impact
Best match
Azure AI Search vs Azure OpenAI
Choose Azure AI Search whenUse Azure AI Search when the hard problem is indexing, filtering, ranking, or retrieving approved content from your own corpus.
Choose Azure OpenAI whenUse Azure OpenAI when the hard problem is generation, summarization, extraction, reasoning, or transformation through a deployed model.
AI Search retrieves and ranks grounded content; Azure OpenAI generates, summarizes, reasons over, or transforms content through deployed models.
Decision details
Question: Are you trying to retrieve grounded content, generate model output, or combine both in a RAG flow?
Key differences
- AI Search owns indexes, analyzers, vector fields, data sources, indexers, and retrieval ranking.
- Azure OpenAI owns model deployments, prompt behavior, token usage, and generation quality.
- Many production designs use both: Search retrieves evidence, then OpenAI produces the answer grounded on that evidence.
Common mistake
Treating Azure OpenAI as a knowledge base. Without retrieval, permissions, and grounding, model output may not reflect your approved data.
Check before deciding
- List the data sources, indexes, and model deployments involved before choosing the pattern.
- Test a real query with expected citations or source IDs, not only a demo prompt.
- Check indexing cost, token cost, access controls, and private-network requirements before production rollout.
AI + dataVision/document extraction
Best match
Azure AI Vision OCR vs Document Intelligence
Choose AI Vision OCR whenUse AI Vision OCR when the scenario is image text extraction or visual analysis without document-specific field extraction.
Choose Document Intelligence whenUse Document Intelligence when the scenario is forms, invoices, layouts, tables, fields, or document-processing workflows.
AI Vision OCR reads text from images; Document Intelligence is built for structured document extraction and document-specific models.
Decision details
Question: Are you reading text from images or extracting structured fields from documents?
Key differences
- Vision OCR is image-centric; Document Intelligence is document-centric.
- Document Intelligence adds layout, prebuilt models, and custom extraction choices.
- The right answer often depends on whether the exam scenario asks for fields/tables or raw text.
Common mistake
Using generic OCR for document workflows that require field confidence, tables, or model-specific extraction.
Check before deciding
- Identify whether the input is an image, document, form, or invoice.
- Check whether raw text is enough or structured fields are required.
- Review endpoint, key, region, and network access before deployment.
NetworkingManagement exposure impact
Best match
Azure Bastion vs public IP management access
Choose Azure Bastion whenUse Azure Bastion when VM management should avoid public RDP/SSH exposure and remain inside controlled Azure access paths.
Choose Public IP management access whenUse public IP management access only for tightly controlled temporary scenarios with explicit exposure review and compensating controls.
Azure Bastion provides browser or native-client VM access through a managed service; public IP management exposes VM management ports directly to the internet.
Decision details
Question: Should operators reach VMs through managed private access, or expose RDP/SSH on public IPs?
Key differences
- Bastion avoids direct public management ports on each VM.
- Public IP management access creates internet-reachable management surfaces.
- NSGs reduce exposure but do not turn public management into private access.
Common mistake
Opening port 22 or 3389 temporarily and forgetting that the public IP plus NSG rule remains an attack surface.
Check before deciding
- Inventory public IPs and inbound management rules.
- Confirm Bastion subnet and VM reachability before removing access.
- Use just-in-time or change-window controls for any temporary exposure.
CostCost governance impact
Best match
Azure budget vs Cost alert
Choose Azure budget whenUse budgets to define expected spend boundaries and threshold notifications for a scope.
Choose Cost alert / anomaly signal whenUse cost alerts, anomaly review, Advisor, or cost analysis when you need to investigate unexpected cost changes and drivers.
An Azure budget tracks planned spend and threshold notifications; cost alerts or anomaly signals help detect unexpected changes in actual spend.
Decision details
Question: Are you setting planned spend guardrails, or detecting unusual cost movement after it happens?
Key differences
- Budgets are proactive guardrails; cost anomaly review is investigative.
- Budgets need correct scope and recipients.
- Cost investigation usually needs tags, resource ownership, and usage evidence.
Common mistake
Creating a budget without validating scope, contact path, or the resources that actually drive spend.
Check before deciding
- Check budget scope, thresholds, and action groups.
- Review month-to-date cost by service, resource group, and tag.
- Use cost runbooks before deleting or resizing resources.
NetworkingReachability impact
Best match
Azure Firewall vs Network Security Group
Choose Azure Firewall whenUse Azure Firewall for centralized inspection, rule collections, threat intelligence, routing control, and shared network security policy.
Choose Network Security Group whenUse Network Security Groups for subnet or NIC allow/deny rules close to workloads.
Azure Firewall is a managed network security service for centralized inspection and policy; an NSG filters traffic at subnet or network-interface scope.
Decision details
Question: Do you need centralized stateful network policy, or subnet/NIC-level traffic filtering?
Key differences
- Azure Firewall is a managed firewall appliance/service in the network path.
- NSGs are distributed rule sets applied to subnets or NICs.
- Firewall policy often works with route tables; NSG behavior is inspected through effective security rules.
Common mistake
Adding firewall rules while traffic still bypasses the firewall because routes or subnet associations were not checked.
Check before deciding
- Map routes, subnets, next hop, and NSG rules before editing firewall policy.
- Check firewall logs and rule collection priority before adding broad allows.
- Use effective routes and effective NSG output to prove the actual path.
NetworkingGlobal routing impact
Best match
Azure Front Door vs Traffic Manager
Choose Azure Front Door whenUse Front Door when the scenario needs HTTP/S acceleration, path/host routing, TLS at edge, WAF, origin groups, or global web ingress.
Choose Traffic Manager whenUse Traffic Manager when DNS-based routing across endpoints is enough and request proxying or WAF is not required.
Front Door is a global HTTP/S edge, routing, acceleration, and WAF service; Traffic Manager is DNS-based traffic distribution.
Decision details
Question: Do you need layer-7 HTTP/S edge features, WAF, and origin routing, or DNS-level endpoint selection?
Key differences
- Front Door proxies HTTP/S traffic at the edge.
- Traffic Manager returns DNS answers and does not inspect or proxy requests.
- WAF and path-based routing are Front Door/Application Gateway style clues, not Traffic Manager clues.
Common mistake
Choosing Traffic Manager when the requirement says WAF, HTTP path routing, TLS edge, or origin health routing.
Check before deciding
- Identify layer 7 versus DNS requirements.
- List origins/endpoints and health-probe behavior.
- Check WAF/routing rules before changing production ingress.
MonitoringSignal selection impact
Best match
Azure Monitor metrics vs logs
Choose Metrics whenUse Azure Monitor metrics for fast numeric signals such as CPU, requests, latency, failures, or capacity counters.
Choose Logs whenUse logs when you need detailed records, correlation, joins, text search, or custom KQL investigation.
Metrics are numeric time-series signals optimized for fast alerting and charts; logs are queryable records that provide richer event and diagnostic context.
Decision details
Question: Can a numeric time-series signal answer the question, or do you need queryable event/detail evidence?
Key differences
- Metrics are lightweight, structured time series and usually better for fast alerting.
- Logs are richer and queryable but depend on ingestion, retention, schema, and cost.
- Good observability uses metrics for symptoms and logs for explanation.
Common mistake
Sending everything to logs and creating expensive noisy alerts for questions that a simple metric could answer.
Check before deciding
- Define the question before choosing signal type: symptom, cause, audit, or evidence.
- Check available metrics, diagnostic settings, tables, and retention before enabling new ingestion.
- Estimate alert noise and ingestion cost before production rollout.
MonitoringVisualization and review impact
Best match
Azure Monitor workbook vs Azure dashboard
Choose Azure Monitor workbook whenUse workbooks for rich monitoring guides, KQL-driven investigation, parameters, drilldowns, and repeatable review flows.
Choose Azure dashboard whenUse dashboards for lightweight, shared, pinned views that operators can open quickly.
Workbooks provide interactive monitoring reports with queries, parameters, and rich visualizations; dashboards pin selected tiles for quick operational views.
Decision details
Question: Does the team need an interactive investigation report, or a simple pinned operational view?
Key differences
- Workbooks are more interactive and query/report oriented.
- Dashboards are simpler pinned views.
- Workbooks are usually better for guided troubleshooting and readiness reviews.
Common mistake
Building a dashboard when the real need is an interactive investigation report with parameters and KQL.
Check before deciding
- Identify audience and workflow: quick glance or guided investigation.
- Check underlying metrics/logs before creating visualizations.
- Keep sensitive query output and sharing scope in mind.
Identity & governanceAccess / policy impact
Best match
Azure Policy vs Management Locks
Choose Azure Policy whenUse Azure Policy to audit, deny, append, or remediate resources based on compliance rules.
Choose Management Locks whenUse management locks when the immediate requirement is to prevent accidental delete or write operations at a scope.
Policy evaluates compliance and can deny or remediate; locks directly restrict delete or update operations at a scope.
Decision details
Question: Do you need to govern what configurations are allowed, or prevent writes/deletes at a scope?
Key differences
- Policy evaluates resource configuration and can enforce governance at scale.
- Locks block operations regardless of why the operation was requested.
- Locks can interrupt legitimate automation; policy can block deployments if definitions or exemptions are wrong.
Common mistake
Using a lock as a governance program or using policy to protect a critical resource from accidental deletion when a lock is the direct control.
Check before deciding
- Check current policy assignments, exemptions, and locks before changing either control.
- Confirm the target scope and whether automation relies on write/delete operations.
- Record compliance or lock evidence before applying enforcement.
Identity & governanceAccess / policy impact
Best match
Azure RBAC vs Azure Policy
Choose Azure RBAC whenUse Azure RBAC to control which identities can perform actions at management or data scopes.
Choose Azure Policy whenUse Azure Policy to control, audit, or remediate resource configuration regardless of which allowed identity deployed it.
RBAC controls who can act; Azure Policy controls what resource states are allowed or remediated.
Decision details
Question: Is the problem who can act, or what configurations are allowed once someone acts?
Key differences
- RBAC answers who can perform an operation.
- Policy answers whether the resulting resource state is allowed or compliant.
- Strong governance usually uses both: least-privilege RBAC plus policy guardrails.
Common mistake
Trying to fix broad Owner access with policy alone, or trying to enforce tagging and regions with RBAC alone.
Check before deciding
- List role assignments and policy assignments at the same scope before changing access.
- Identify whether the failure is authorization or policy denial.
- Use exemptions and custom roles carefully, with evidence and owner approval.
OperationsDiscovery vs telemetry
Best match
Azure Resource Graph vs Log Analytics KQL
Choose Azure Resource Graph whenUse Resource Graph when the question is inventory, configuration, exposure, ownership, policy, or resource relationships across subscriptions.
Choose Log Analytics KQL whenUse Log Analytics KQL when the question is runtime events, logs, metrics-derived tables, errors, alerts, or historical telemetry in a workspace.
Resource Graph queries Azure resource inventory/control-plane state; Log Analytics queries collected telemetry, logs, and table data.
Decision details
Question: Are you trying to find Azure resources and configuration or analyze collected logs and telemetry?
Key differences
- Resource Graph is read-only resource inventory; Log Analytics depends on data collection and workspace retention.
- Resource Graph is excellent before changes; Log Analytics is excellent after activity has happened.
- Exam scenarios often reveal the answer by saying “resources configured as” versus “logs/events show.”
Common mistake
Expecting Resource Graph to contain app logs or expecting Log Analytics to know every resource that lacks diagnostic settings.
Check before deciding
- Classify the question as inventory/configuration or telemetry/events.
- Use Resource Graph before risky changes to find affected resources.
- Use Log Analytics after diagnostics are enabled and data has been collected.
DataData platform impact
Best match
Azure SQL Database vs SQL Managed Instance
Choose Azure SQL Database whenUse Azure SQL Database when the unit of management is a database or elastic pool and platform-managed simplicity is the priority.
Choose SQL Managed Instance whenUse SQL Managed Instance when the workload needs broader SQL Server compatibility, instance-level features, or easier lift-and-shift behavior.
Azure SQL Database is database-scoped PaaS; SQL Managed Instance preserves more instance-level SQL Server compatibility. Also covers: Azure SQL Database vs SQL Managed Instance.
Decision details
Question: Do you need a managed database surface, or SQL Server instance-level compatibility?
Key differences
- Azure SQL Database optimizes database-level PaaS management and scaling.
- Managed Instance keeps more instance-level capabilities and network isolation patterns.
- Compatibility, cross-database behavior, SQL Agent needs, networking, and migration path should drive the choice.
Common mistake
Choosing Azure SQL Database for a lift-and-shift workload that quietly depends on instance-level SQL Server features.
Check before deciding
- Inventory SQL Server features, cross-database dependencies, jobs, linked servers, and network requirements.
- Check restore, failover, backup, and maintenance expectations before choosing.
- Run a migration compatibility assessment before committing the target service.
DataRelational performance and cost impact
Best match
Azure SQL elastic pool vs single database
Choose Elastic pool whenUse an elastic pool when many databases have variable demand and can share a common compute budget.
Choose Single database whenUse a single database when one database needs independent sizing, performance isolation, or simple one-workload management.
Elastic pools share compute across many databases with variable demand; single databases isolate compute for one database workload.
Decision details
Question: Are many databases sharing unpredictable utilization, or does one database need isolated capacity?
Key differences
- Elastic pools smooth cost across multiple variable databases.
- Single databases isolate compute and scaling decisions.
- Pool sizing must account for noisy neighbors and aggregate peak demand.
Common mistake
Putting one hot database into a pool and expecting cost savings without checking peak and per-database limits.
Check before deciding
- List databases, SKU, pool membership, and utilization patterns.
- Check per-database and pool limits before moving workloads.
- Review Query Store and performance metrics before scaling.
DataData platform impact
Best match
Azure SQL vs Cosmos DB
Choose Azure SQL whenUse Azure SQL when relational modeling, joins, transactions, SQL compatibility, and structured reporting are central.
Choose Cosmos DB whenUse Cosmos DB when the workload needs globally distributed, low-latency NoSQL access with a well-designed partition key.
Azure SQL is managed relational data; Cosmos DB is globally distributed NoSQL and multi-model data with tunable consistency and throughput.
Decision details
Question: Is the workload relational with SQL-style constraints, or globally distributed NoSQL with partition-first access patterns?
Key differences
- Azure SQL favors relational schema, query consistency, and mature SQL ecosystem behavior.
- Cosmos DB favors partitioned NoSQL scale, multiple APIs, global distribution, and RU-based throughput planning.
- The Cosmos DB partition key and access pattern are architecture decisions, not afterthoughts.
Common mistake
Choosing Cosmos DB for scale without proving the partition key, query pattern, and RU cost model.
Check before deciding
- Map entities, query patterns, transaction boundaries, and data growth before choosing.
- Estimate throughput, indexing, region, and consistency requirements.
- Prototype the highest-volume query path and measure latency and cost.
Backup & resilienceRecovery impact
Best match
Backup vault vs Recovery Services vault
Choose Backup vault whenUse Backup vault for workloads supported by Azure Backup's newer data-protection model and policy flow.
Choose Recovery Services vault whenUse Recovery Services vault where the workload, migration state, or recovery feature set still depends on that vault model.
Backup vault is used by newer Azure Backup workloads; Recovery Services vault supports classic backup and site recovery scenarios.
Decision details
Question: Which vault type matches the workload you need to protect and the recovery operation you must prove?
Key differences
- Vault choice is workload-driven; not every protected item can move freely between vault types.
- Backup policies, recovery points, soft delete, and cross-region behavior must be checked per vault.
- Operational teams need to know which vault owns the protected item before testing restore.
Common mistake
Creating a vault because the name sounds right, then discovering the workload or restore flow is supported by the other vault type.
Check before deciding
- List protected items, policies, and recent backup jobs before changing vault setup.
- Confirm restore requirements with the application or data owner, not only the infrastructure team.
- Run a non-destructive restore-readiness review before any production recovery action.
App hostingDeployment impact
Best match
Bicep vs ARM Template
Choose Bicep whenUse Bicep when humans will author and maintain the Azure infrastructure code.
Choose ARM Template whenUse ARM templates directly when you already receive generated JSON, need exact low-level representation, or maintain legacy deployments.
Bicep is a cleaner language that compiles to ARM template JSON; ARM templates are the JSON deployment representation.
Decision details
Question: Do you want cleaner infrastructure authoring, or raw ARM JSON compatibility for generated or legacy templates?
Key differences
- Bicep is a higher-level authoring language that compiles to ARM JSON.
- ARM templates are the underlying deployment format, but they are more verbose and harder to review by hand.
- Both deploy through ARM, so what-if, scope, parameters, and deployment mode still matter.
Common mistake
Assuming Bicep makes a deployment safe. The same wrong scope, parameters, or complete-mode deployment can still create or delete resources.
Check before deciding
- Run what-if at the correct scope before applying either format.
- Review parameters, deployment mode, and target scope with the resource owner.
- Check deployment history and operation errors before rerunning a failed deployment.
StorageData access impact
Best match
Blob Storage vs Azure Files
Choose Blob Storage whenUse Blob Storage for object storage, HTTP/REST access, data lakes, backups, media, logs, and application objects.
Choose Azure Files whenUse Azure Files when applications or users need SMB/NFS-style shared file access with directory semantics.
Blob Storage is object storage; Azure Files provides managed SMB/NFS file shares.
Decision details
Question: Does the workload need object storage, or a managed file share protocol?
Key differences
- Blob is object storage; Azure Files is managed file share storage.
- Azure Files has share quota, protocol, identity, mount, and snapshot considerations.
- Blob has containers, tiers, lifecycle, versioning, immutability, and SAS/public access considerations.
Common mistake
Using Azure Files as a general object store or Blob Storage as a drop-in replacement for a mounted file share.
Check before deciding
- Confirm required access protocol, permissions, performance, backup, and restore behavior.
- Check public access, SAS/key usage, private endpoints, and lifecycle rules before exposing data.
- Test client access from the actual network and identity path.
StorageData access impact
Best match
Blob Storage vs Data Lake Storage Gen2
Choose Blob Storage whenUse Blob Storage for general object workloads where containers, blobs, tiers, and lifecycle policy are the main concerns.
Choose Data Lake Storage Gen2 whenUse Data Lake Storage Gen2 when analytics workloads need hierarchical namespace, directory semantics, and lake-oriented access patterns.
Blob Storage is object storage; Data Lake Storage Gen2 adds hierarchical namespace and analytics-friendly ACL semantics.
Decision details
Question: Do you need general object storage, or hierarchical namespace and analytics-oriented lake behavior?
Key differences
- Data Lake Storage Gen2 is built on storage accounts with hierarchical namespace enabled.
- Hierarchical namespace changes directory operations, ACL behavior, and analytics integration.
- The choice affects access control, tooling, migration, and analytics performance patterns.
Common mistake
Enabling or choosing lake behavior without checking how existing apps, permissions, and tools interact with hierarchical namespace.
Check before deciding
- Identify analytics engines, access methods, ACL needs, and migration expectations.
- Check storage account hierarchical namespace, private access, and identity model.
- Test representative read/write/list operations before migrating production data.
Security operationsGovernance reporting impact
Best match
Compliance Manager vs Secure Score
Choose Compliance Manager whenUse Compliance Manager when the scenario centers on regulatory assessments, control improvement actions, and compliance evidence.
Choose Secure Score whenUse Secure Score when the scenario centers on security posture recommendations and measurable risk-reduction score improvement.
Compliance Manager tracks regulatory control improvement actions; Secure Score summarizes security posture recommendations and risk-reduction progress.
Decision details
Question: Is the learner being asked for regulatory compliance improvement tracking, or security posture scoring?
Key differences
- Compliance Manager maps work to compliance assessments and controls.
- Secure Score prioritizes security recommendations and posture improvement.
- Compliance and security posture overlap but are not identical.
Common mistake
Using secure score as proof of regulatory compliance without mapping controls and evidence.
Check before deciding
- Separate regulatory requirement from security recommendation.
- Collect the evidence the auditor or security owner actually needs.
- Map the improvement action to owner, due date, and scope.
Identity & governanceIdentity access boundary impact
Best match
Conditional Access vs Azure RBAC
Choose Conditional Access whenUse Conditional Access when the decision depends on user, device, location, risk, app, sign-in conditions, MFA, or session controls.
Choose Azure RBAC whenUse Azure RBAC when the decision depends on which Azure resource actions an identity can perform at management-group, subscription, resource-group, or resource scope.
Conditional Access controls sign-in conditions and session requirements; Azure RBAC controls allowed actions at Azure scopes after the identity is authenticated.
Decision details
Question: Is the problem about how an identity signs in, or what the identity can do inside Azure after sign-in?
Key differences
- Conditional Access is evaluated during sign-in and session access.
- RBAC is evaluated when an authenticated identity calls Azure control-plane or data-plane operations.
- Strong access design usually needs both: sign-in controls plus least-privilege role assignments.
Common mistake
Trying to stop broad Owner rights with Conditional Access alone, or trying to require MFA for risky sign-ins with RBAC alone.
Check before deciding
- Confirm whether the failure is sign-in/session enforcement or Azure authorization.
- Review role assignments at the same scope as the affected resource.
- Review Conditional Access policy targeting before changing broad access controls.
App hostingRelease strategy impact
Best match
Container Apps revision vs App Service deployment slot
Choose Container Apps revision whenUse Container Apps revisions when releasing container app versions, traffic weights, and revision-scoped configuration.
Choose App Service deployment slot whenUse App Service deployment slots when releasing App Service apps through staging/production slots and swap behavior.
Container Apps revisions version container app runtime/configuration with traffic splitting; App Service deployment slots provide swappable app environments for App Service apps.
Decision details
Question: Is the app hosted on Container Apps with revision traffic, or App Service with slot swap semantics?
Key differences
- Revisions belong to Container Apps.
- Deployment slots belong to App Service and Function Apps on supported plans.
- Both can support safer rollout, but the mechanics and command evidence differ.
Common mistake
Applying slot-swap mental models to Container Apps revisions or expecting revisions in App Service.
Check before deciding
- Confirm the hosting platform first.
- List current revisions or slots before changing traffic.
- Test health probes and rollback path before production rollout.
ContainersCluster / workload impact
Best match
Container Apps vs AKS
Choose Container Apps whenUse Container Apps when you want revisions, ingress, scale rules, and managed container hosting without operating a Kubernetes cluster.
Choose AKS whenUse AKS when you need Kubernetes APIs, node pools, custom networking, cluster add-ons, or deep platform control.
Container Apps hides most orchestration and infrastructure; AKS gives Kubernetes-level control for platform teams that need it.
Decision details
Question: Do you need a managed container app platform, or full Kubernetes cluster control?
Key differences
- Container Apps abstracts much of the cluster and gives app-level revisions and scaling.
- AKS exposes the Kubernetes control surface and requires cluster, node, network, and upgrade ownership.
- The right choice depends on operational ownership as much as application architecture.
Common mistake
Choosing AKS for every container workload before confirming the team is ready to operate Kubernetes safely.
Check before deciding
- Identify required ingress, private networking, secrets, registry access, scale rules, and observability.
- Check whether the team needs Kubernetes-native APIs or just managed container deployment.
- Compare production change workflow: Container Apps revision rollout vs AKS manifests, ingress, and node upgrades.
ContainersCluster / workload impact
Best match
Container Apps vs Container Instances
Choose Container Apps whenUse Container Apps for long-running services, APIs, event-driven apps, revisions, traffic splitting, and managed scaling.
Choose Container Instances whenUse Container Instances for simple container groups, short-lived jobs, quick tests, or cases where app-platform features are unnecessary.
Container Apps is an application platform with revisions, ingress, Dapr, jobs, and scale rules; Container Instances is simpler container execution.
Decision details
Question: Is this a managed app with ingress, revisions, and scale rules, or a simple container run?
Key differences
- Container Apps provides app platform behavior such as revisions, ingress, environment, and scale rules.
- Container Instances is lower-level and simpler for direct container execution.
- Secrets, registry auth, networking, and logs are managed differently across the two services.
Common mistake
Building a production service on Container Instances and then recreating app-platform features manually.
Check before deciding
- Confirm whether the workload needs ingress, revision rollback, autoscaling, or service discovery.
- Check image pull, secrets, environment variables, and networking before choosing.
- For production services, document rollout and rollback behavior before deployment.
ArchitectureOperations boundary impact
Best match
Control Plane vs Data Plane
Choose Control Plane whenThink control plane when the action creates, configures, scales, secures, or deletes Azure resources.
Choose Data Plane whenThink data plane when the action reads, writes, processes, queries, or serves the data/application inside the resource.
The control plane manages resource configuration; the data plane accesses or operates service data.
Decision details
Question: Are you managing the Azure resource itself, or accessing the workload/data inside that resource?
Key differences
- Control-plane permissions usually flow through Azure Resource Manager and RBAC at scope.
- Data-plane permissions may use service-specific roles, keys, tokens, connection strings, or network rules.
- A user can have control-plane access without data-plane access, or the reverse, depending on service design.
Common mistake
Granting Contributor and assuming that automatically allows reading secrets, blobs, databases, or messages.
Check before deciding
- Identify whether the requested action is resource management or data access.
- Check both Azure RBAC and service-specific access controls before changing permissions.
- Collect the exact error message because authorization failures often reveal the missing plane.
AI + dataLanguage workload choice
Best match
Conversational Language Understanding vs custom text classification
Choose CLU whenUse CLU when the app needs intents, entities, utterances, and conversational routing.
Choose Custom text classification whenUse custom text classification when the app needs to label text or documents into categories without conversational intent routing.
CLU predicts conversational intents/entities; custom text classification assigns documents or text into categories.
Decision details
Question: Is the app interpreting user intent in conversation or classifying text/documents into categories?
Key differences
- CLU is dialog/intent oriented; classification is category-label oriented.
- CLU design depends on utterances, intents, and entities.
- Classification design depends on labeled examples and category boundaries.
Common mistake
Using a conversational intent model for every NLP problem even when the requirement is document classification.
Check before deciding
- Read the requirement for intents, entities, categories, and expected output.
- Choose sample data that mirrors real user utterances or documents.
- Check endpoint, deployment, and confidence thresholds before production.
IntegrationEvent processing impact
Best match
Cosmos DB change feed vs Event Grid
Choose Cosmos DB change feed whenUse Cosmos DB change feed when the workload reacts to item-level changes in a Cosmos DB container and needs ordered processing by logical partition.
Choose Event Grid whenUse Event Grid when the workload reacts to service events, filters events, and routes notifications to handlers.
Cosmos DB change feed reads ordered item changes from containers; Event Grid delivers event notifications from event sources to handlers.
Decision details
Question: Do you need to process ordered data changes from a Cosmos container, or route event notifications between services?
Key differences
- Change feed is tied to Cosmos DB container changes.
- Event Grid is a general event routing service.
- Change feed processors track leases and progress; Event Grid uses subscriptions, filters, retry, and dead-lettering.
Common mistake
Using Event Grid as if it exposes every document mutation stream with change-feed semantics.
Check before deciding
- Name the source of truth and event granularity.
- Check container partitioning and lease container design for change feed.
- Check Event Grid filters, retry, and dead-letter settings before production.
DataData modeling impact
Best match
Cosmos DB database vs container
Choose Cosmos DB database whenUse the Cosmos DB database as the logical grouping and, when configured, a shared throughput boundary for containers.
Choose container whenUse the container as the place where items live, partition keys are enforced, indexing is configured, and most query behavior is shaped.
A Cosmos DB database is a logical namespace; a container is the unit where items, partitioning, indexing, and throughput are usually applied.
Decision details
Question: Are you defining a namespace and throughput boundary, or the item collection with partitioning and indexing?
Key differences
- Databases organize containers and can hold shared throughput in some designs.
- Containers hold items and define partition key, indexing policy, TTL, and throughput if not shared.
- Most performance and cost problems show up at the container and partition-key level.
Common mistake
Treating the database as the main scale boundary and ignoring the container partition key that actually governs item distribution.
Check before deciding
- List databases, containers, throughput mode, and partition keys before schema changes.
- Check hot partitions, indexing policy, and RU consumption at the container level.
- Do not change partitioning strategy without a migration plan.
StorageData access impact
Best match
Cosmos DB logical vs physical partition
Choose Cosmos DB logical whenUse logical partition thinking when designing item distribution, partition key values, and query patterns.
Choose physical partition whenUse physical partition thinking when investigating throughput distribution, hot partitions, storage growth, and backend scaling behavior.
Logical partitions group items by partition key value; physical partitions are internal storage and throughput partitions managed by Cosmos DB.
Decision details
Question: Are you reasoning about your partition key value, or the backend partitions Azure uses to serve data?
Key differences
- Logical partitions are based on your partition key values.
- Physical partitions are Azure-managed infrastructure that host logical partitions.
- Hot logical partitions can create throttling even when total account throughput looks sufficient.
Common mistake
Looking only at total RU/s and missing that one logical partition key is carrying most of the traffic.
Check before deciding
- Inspect partition key design, high-volume keys, RU consumption, and throttling evidence.
- Review queries that do not include the partition key.
- Do not change partition key strategy without a data migration plan.
DataData platform impact
Best match
Cosmos DB manual vs autoscale throughput
Choose Cosmos DB manual whenUse manual throughput when workload demand is steady, understood, and managed against a fixed RU/s target.
Choose autoscale throughput whenUse autoscale throughput when traffic varies and you need the service to scale within a configured maximum.
Manual throughput fixes provisioned RU/s; autoscale adjusts RU/s within a configured range as workload demand changes. Also covers: Cosmos DB manual throughput vs autoscale; Manual vs Autoscale Throughput.
Decision details
Question: Is demand predictable enough for fixed RU/s, or variable enough to pay for autoscale headroom?
Key differences
- Manual throughput gives predictable capacity and cost when usage is stable.
- Autoscale can absorb bursts but requires careful max RU/s selection to avoid surprise spend.
- Both modes still depend on partition key quality and query efficiency.
Common mistake
Switching to autoscale to hide inefficient queries or hot partitions instead of fixing the access pattern.
Check before deciding
- Review RU consumption, throttling, hot partitions, and peak windows before switching modes.
- Set autoscale max based on measured demand, not guesswork.
- Capture before/after metrics after changing throughput mode.
DataScale / cost impact
Best match
Cosmos DB serverless vs Provisioned throughput
Choose Cosmos DB serverless whenUse serverless when usage is intermittent, smaller, or early-stage and you want consumption-based billing without managing RU/s.
Choose Provisioned throughput whenUse provisioned throughput when workloads need predictable RU/s, autoscale/manual controls, or production capacity planning.
Serverless charges for request units consumed; provisioned throughput reserves RU/s capacity at database or container scope.
Decision details
Question: Is the workload intermittent and unpredictable, or does it need predictable reserved throughput and scale controls?
Key differences
- Serverless removes RU/s planning but has different limits and cost behavior.
- Provisioned throughput requires partition and RU planning.
- Autoscale provisioned throughput is different from serverless billing.
Common mistake
Choosing serverless for a workload that needs predictable sustained throughput, then being surprised by limits or cost shape.
Check before deciding
- Estimate workload request patterns before choosing mode.
- Review partition key and hot partition risk.
- Use Cosmos runbooks before scaling or changing backup/failover settings.
MonitoringTelemetry routing impact
Best match
Data collection rule vs diagnostic settings
Choose Data collection rule whenUse a data collection rule when the scenario involves Azure Monitor Agent, data collection endpoints, transform logic, or VM/agent telemetry routing.
Choose Diagnostic settings whenUse diagnostic settings when the scenario involves sending a resource’s platform logs and metrics to Log Analytics, Storage, or Event Hubs.
Data collection rules shape Azure Monitor agent collection and routing; diagnostic settings send resource platform logs and metrics to destinations.
Decision details
Question: Are you collecting agent-based telemetry, or routing Azure resource platform logs and metrics?
Key differences
- DCRs are central to Azure Monitor Agent collection.
- Diagnostic settings are attached to Azure resources for platform telemetry export.
- Many environments need both, but they do not collect the same signals.
Common mistake
Expecting diagnostic settings to collect guest OS telemetry, or expecting a DCR to enable every resource platform log.
Check before deciding
- Name the telemetry source: guest/agent or platform resource.
- Check current diagnostic settings before enabling noisy logs.
- Check DCR associations before changing VM monitoring.
DataData platform impact
Best match
Data Factory vs Synapse Pipelines
Choose Data Factory whenUse Data Factory when the primary job is data movement, transformation orchestration, integration runtime, and pipeline scheduling across services.
Choose Synapse Pipelines whenUse Synapse Pipelines when orchestration is part of a Synapse workspace with SQL pools, Spark, and analytics development in the same environment.
Data Factory focuses on data integration; Synapse pipelines bring similar orchestration into an analytics workspace. Also covers: Data Factory Pipeline vs Synapse Pipeline.
Decision details
Question: Do you need standalone data integration orchestration, or orchestration inside a Synapse analytics workspace?
Key differences
- Data Factory is the standalone integration service and often fits cross-platform orchestration.
- Synapse Pipelines share workspace context with Synapse SQL, Spark, linked services, and workspace security.
- Integration runtime, private endpoints, triggers, and rerun behavior still need safe review in either service.
Common mistake
Choosing based on UI similarity and overlooking workspace governance, runtime networking, and who owns reruns after failures.
Check before deciding
- List pipelines, triggers, linked services, and integration runtimes before migration or rerun.
- Confirm whether the pipeline depends on Synapse workspace assets.
- Capture failed activity output before changing triggers or rerunning production pipelines.
DataData platform impact
Best match
Dedicated SQL Pool vs Serverless SQL Pool
Choose Dedicated SQL Pool whenUse a dedicated SQL pool when workloads need provisioned MPP warehouse capacity, predictable performance, and controlled loading/query patterns.
Choose Serverless SQL Pool whenUse a serverless SQL pool for exploratory or on-demand querying over files in the lake without provisioning a warehouse.
Dedicated SQL pools reserve data warehouse capacity; serverless SQL pools query lake data on demand.
Decision details
Question: Do you need provisioned warehouse capacity, or on-demand SQL over lake data?
Key differences
- Dedicated pools have allocated capacity and require pause/resume, scale, distribution, and workload management decisions.
- Serverless pools charge per query/data processed and depend heavily on file layout, format, and query efficiency.
- Dedicated is a data warehouse choice; serverless is often an exploration, external table, or lightweight query choice.
Common mistake
Running broad serverless queries over poorly partitioned data and being surprised by performance or scan cost.
Check before deciding
- Confirm workload pattern, concurrency, data size, and performance objective.
- Review pool state, SKU, pause/resume behavior, and query history before changes.
- Test representative queries against real file layout before committing.
Security operationsSecurity monitoring impact
Best match
Defender for Cloud vs Microsoft Sentinel
Choose Defender for Cloud whenUse Defender for Cloud when the scenario asks about secure score, regulatory compliance, recommendations, plans, or workload protection.
Choose Microsoft Sentinel whenUse Microsoft Sentinel when the scenario asks for SIEM, analytics rules, incidents, automation, hunting, or cross-source security operations.
Defender for Cloud manages cloud security posture and workload protection; Microsoft Sentinel is a SIEM/SOAR workspace for detection, investigation, and response.
Decision details
Question: Is the requirement posture/workload protection, or centralized security analytics and incident response?
Key differences
- Defender for Cloud is posture and protection oriented.
- Sentinel is detection, investigation, and response oriented.
- Many security designs send Defender alerts into Sentinel.
Common mistake
Calling Sentinel the posture-management tool, or expecting Defender for Cloud to replace SIEM workflows.
Check before deciding
- Check whether the ask is recommendation/compliance or incident detection.
- Review enabled Defender plans before expanding coverage.
- Inspect Sentinel analytics rules and incidents before changing response automation.
Identity & governanceIdentity permission impact
Best match
Delegated vs Application Permission
Choose Delegated whenUse delegated permissions when the app should operate in the context of a signed-in user and respect that user's access.
Choose Application Permission whenUse application permissions for daemon, service, or automation scenarios where the app acts as itself.
Delegated permission acts with a signed-in user; application permission lets an app act as itself without a user.
Decision details
Question: Should the app act as the signed-in user, or act on its own without a user present?
Key differences
- Delegated permission combines app consent with the user's identity and effective access.
- Application permission can operate without a user and often has broader tenant or resource impact.
- Admin consent, token claims, and audit evidence differ between the two models.
Common mistake
Granting application permission to solve a user-flow issue, creating an app-only identity with more access than intended.
Check before deciding
- Confirm whether a user is present and whether the app should inherit user restrictions.
- Review app registration API permissions and granted consent before changing scopes.
- Collect sign-in/audit logs after consent changes.
MonitoringEvidence and telemetry impact
Best match
Diagnostic setting vs Activity Log
Choose Diagnostic setting whenUse diagnostic settings to route supported resource logs and metrics to a destination such as Log Analytics, Event Hubs, or Storage.
Choose Activity Log whenUse Activity Log when the question is who changed Azure resources, when, and whether the control-plane operation succeeded.
Activity Log records subscription-level control-plane events; diagnostic settings route selected platform logs and metrics to destinations like Log Analytics, Storage, or Event Hubs.
Decision details
Question: Are you collecting resource telemetry, or investigating control-plane changes in Azure?
Key differences
- Diagnostic settings are configured per resource or scope to export telemetry categories.
- Activity Log records Azure control-plane operations at subscription scope.
- Diagnostic settings can increase ingestion cost; Activity Log may not contain data-plane details.
Common mistake
Looking for application or data-plane logs in Activity Log, or enabling every diagnostic category without cost review.
Check before deciding
- Identify whether the evidence needed is control-plane change, resource log, metric, or application telemetry.
- List current diagnostic settings and destinations before enabling more categories.
- Capture Activity Log around the incident window before changing resources.
MonitoringTelemetry collection
Best match
Diagnostic settings vs data collection rule
Choose Diagnostic settings whenUse diagnostic settings when the scenario is sending resource platform logs/metrics to Log Analytics, Event Hubs, or Storage.
Choose Data collection rule whenUse a data collection rule when the scenario is Azure Monitor Agent, VM/guest telemetry, collection transforms, or DCR associations.
Diagnostic settings route platform logs and metrics from resources; data collection rules define how monitoring agents and collection pipelines gather telemetry.
Decision details
Question: Are you routing Azure platform logs from a resource or configuring an agent/data collection pipeline?
Key differences
- Diagnostic settings are attached to Azure resources and categories.
- DCRs are agent/pipeline configuration objects with associations.
- Both can affect cost and data volume, so exam scenarios often include destination and collection scope clues.
Common mistake
Enabling all log categories everywhere without estimating ingestion cost or retention impact.
Check before deciding
- List supported diagnostic categories first.
- Check Log Analytics retention and table cost before turning on verbose logs.
- Verify DCR associations when troubleshooting missing VM telemetry.
AI + dataDocument extraction choice
Best match
Document Intelligence layout model vs prebuilt model
Choose Layout model whenUse layout when the task is extracting text, tables, selection marks, and structure across varied documents.
Choose Prebuilt model whenUse a prebuilt model when the document type matches a supported form, invoice, receipt, ID, or other known pattern.
Layout extracts structure from documents; prebuilt models target known document types and common fields.
Decision details
Question: Do you need generic document structure or fields from a known document type?
Key differences
- Layout is broader and structure-oriented; prebuilt models are targeted and field-oriented.
- Prebuilt models reduce custom training when the document type matches.
- Layout is often a step before deciding whether custom extraction is needed.
Common mistake
Training a custom model before testing whether layout or a prebuilt model already solves the extraction need.
Check before deciding
- Identify the document type and fields required.
- Try layout/prebuilt extraction with sample documents.
- Use custom extraction only when the generic or prebuilt path misses required fields.
DataDatabase purchasing impact
Best match
DTU vs vCore
Choose DTU whenUse DTU when a simple bundled performance model is enough and the workload is not asking for detailed hardware or license control.
Choose vCore whenUse vCore when you need clearer CPU/memory/storage sizing, hardware family choice, reserved capacity, or Azure Hybrid Benefit planning.
DTU is a bundled performance model; vCore separates compute, memory, and storage choices more explicitly.
Decision details
Question: Do you want a simplified blended sizing model, or more transparent compute, memory, and licensing control?
Key differences
- DTU bundles compute, storage, and IO into an abstract unit.
- vCore exposes compute and storage choices more directly and aligns better with SQL Server licensing conversations.
- Migration between models should be tested with workload metrics, not only pricing tables.
Common mistake
Changing purchasing model to reduce cost without checking CPU, IO, storage, and query wait evidence.
Check before deciding
- Review current database metrics, wait stats, storage, and service objective.
- Estimate cost with production workload peaks and licensing assumptions.
- Test the target tier before changing a production database.
IntegrationWorkflow orchestration impact
Best match
Durable Functions vs Logic Apps
Choose Durable Functions whenUse Durable Functions when orchestration is best expressed in application code with custom control flow, fan-out/fan-in, and function-level deployment.
Choose Logic Apps whenUse Logic Apps when the value is managed connectors, workflow designer, business process integration, and lower-code operational visibility.
Durable Functions is code-first serverless orchestration; Logic Apps is workflow-first integration with connectors and visual workflow management.
Decision details
Question: Does the scenario need code-first orchestration with custom logic, or connector-driven workflow integration?
Key differences
- Durable Functions lives in the Functions app development model.
- Logic Apps lives in the workflow and connector model.
- Integration teams often prefer Logic Apps; application teams may prefer code-first Durable Functions.
Common mistake
Choosing Functions for every serverless workflow even when managed connectors and business workflow operations are the core requirement.
Check before deciding
- Name the owner: app team or integration/process team.
- List connector, custom-code, state, and monitoring needs.
- Review workflow/function run history before changing orchestration.
IntegrationFailure-handling impact
Best match
Event Grid dead-letter destination vs Service Bus dead-letter queue
Choose Event Grid dead-letter destination whenUse Event Grid dead-lettering when event delivery to a handler fails after retry policy and the undelivered event needs storage for inspection.
Choose Service Bus dead-letter queue whenUse Service Bus DLQ when messages exceed delivery attempts, expire, fail processing, or are explicitly dead-lettered by consumers.
Event Grid dead-lettering stores undelivered events after delivery failures; Service Bus DLQ stores messages that cannot be delivered or processed according to queue/topic rules.
Decision details
Question: Are you handling failed event delivery from Event Grid, or failed message processing in a brokered queue/topic?
Key differences
- Event Grid dead-lettering is tied to event subscription delivery.
- Service Bus DLQ is tied to brokered messaging entities.
- The Targeted Study Plan differs: event subscription/retry/filter versus queue/topic processing behavior.
Common mistake
Looking for a Service Bus DLQ when the failure is Event Grid webhook delivery, or treating Event Grid as a brokered queue.
Check before deciding
- Identify the service that owns the failure path.
- Check retry, expiration, and dead-letter configuration.
- Review handler health and poison-message patterns before replay.
IntegrationMessaging / integration impact
Best match
Event Grid vs Event Hubs
Choose Event Grid whenUse Event Grid when producers emit discrete events that subscribers should react to through filtering and delivery semantics.
Choose Event Hubs whenUse Event Hubs when the workload ingests telemetry, logs, or ordered streams at high throughput for consumers to process.
Event Grid routes discrete events; Event Hubs ingests high-volume streams.
Decision details
Question: Are you routing discrete events to handlers, or ingesting a high-volume event stream?
Key differences
- Event Grid is event routing with subscriptions, filters, retry, and dead-letter behavior.
- Event Hubs is streaming ingestion with partitions, consumer groups, throughput, and capture options.
- Event Grid pushes events to handlers; Event Hubs is read by consumers from a stream.
Common mistake
Using Event Grid as a telemetry stream or Event Hubs as a simple notification router without checking delivery and consumer semantics.
Check before deciding
- Define event volume, ordering needs, subscriber count, retry behavior, and dead-letter requirements.
- Inspect existing subscriptions, filters, consumer groups, and throughput before changes.
- Test failure handling with a non-production event before changing production routing.
IntegrationMessaging / integration impact
Best match
Event Hubs vs Service Bus
Choose Event Hubs whenUse Event Hubs for high-throughput event ingestion where consumers read from partitions and handle stream processing.
Choose Service Bus whenUse Service Bus when messages need broker features such as queues/topics, locks, sessions, dead-lettering, and business process reliability.
Event Hubs is high-throughput streaming; Service Bus is enterprise brokered messaging for commands, workflows, and business transactions.
Decision details
Question: Is the workload a telemetry/event stream, or brokered business messaging?
Key differences
- Event Hubs optimizes stream ingestion and multiple consumer groups.
- Service Bus optimizes commands, work items, pub/sub messages, and delivery guarantees.
- Ordering, replay, lock duration, sessions, and dead-letter handling are key decision points.
Common mistake
Choosing Event Hubs for work queues that need per-message settlement, retries, sessions, or dead-letter operations.
Check before deciding
- Clarify whether consumers process streams or individual business messages.
- Check ordering, retry, dead-letter, replay, and throughput requirements.
- Inspect current lag, dead-letter count, and consumer behavior before migration.
IntegrationMessaging / integration impact
Best match
Event Hubs vs Service Bus vs Event Grid
Choose Event Hubs whenUse Event Hubs when the core need is high-volume stream ingestion and consumer-group processing.
Choose Service Bus / Event Grid whenUse Service Bus for durable business messaging or Event Grid for event notification and routing to handlers.
Event Hubs is for high-throughput event streams, Service Bus is for brokered enterprise messaging, and Event Grid is for reactive event routing.
Decision details
Question: Do you need stream ingestion, brokered messaging, or event routing?
Key differences
- Event Hubs is the stream; Service Bus is the broker; Event Grid is the event router.
- Consumer behavior differs: stream readers, message receivers, or event handlers.
- Retry, ordering, dead-letter, filtering, and replay expectations should decide the service.
Common mistake
Picking the service with the familiar name instead of writing down delivery semantics and failure behavior.
Check before deciding
- Classify the workload as telemetry stream, work queue, pub/sub message, or event notification.
- Document ordering, replay, dead-letter, retry, and fan-out needs.
- Run a small failure-mode test before changing integration routes.
NetworkingHybrid connectivity impact
Best match
ExpressRoute vs Site-to-site VPN
Choose ExpressRoute whenUse ExpressRoute when requirements call for private connectivity, predictable performance, provider integration, or enterprise hybrid network architecture.
Choose Site-to-site VPN whenUse site-to-site VPN when encrypted connectivity over the internet is acceptable, the environment is smaller, or VPN is needed as a backup path.
ExpressRoute provides private connectivity through a connectivity provider; site-to-site VPN uses encrypted tunnels over the public internet.
Decision details
Question: Do you need private provider-backed hybrid connectivity, or is encrypted internet VPN connectivity enough?
Key differences
- ExpressRoute is private provider connectivity, not encrypted internet tunneling by default.
- VPN is usually faster to start but may have lower predictability than private circuit connectivity.
- Many enterprise designs use both: ExpressRoute primary, VPN backup.
Common mistake
Treating ExpressRoute as automatically encrypted end-to-end or ignoring VPN backup and route failover behavior.
Check before deciding
- Document latency, bandwidth, encryption, and failover requirements.
- Check route propagation and gateway SKU choices before deployment.
- Use network discovery before changing hybrid routing.
AI + dataAgentic architecture
Best match
Foundry agent vs chat completion
Choose Foundry agent whenUse an agent when the scenario requires tools, actions, retrieval, multi-turn task state, or workflow-like behavior.
Choose Chat completion whenUse chat completion when the scenario is a direct prompt, system message, grounding payload, and model response without managed agent orchestration.
Agents coordinate tools, memory, orchestration, and multi-step tasks; chat completions produce model responses for direct prompt-and-response interactions.
Decision details
Question: Does the solution need tool-using, stateful task orchestration or a direct model response to a prompt?
Key differences
- Agents add orchestration concepts that must be secured and monitored beyond the model call.
- Chat completion remains simpler and easier to reason about for stateless prompt/response flows.
- Agent scenarios usually require more attention to tool permissions, data boundaries, and human approval points.
Common mistake
Using an agent for every generative AI scenario. On exams, the simpler model call is often enough when no tool orchestration is required.
Check before deciding
- List tools, data sources, and actions the agent can call.
- Separate model output risk from tool-execution risk.
- Check identity and approval boundaries before allowing an agent to change data or call APIs.
NetworkingEdge and regional protection impact
Best match
Front Door WAF vs Application Gateway WAF
Choose Front Door WAF whenUse Front Door WAF when traffic enters through global edge routing and needs edge-level policy before reaching origins.
Choose Application Gateway WAF whenUse Application Gateway WAF when traffic is regional, VNet-oriented, or protected at the application gateway layer.
Front Door WAF protects global edge traffic; Application Gateway WAF protects regional application gateway traffic inside a regional design.
Decision details
Question: Should web protection happen at the global edge or at a regional application gateway?
Key differences
- Front Door WAF applies at the global edge in front of Front Door routes.
- Application Gateway WAF applies regionally on Application Gateway listeners.
- Policy mode, exclusions, managed rules, custom rules, and origin/back-end exposure must be checked in context.
Common mistake
Applying WAF in one layer while the public origin or alternate route bypasses that WAF entirely.
Check before deciding
- Trace DNS and client path to confirm which WAF actually receives traffic.
- Review WAF mode, managed rule sets, exclusions, and custom rules before switching to prevention.
- Check origin exposure so users cannot bypass the protected entry point.
App hostingScale / cold-start impact
Best match
Functions Consumption vs Premium
Choose Functions Consumption whenUse Consumption when executions are bursty, short, event-driven, and cold start is acceptable.
Choose Premium whenUse Premium when the app needs pre-warmed instances, VNet integration, higher scale control, or workloads that do not fit basic Consumption behavior.
Consumption is pure serverless usage billing; Premium adds prewarmed capacity and advanced networking capabilities.
Decision details
Question: Can the function tolerate cold start and pay-per-execution scaling, or does it need warm capacity and stronger network/runtime control?
Key differences
- Consumption emphasizes automatic scale and pay-per-execution economics.
- Premium adds always-ready capacity, richer networking, and stronger runtime control at a baseline cost.
- Cold start, execution duration, trigger pressure, and dependency latency should drive the choice.
Common mistake
Optimizing for apparent idle cost while ignoring cold-start, VNet, and throughput requirements that force a later plan migration.
Check before deciding
- Check trigger volume, execution duration, memory use, and dependency latency.
- Inspect current plan, app settings, and scale behavior before changing hosting plan.
- Test cold-start and peak-load behavior with representative events.
App hostingImage deployment impact
Best match
Generalized vs specialized VM image
Choose Generalized whenUse a generalized image when you want reusable VM instances without carrying the source machine identity.
Choose specialized VM image whenUse a specialized image when you intentionally need to preserve OS state, machine identity, users, and installed configuration.
Generalized images remove machine identity for reusable provisioning; specialized images preserve state from the source VM.
Decision details
Question: Are you creating a reusable clean VM image, or preserving one machine exactly as-is?
Key differences
- Generalized images are prepared to create new machines from a clean identity state.
- Specialized images keep the source VM state and are closer to cloning that machine.
- The wrong image type can cause identity duplication, domain issues, or unusable provisioning expectations.
Common mistake
Capturing a specialized image when the team expected a reusable base image for scaled deployments.
Check before deciding
- Confirm whether the VM should be sysprepped/generalized before capture.
- Record extensions, disks, network assumptions, and identity dependencies.
- Test a new VM from the image before using it in production scale sets or deployments.
Identity & governanceAccess management impact
Best match
Group-based RBAC vs Direct user role assignment
Choose Group-based RBAC whenUse group-based RBAC when access should follow a team, job role, approval workflow, or lifecycle-managed membership.
Choose Direct user assignment whenUse direct user assignment only for exceptional, temporary, or highly specific cases where a group model is not appropriate.
Group-based RBAC assigns roles to an Entra group; direct assignment grants a role to an individual user at scope.
Decision details
Question: Should access be managed through membership and lifecycle processes, or assigned directly to one person?
Key differences
- Group-based access is easier to review and remove at scale.
- Direct assignments accumulate quickly and are harder to govern.
- Privileged groups still need owner, membership, and PIM review.
Common mistake
Cleaning up direct assignments without checking inherited scope or group membership, which can leave hidden access paths behind.
Check before deciding
- List role assignments at the target and parent scopes.
- Separate direct assignments from group-based assignments.
- Review owners, eligible assignments, and privileged roles before cleanup.
CostCost impact
Best match
Hot vs Cool vs Archive Blob Tiers
Choose Hot whenUse Hot for data that is actively read, updated, or needed quickly.
Choose Cool / Archive Blob Tiers whenUse Cool or Archive when data is rarely accessed and lower storage cost matters more than retrieval speed or transaction cost.
Access tiers trade read/write frequency, retrieval latency, and storage cost.
Decision details
Question: How often will the data be read, and how quickly must it be restored?
Key differences
- Hot usually favors frequent access with higher storage cost and lower access friction.
- Cool lowers storage cost for infrequent access but can increase access and early deletion considerations.
- Archive is for long-term retention and requires rehydration before normal reads.
Common mistake
Moving data to Archive to save money without checking restore-time expectations or downstream jobs that still read it.
Check before deciding
- Review access patterns, lifecycle rules, retention requirements, and restore-time objectives.
- Check current blob tier distribution and last modified/access evidence before lifecycle changes.
- Test rehydration or restore expectations with the data owner before applying broad policies.
App hostingDeployment impact
Best match
Incremental vs Complete Deployment Mode
Choose Incremental whenUse incremental mode for most deployments where resources not in the template should remain untouched.
Choose Complete Deployment Mode whenUse complete mode only when the template deliberately represents the entire target scope and deletion impact is approved.
Incremental mode updates declared resources without deleting omitted ones; complete mode can remove resources not declared at the target scope.
Decision details
Question: Should the deployment update only declared resources, or enforce that the template is the full desired state at that scope?
Key differences
- Incremental mode creates or updates resources in the template without deleting unrelated resources.
- Complete mode can remove resources at the deployment scope that are not represented in the template.
- Scope is everything: resource group, subscription, and nested deployments change the blast radius.
Common mistake
Running complete mode against a shared resource group and deleting resources that were never meant to be managed by that template.
Check before deciding
- Run what-if and inspect delete operations before any complete-mode deployment.
- Confirm the target scope and ownership of every resource that would be removed.
- Keep a rollback and recovery plan for deleted resources before applying complete mode.
AI + dataSearch indexing architecture
Best match
Integrated vectorization vs custom embedding pipeline
Choose Integrated vectorization whenUse integrated vectorization when the goal is simpler AI Search indexing with managed vectorization steps and less custom pipeline code.
Choose Custom embedding pipeline whenUse a custom embedding pipeline when you need exact preprocessing control, external data movement, custom scheduling, or nonstandard chunking/evaluation.
Integrated vectorization lets Azure AI Search handle chunking/vectorization flow; custom pipelines give teams deeper control over preprocessing, embeddings, and storage.
Decision details
Question: Should Azure AI Search own vectorization or should the application/data pipeline produce embeddings explicitly?
Key differences
- Integrated vectorization reduces custom code but still needs service identity, indexer, skillset, and data-source permissions.
- Custom pipelines can fit mature data engineering flows but create more moving parts to secure and monitor.
- Both patterns need evaluation for chunk quality, relevance, cost, and stale index behavior.
Common mistake
Choosing vectorization mechanics before defining retrieval quality, permissions, refresh cadence, and cost limits.
Check before deciding
- Check data source, index, vector fields, and skillset permissions.
- Measure retrieval quality with expected queries and citations.
- Review indexer failures and service scale before production.
Identity & governanceSecret / cryptography impact
Best match
Key Vault key vs Secret vs Certificate
Choose Key Vault key whenUse keys when the workload needs cryptographic operations such as encryption, signing, wrapping, or key rotation.
Choose Secret / Certificate whenUse secrets for sensitive values and certificates for certificate objects that need issuance, renewal, or binding workflows.
Key Vault keys are cryptographic keys, secrets are sensitive values, and certificates manage certificate material and lifecycle.
Decision details
Question: Are you storing a cryptographic key, an application secret, or certificate material that has lifecycle and renewal needs?
Key differences
- Keys, secrets, and certificates have different permissions and operations.
- Certificate objects often create backing keys/secrets that must be understood.
- Rotation and access review differ by object type.
Common mistake
Granting broad secret access when the workload only needs a certificate binding or key operation.
Check before deciding
- List vault access model and object permissions before changing access.
- Separate app runtime access from human operator access.
- Collect evidence before rotation or purge-protection changes.
Identity & governanceSecret access impact
Best match
Key Vault RBAC vs Access Policy
Choose Key Vault RBAC whenUse Key Vault RBAC when you want centralized role assignment, scope inheritance, and Azure RBAC governance for vault data operations.
Choose Key Vault access policy whenUse access policies when the vault or migration state still depends on the older vault-local permission model.
Key Vault RBAC uses Azure role assignments; access policies use the older vault-level policy model for data-plane permissions.
Decision details
Question: Should Key Vault data access be governed through Azure RBAC or vault-local access policies?
Key differences
- RBAC uses Azure role assignments and scope inheritance.
- Access policies are configured directly on the vault and can be easier to inspect locally but less aligned with central RBAC governance.
- Switching models can break secret, key, or certificate access if assignments are not prepared.
Common mistake
Changing the vault access model before proving every application identity has equivalent data-plane access.
Check before deciding
- List current vault access model, access policies, and role assignments before changes.
- Map each application identity to required secret/key/certificate operations.
- Test read-only secret access with the target identity before switching models.
NetworkingTraffic routing impact
Best match
Load Balancer vs Application Gateway
Choose Load Balancer whenUse Load Balancer for TCP/UDP load distribution, inbound NAT, and network-level balancing without HTTP routing logic.
Choose Application Gateway whenUse Application Gateway for HTTP/S routing, TLS termination, path/host rules, cookies, probes, and WAF options.
Load Balancer operates at transport layers; Application Gateway handles HTTP routing, listeners, backend settings, and WAF integration.
Decision details
Question: Do you need Layer 4 load distribution, or HTTP-aware Layer 7 routing?
Key differences
- Load Balancer works at Layer 4 and does not understand HTTP paths or headers.
- Application Gateway works at Layer 7 and can route based on HTTP properties.
- Health probes, backend pools, SNAT/outbound behavior, and TLS ownership differ.
Common mistake
Using Load Balancer for an HTTP app that needs host/path routing or WAF, then trying to recreate Layer 7 behavior elsewhere.
Check before deciding
- Identify protocol, TLS termination point, routing rules, and health probe requirements.
- Inspect current backend health and probe configuration before changing traffic flow.
- Check whether outbound/SNAT behavior is part of the design.
MonitoringObservability model impact
Best match
Log Analytics workspace vs Application Insights
Choose Log Analytics workspace whenUse Log Analytics workspace as the query and retention home for operational logs across resources and services.
Choose Application Insights whenUse Application Insights when the focus is application telemetry such as requests, dependencies, exceptions, availability, and traces.
Log Analytics workspace is the central query and retention store for logs; Application Insights focuses on application performance, failures, dependencies, availability, and user behavior telemetry.
Decision details
Question: Are you centralizing operational logs, or instrumenting application behavior and user-facing performance?
Key differences
- Log Analytics is the broader workspace and KQL query surface for operational data.
- Application Insights adds application performance monitoring concepts and SDK/agent telemetry.
- Many App Insights resources are workspace-based, so workspace retention and cost still matter.
Common mistake
Treating Application Insights as just another log bucket and missing sampling, dependency tracking, availability tests, and app-level signals.
Check before deciding
- Map which apps and resources send data to which workspace.
- Check ingestion, retention, sampling, and table cost before expanding telemetry.
- Use App Insights for application symptoms and workspace queries for cross-resource evidence.
IntegrationMessaging / integration impact
Best match
Logic Apps Standard vs Consumption
Choose Logic Apps Standard whenUse Logic Apps Standard when workflows need stronger runtime isolation, local project structure, VNet options, or multiple workflows in one app.
Choose Consumption whenUse Logic Apps Consumption for simpler serverless workflows where per-action billing and multi-tenant managed runtime fit.
Standard runs workflows in a single-tenant model; Consumption runs workflows in a multi-tenant serverless model.
Decision details
Question: Do workflows need single-tenant runtime control, or simple multi-tenant pay-per-action execution?
Key differences
- Standard runs on a single-tenant app model with hosting and networking choices.
- Consumption is simpler to start and bills per action/trigger execution.
- Connector availability, networking, deployment model, and cost behavior should be checked before migration.
Common mistake
Migrating to Standard for control without planning hosting cost, deployment workflow, or connector differences.
Check before deciding
- List triggers, actions, connectors, integration accounts, and network dependencies.
- Compare execution volume and hosting cost before switching plan type.
- Test workflow runs and connector authentication in a non-production environment.
StorageData access impact
Best match
LRS vs ZRS vs GRS
Choose LRS whenUse LRS when local durability is enough and the workload does not require zone or regional redundancy.
Choose ZRS or GRS whenUse ZRS or GRS when availability-zone resilience or cross-region disaster recovery is part of the requirement.
LRS keeps replicas within one physical location, ZRS spreads data across zones, and GRS copies data to a paired secondary region.
Decision details
Question: Do you need local, zone-level, or regional redundancy for the data and recovery objective?
Key differences
- LRS keeps replicas in one region location model; ZRS spreads across availability zones where supported.
- GRS adds cross-region replication for regional disaster recovery scenarios.
- Redundancy choice affects cost, failover behavior, read access options, and compliance expectations.
Common mistake
Choosing the cheapest redundancy tier without confirming recovery-time and recovery-point expectations with the data owner.
Check before deciding
- Confirm RTO/RPO, region requirements, read-access needs, and compliance constraints.
- Check current account redundancy and failover readiness before changing production storage.
- Review backup, soft delete, versioning, and restore evidence separately from redundancy.
Identity & governanceAccess / credential impact
Best match
Managed Identity vs Service Principal
Choose Managed Identity whenUse managed identity for Azure-hosted workloads that can authenticate without storing client secrets or certificates.
Choose Service Principal whenUse a service principal when the identity must exist outside a single Azure resource lifecycle, cross environments, or integrate with systems that need app credentials.
Managed identity is lifecycle-managed by Azure for a resource; a service principal is an application identity that often requires explicit credential and permission management.
Decision details
Question: Can Azure manage the identity lifecycle for the workload, or do you need a standalone app identity with credentials?
Key differences
- Managed identity removes credential storage and is tied to Azure resource or user-assigned identity lifecycle.
- Service principals require explicit credential/certificate rotation and ownership tracking.
- Both still need least-privilege role assignments at the correct scope.
Common mistake
Creating service principals with long-lived secrets for Azure workloads that could use managed identity instead.
Check before deciding
- List existing identities, credentials, owners, and role assignments before changing authentication.
- Prefer managed identity when the workload platform supports it and scope is clear.
- If service principal remains required, document rotation owner and expiry monitoring.
Identity & governanceGovernance scope impact
Best match
Management group vs Subscription
Choose Management group whenUse management groups to apply governance, policy, and RBAC structure across multiple subscriptions.
Choose Subscription whenUse subscriptions as the billing, quota, access, and resource-management boundary for workloads or environments.
Management groups organize and govern subscriptions; subscriptions are billing, quota, and resource-management containers.
Decision details
Question: Is the decision about organizing governance across subscriptions, or operating resources inside one subscription boundary?
Key differences
- Management groups are hierarchy and governance containers, not resource deployment locations.
- Subscriptions contain resource groups and resources and carry billing/quota/provider registration concerns.
- Inheritance from management groups can surprise teams working only at subscription level.
Common mistake
Troubleshooting a policy or role assignment only inside the subscription while the effective assignment is inherited from a management group.
Check before deciding
- Map the management group hierarchy and subscription placement before changing governance.
- Check inherited policy and role assignments before creating local exceptions.
- Record the exact scope string for every assignment or exemption.
MonitoringAlerting impact
Best match
Metric alert vs Log alert
Choose Metric alert whenUse a metric alert for fast threshold alerts on platform metrics with predictable dimensions.
Choose Log alert whenUse a log alert when the condition requires KQL, joins, text matching, custom tables, or correlated evidence.
Metric alerts evaluate Azure platform metrics; log alerts run queries over Log Analytics data and can express richer conditions at higher query and ingestion complexity.
Decision details
Question: Can a metric threshold detect the condition, or does the alert require a KQL query?
Key differences
- Metric alerts are usually simpler, faster, and less dependent on log ingestion delays.
- Log alerts are more flexible but depend on table schema, ingestion latency, query quality, and cost.
- Alert noise is a design problem: severity, frequency, window, dimensions, and action groups all matter.
Common mistake
Writing a log alert for a simple metric condition, then debugging ingestion delay and noisy KQL instead of using the metric directly.
Check before deciding
- Check whether the needed signal exists as a metric with useful dimensions.
- If using logs, test the KQL over the incident window before creating the rule.
- Review action groups, frequency, severity, and suppression strategy before enabling.
Security operationsIncident correlation impact
Best match
Microsoft Defender XDR vs Microsoft Sentinel
Choose Defender XDR whenUse Defender XDR when the scenario stays inside Microsoft Defender incident correlation and workload-specific protection portals.
Choose Microsoft Sentinel whenUse Sentinel when the scenario requires custom analytics, workbooks, hunting, automation, retention, and data connectors across many systems.
Defender XDR correlates incidents across Microsoft Defender workloads; Sentinel is a cloud-native SIEM/SOAR for Microsoft and non-Microsoft sources.
Decision details
Question: Is the problem unified Microsoft Defender incident correlation, or broader SIEM/SOAR across many data sources?
Key differences
- Defender XDR is product-family incident correlation.
- Sentinel is SIEM/SOAR with workspace data, connectors, analytics, and automation.
- The correct choice often depends on whether non-Microsoft logs and custom detection are required.
Common mistake
Choosing Sentinel for every security scenario even when the clue is Defender product-family incident correlation only.
Check before deciding
- Name the log sources and incident workflow first.
- Check whether custom analytics or non-Microsoft connectors are required.
- Keep response automation in a tested scope before production.
AI + dataModel lifecycle
Best match
Model catalog vs model deployment
Choose Model catalog whenUse the model catalog when the task is discovering, comparing, or selecting foundation models and capabilities.
Choose Model deployment whenUse a model deployment when the task is runtime access, quota, capacity, monitoring, endpoint names, or application integration.
A model catalog helps users discover/select models; a deployment is the configured runtime endpoint/capacity that applications call.
Decision details
Question: Is the scenario about choosing a model or running an application against a configured model endpoint?
Key differences
- Catalog selection is design-time; deployments are runtime resources with cost, quotas, and access patterns.
- Applications usually need deployment names/endpoints rather than catalog entries.
- Operational questions focus on metrics, throttling, capacity, and deployment health.
Common mistake
Assuming selecting a model in a catalog means the application is ready to call it in production.
Check before deciding
- Identify model, deployment name, region, quota, and endpoint.
- Check tokens, throttling, metrics, and content safety before release.
- Keep official model availability and pricing checks outside the static exam notes.
Identity & governanceAuthentication policy impact
Best match
Multifactor authentication vs Conditional Access
Choose MFA whenUse MFA when the learner or operator must name the second verification factor that raises sign-in assurance.
Choose Conditional Access whenUse Conditional Access when the requirement depends on conditions such as user group, location, device state, risk, app, or session behavior.
MFA is an authentication requirement; Conditional Access is the policy engine that decides when MFA or other controls are required.
Decision details
Question: Do you need the extra authentication factor itself, or the policy logic that decides when controls apply?
Key differences
- MFA is one control that can be required.
- Conditional Access combines signals and decisions, and can require MFA, compliant device, block access, or session restrictions.
- Exam scenarios often hide the answer in words like location, device, risk, and app targeting.
Common mistake
Choosing MFA whenever sign-in is mentioned, even when the scenario asks for conditional targeting and policy logic.
Check before deciding
- Identify the condition that must be evaluated.
- Check who is targeted and excluded before changing policy.
- Validate policy in report-only or non-production scope before broad enforcement.
NetworkingOutbound connectivity impact
Best match
NAT Gateway vs Load Balancer outbound rules
Choose NAT Gateway whenUse NAT Gateway when a subnet needs predictable outbound internet SNAT with dedicated public IPs or prefixes.
Choose Load Balancer outbound rules whenUse Load Balancer outbound rules when outbound behavior is intentionally tied to a Standard Load Balancer backend pool design.
NAT Gateway provides managed outbound SNAT for subnets; Load Balancer outbound rules can provide outbound connectivity tied to a load balancer frontend.
Decision details
Question: Should outbound SNAT be handled at the subnet level, or through load-balancer-tied outbound rules?
Key differences
- NAT Gateway attaches to subnets and becomes the preferred outbound path for resources in those subnets.
- Load Balancer outbound rules depend on backend pool membership and load balancer configuration.
- SNAT exhaustion, public IP ownership, routes, and subnet association drive troubleshooting.
Common mistake
Adding NAT Gateway without checking existing load balancer outbound rules, public IP dependencies, and route tables.
Check before deciding
- List subnet NAT Gateway associations, load balancer outbound rules, public IPs, and route tables.
- Check SNAT metrics or connection failure evidence before changing egress.
- Test outbound path from a representative VM or workload after the change.
AI + dataModel serving impact
Best match
Online endpoint vs Batch endpoint
Choose Online endpoint whenUse an online endpoint for real-time scoring where callers expect a request/response API and latency matters.
Choose Batch endpoint whenUse a batch endpoint when jobs can run asynchronously over files, datasets, or large input sets and callers can wait for output.
Online endpoints serve real-time inference; batch endpoints process asynchronous inference jobs over larger inputs. Also covers: ML online endpoint vs batch endpoint; Online Endpoint vs Batch Endpoint.
Decision details
Question: Does inference need to respond now, or can it run asynchronously over a batch of inputs?
Key differences
- Online endpoints need traffic routing, authentication, scale, and live availability planning.
- Batch endpoints need job scheduling, input/output storage, retry behavior, and throughput planning.
- Online cost is tied to serving capacity; batch cost is tied to job execution and data movement.
Common mistake
Using an online endpoint for large offline jobs, then fighting timeout, cost, and scaling issues that batch inference is designed to absorb.
Check before deciding
- Confirm latency, throughput, authentication, and failure-retry expectations with the consuming app owner.
- Inspect existing endpoint deployments and traffic before changing production inference routes.
- Run a representative test payload and record latency, error rate, and cost before committing.
Identity & governancePrivilege impact
Best match
Owner vs Contributor vs Reader role
Choose Owner whenUse Owner only when the identity must manage role assignments or fully administer the scope.
Choose Contributor / Reader whenUse Contributor or Reader when the identity should modify resources without granting access, or only inspect state.
Owner can manage access and resources; Contributor can manage resources but not access; Reader can view resources without making changes.
Decision details
Question: Does the identity need to manage access, change resources, or only view configuration?
Key differences
- Owner can manage access; Contributor can change resources but not grant access; Reader can view configuration.
- Broad Owner at subscription or management-group scope is high-risk.
- Least privilege often means custom roles or narrower scope, not just choosing among the three common roles.
Common mistake
Granting Owner because a deployment failed, when the real missing permission is narrower and temporary.
Check before deciding
- List existing assignments, inherited scope, and recent role changes before granting anything.
- Choose the narrowest scope and role that satisfies the task.
- Set review or removal evidence for temporary elevated access.
Identity & governancePrivilege lifetime impact
Best match
PIM eligible assignment vs permanent role assignment
Choose PIM eligible assignment whenUse PIM eligible assignment when privileged access should require activation, justification, approval, MFA, or time limit.
Choose Permanent role assignment whenUse a permanent assignment only when standing access is required and accepted by governance policy.
PIM eligible assignment makes privilege just-in-time and auditable; permanent assignment keeps privilege active until removed.
Decision details
Question: Should the identity hold standing access, or activate privileged access only when needed?
Key differences
- Eligible assignments reduce standing privilege.
- Permanent assignments are always available to the identity.
- PIM adds activation evidence and governance around sensitive roles.
Common mistake
Granting permanent Owner or User Access Administrator because a deployment failed once.
Check before deciding
- List existing role assignments and inherited scopes.
- Confirm whether the task needs access all the time or only during a change window.
- Use a narrow scope and review interval for privileged access.
Identity & governanceGovernance / compliance impact
Best match
Policy definition vs Policy initiative
Choose Policy definition whenUse a policy definition for one specific rule, effect, and parameterized evaluation.
Choose Policy initiative whenUse a policy initiative when multiple related definitions should be assigned, tracked, and reported together.
A policy definition describes one rule; a policy initiative groups multiple policy definitions into a larger compliance objective.
Decision details
Question: Are you enforcing one governance rule, or grouping several rules into a compliance baseline?
Key differences
- Definitions are individual rules; initiatives are grouped rule sets.
- Initiatives simplify assignment and compliance reporting for baselines.
- Parameters can exist at both definition and initiative assignment layers.
Common mistake
Assigning many separate policy definitions when an initiative would make compliance state and exceptions easier to manage.
Check before deciding
- Review existing initiatives before creating a new standalone rule.
- Check assignment scope, parameters, exemptions, and enforcement mode.
- Use policy compliance runbooks before remediating resources.
Exam readinessStudy method choice
Best match
Practice assessment vs scenario lab
Choose Practice assessment whenUse practice assessments to find weak objective areas and get used to exam wording.
Choose Scenario lab whenUse scenario labs when you need hands-on context for why a service, command, or configuration choice is correct.
A practice assessment checks exam-style recall and reasoning; a scenario lab teaches how Azure decisions behave in a real portal/CLI context.
Decision details
Question: Are you trying to measure readiness or build the experience needed to reason through scenario questions?
Key differences
- Practice questions expose gaps; labs create durable mental models.
- Labs should be read-only first and low-cost where possible.
- The strongest study loop is Learn objective → Compare decision → command/resource discovery → runbook/lab → practice question.
Common mistake
Only memorizing answers without building the operational context behind scenario questions.
Check before deciding
- Use Microsoft Learn as the official objective source.
- Map every missed question to a concept, Compare card, and lab action.
- Use Resource Graph and read-only CLI commands before running any cost-impacting lab.
AI + dataDocument AI model impact
Best match
Prebuilt vs Custom Document Intelligence model
Choose Prebuilt whenUse a prebuilt Document Intelligence model for common document types where the built-in fields match what you need.
Choose Custom Document Intelligence model whenUse a custom model when layouts, field names, language, or business rules are specific to your organization.
Prebuilt models cover common document types; custom models are trained on examples for organization-specific document extraction.
Decision details
Question: Can a prebuilt extraction model handle the document type, or do your forms require training on your own examples?
Key differences
- Prebuilt models reduce training effort but limit field control.
- Custom models require labeled examples and validation but can fit your document shape.
- Custom accuracy depends on representative samples, versioning, and ongoing review after document templates change.
Common mistake
Training a custom model before proving that a prebuilt model fails on real samples, or trusting a prebuilt model without testing edge cases.
Check before deciding
- Run a sample set through the prebuilt model and record fields, confidence scores, and misses.
- If custom is needed, separate training, validation, and holdout samples before production use.
- Check data privacy, region, and cost before sending production documents through any model.
NetworkingName resolution impact
Best match
Private DNS zone vs Public DNS zone
Choose Private DNS zone whenUse Private DNS zones for private endpoints, internal service names, and VNet-linked name resolution that should not be public.
Choose Public DNS zone whenUse public DNS zones when internet clients must resolve the name through public DNS.
Private DNS zones resolve names inside linked virtual networks; public DNS zones publish names for public resolution on the internet.
Decision details
Question: Should this name resolve only inside Azure/private networks, or should it be publicly resolvable?
Key differences
- Private DNS depends on VNet links and private records.
- Public DNS is externally resolvable and must be managed with public exposure in mind.
- Private endpoint failures are often DNS failures, not endpoint failures.
Common mistake
Creating a private endpoint but leaving clients resolving the old public name or missing the required private DNS zone link.
Check before deciding
- Check which resolver path clients use.
- List private DNS zone links and records before cutover.
- Validate CNAME/A records from the network where the app actually runs.
AI + dataAI security boundary
Best match
Private endpoint vs managed identity for AI security
Choose Private endpoint whenUse private endpoints when the requirement is to remove public network exposure and route service access over private network paths.
Choose Managed identity whenUse managed identity when the requirement is to avoid secrets and grant scoped identity-based access.
Private endpoints restrict network path; managed identity controls who or what can authenticate and authorize requests.
Decision details
Question: Is the scenario about network reachability or identity-based authorization?
Key differences
- Private endpoint answers “where can traffic come from?”
- Managed identity answers “who is allowed to call or manage this?”
- Strong designs often need both, plus DNS, diagnostics, and least-privilege roles.
Common mistake
Adding a private endpoint and assuming identity/role assignments are no longer needed.
Check before deciding
- Separate network controls from identity controls in the scenario.
- Validate private DNS resolution before disabling public access.
- Review role assignments and keys before release.
NetworkingReachability impact
Best match
Private Endpoint vs Service Endpoint
Choose Private Endpoint whenUse Private Endpoint when the service should be reached through a private IP in your VNet and public exposure should be minimized.
Choose Service Endpoint whenUse Service Endpoint when the service can remain on its public endpoint but access should be restricted to selected virtual networks/subnets.
Private Endpoint gives a private IP for a specific resource; Service Endpoint extends VNet identity to a public service endpoint without creating a private IP.
Decision details
Question: Do you need a private IP connection to a specific resource, or VNet-restricted access to a service endpoint?
Key differences
- Private Endpoint creates a network interface with a private IP for a specific resource.
- Service Endpoint extends subnet identity to supported PaaS services while the service endpoint remains public-facing.
- Private DNS, approval state, network policies, and public network access settings are common failure points.
Common mistake
Creating a private endpoint and forgetting private DNS, causing clients to keep resolving the public endpoint.
Check before deciding
- Check public network access, private endpoint connection state, DNS zone links, and client resolution before changes.
- Map which subnet and workload must reach the service.
- Test name resolution and connection from the consuming network before disabling public access.
AI + dataAI workflow design
Best match
Prompt flow vs code-first orchestration
Choose Prompt flow whenUse prompt flow when the focus is prompt-chain design, evaluation, traceability, and fast iteration with AI workflow assets.
Choose Code-first orchestration whenUse code-first orchestration when the app must own branching, retries, authorization, deployment, telemetry, and integration behavior directly.
Prompt flow helps design, evaluate, and iterate AI workflows; code-first orchestration gives app teams full control over runtime behavior, deployment, and integration logic.
Decision details
Question: Do you need a managed AI workflow/evaluation surface or application code that owns the orchestration path?
Key differences
- Prompt flow helps with experimentation and evaluation; code owns production-grade control and app-specific lifecycle.
- Code-first paths may integrate better with existing CI/CD and testing standards.
- Prompt flow can clarify model and prompt behavior before teams harden the production implementation.
Common mistake
Treating prompt flow as a complete production architecture without checking identity, observability, deployment, and rollback requirements.
Check before deciding
- Map the flow steps to the app runtime path.
- Check how secrets, identities, and telemetry are handled.
- Use a deployment runbook before promoting prompt or code changes.
Security operationsCompliance control impact
Best match
Purview retention policy vs DLP policy
Choose Retention policy whenUse retention when the scenario asks how long data must be kept, deleted, or preserved for records requirements.
Choose DLP policy whenUse DLP when the scenario asks to detect, block, warn, or audit sharing of sensitive information.
Retention controls how long content is kept or deleted; DLP policies help detect and prevent sensitive data loss or inappropriate sharing.
Decision details
Question: Is the requirement about lifecycle retention/deletion, or preventing sensitive information from leaving approved boundaries?
Key differences
- Retention is lifecycle and records oriented.
- DLP is leakage prevention and sensitive information handling oriented.
- Both are compliance controls, but they answer different risk questions.
Common mistake
Treating all compliance wording as retention, even when the scenario is about sensitive-data exfiltration or sharing.
Check before deciding
- Identify the compliance verb: keep, delete, preserve, block, warn, or audit.
- Confirm target locations and sensitive information types.
- Test policy impact before broad enforcement.
AI + dataGenerative AI grounding
Best match
RAG with vector search vs fine-tuning
Choose RAG with vector search whenUse RAG when answers must cite or use fresh, permissioned, domain content without retraining a model.
Choose Fine-tuning whenUse fine-tuning when the model needs to adapt behavior, format, or task patterns that prompts and retrieval cannot solve.
RAG grounds model responses with retrieved content; fine-tuning changes model behavior for patterns, style, or task adaptation.
Decision details
Question: Is the problem missing knowledge/evidence or does the model need different learned behavior?
Key differences
- RAG keeps knowledge in data sources and indexes; fine-tuning changes the model artifact or deployment behavior.
- RAG needs retrieval quality, chunking, indexing, and access control.
- Fine-tuning needs training data quality, evaluation, cost, deployment governance, and rollback planning.
Common mistake
Fine-tuning a model just because the model does not know private company documents. That is usually a retrieval/grounding problem first.
Check before deciding
- Identify whether the exam scenario asks for current facts, citations, or private data.
- Test retrieval precision and permission filtering before changing model behavior.
- Compare token, index, and training costs before production.
Backup & resilienceRestore / data-loss impact
Best match
Recovery point vs Snapshot
Choose Recovery point whenUse recovery points when restore needs to follow backup policy, retention, vault protection, and workload-aware recovery workflows.
Choose Snapshot whenUse snapshots for storage or disk point-in-time copy scenarios where lifecycle, consistency, and retention are managed separately.
A recovery point is managed by backup/recovery tooling; a snapshot is a point-in-time copy of a disk, blob, or file share object.
Decision details
Question: Are you using managed backup restore history, or a direct point-in-time copy of a storage/disk object?
Key differences
- Recovery points are tied to backup policy and vault behavior.
- Snapshots may not provide the same application consistency or retention governance.
- Both can create cost and data-exposure concerns if left unmanaged.
Common mistake
Assuming a snapshot is a full backup strategy without checking retention, consistency, restore process, or ownership.
Check before deciding
- Check protected items, backup policy, and recent job status.
- List snapshots and confirm age, owner, and delete safety.
- Test restore path before relying on it for exam scenarios or production.
Identity & governanceScope / lifecycle impact
Best match
Resource group vs Resource
Choose Resource group whenUse a resource group as the management, deployment, tagging, RBAC, and lifecycle container for related resources.
Choose Resource whenUse resource-level operations when the change should affect only one Azure resource and not the whole group.
A resource group is a management container; a resource is the individual service instance being managed.
Decision details
Question: Are you managing a lifecycle boundary for related assets, or one specific Azure object?
Key differences
- Resource-group actions can affect every contained resource.
- Resource-level actions are narrower but may still affect dependencies.
- RBAC, locks, policy, tags, and deployment history can exist at both levels.
Common mistake
Deleting or locking at resource-group level when the request was really about one resource.
Check before deciding
- Inventory all resources in the group before any group-level change.
- Check locks, policy, role assignments, and dependencies at both group and resource scope.
- Use resource-level action when blast radius should be narrow.
GovernanceGovernance control choice
Best match
Resource lock vs Azure Policy deny
Choose Resource lock whenUse a resource lock when the goal is to protect a critical resource or scope from accidental delete/write actions.
Choose Policy deny whenUse Policy deny when the goal is to enforce configuration rules before resources are created or updated.
Resource locks block delete or write actions at a scope; Policy deny prevents noncompliant resource create/update requests based on rules.
Decision details
Question: Should the control protect existing resources from accidental changes or prevent noncompliant configurations from being created?
Key differences
- Locks are blunt protection on a resource/scope; policy deny is rule-based governance.
- Locks can surprise operators during legitimate maintenance.
- Policy deny needs assignment scope, parameters, exemptions, and compliance review.
Common mistake
Using locks as a substitute for governance policy or using deny policy without testing exemptions and deployment impact.
Check before deciding
- Identify whether the risk is accidental change or noncompliant configuration.
- Review lock inheritance and policy assignments before remediation.
- Test policy in audit mode when possible before deny.
NetworkingTraffic flow / security impact
Best match
Route table vs Network Security Group
Choose Route table whenUse route table analysis when traffic is taking the wrong next hop, missing a firewall, or bypassing expected routing.
Choose Network Security Group whenUse NSG analysis when traffic reaches the right path but is allowed or blocked by security rules.
Route tables influence where packets go; Network Security Groups decide whether allowed traffic can pass.
Decision details
Question: Are you troubleshooting path selection, or traffic allow/deny rules?
Key differences
- Routing and filtering are separate layers.
- Effective routes and effective NSG rules should both be checked for VM traffic.
- A firewall path can fail because of either routing or rules.
Common mistake
Changing NSG rules when the real problem is a route table or next-hop issue.
Check before deciding
- Check effective routes and effective NSG rules from the NIC/subnet perspective.
- Verify route association and NSG association at subnet/NIC scope.
- Use Network Watcher before changing production networking.
AI + dataSearch enrichment impact
Best match
Search indexer vs Skillset
Choose Search indexer whenUse an indexer when the job is connecting to a supported data source, detecting changes, and loading documents into an index.
Choose Skillset whenUse a skillset when content needs enrichment such as extraction, chunking, OCR, or AI transformation before it lands in the index.
An indexer reads and loads data; a skillset enriches content during indexing before it lands in the search index.
Decision details
Question: Are you moving data into a search index, enriching it during indexing, or both?
Key differences
- An indexer controls data source reads, schedules, field mappings, and indexing runs.
- A skillset controls enrichment steps that transform or add fields during indexing.
- A failed indexer run may be caused by data access, mapping, or skill execution, so inspect both when troubleshooting.
Common mistake
Adding a skillset to fix a data-loading problem. If the indexer cannot reach or map the source, enrichment will not solve it.
Check before deciding
- List the data source, index, indexer, and skillset before editing any one of them.
- Run or inspect indexer status in a non-production window if reindexing can change visible search results.
- Capture failing field names, skill errors, and document counts before changing mappings.
IntegrationMessaging / integration impact
Best match
Service Bus Queue vs Topic
Choose Service Bus Queue whenUse a Service Bus queue for point-to-point work where one receiver should process each message.
Choose Topic whenUse a Service Bus topic when publishers should send once and multiple subscriptions receive filtered copies.
A queue has point-to-point consumers; a topic publishes messages to subscriptions with filters.
Decision details
Question: Should each message go to one consumer path, or be published to multiple subscriptions?
Key differences
- Queues model competing consumers for one work stream.
- Topics add subscriptions and filters for pub/sub fan-out.
- Dead-letter handling, sessions, duplicate detection, and lock duration still matter in both.
Common mistake
Building fan-out by adding multiple consumers to one queue, then discovering only one consumer gets each message.
Check before deciding
- Confirm whether the business event has one owner or multiple independent subscribers.
- Inspect subscription filters and dead-letter counts before routing changes.
- Test with duplicate, failed, and delayed messages before production rollout.
Identity + securityCredential strategy
Best match
Service principal secret vs federated credential
Choose Service principal secret whenUse a service principal secret only when federation is unavailable and rotation, storage, and access controls are strong.
Choose Federated credential whenUse a federated credential when CI/CD or workload identity can trust an external identity provider without storing a client secret.
A client secret is a stored credential; a federated credential lets an external identity provider exchange tokens without a long-lived secret.
Decision details
Question: Should automation store a secret or use workload federation to avoid long-lived credentials?
Key differences
- Secrets must be stored, rotated, and protected.
- Federation reduces secret sprawl but requires correct issuer, subject, and audience configuration.
- Exam scenarios often reward eliminating stored secrets when a supported federation path exists.
Common mistake
Treating a secret in a pipeline variable as equivalent to identity-based federation.
Check before deciding
- Inventory app credentials before rotation.
- Confirm federated issuer/subject/audience values.
- Use least-privilege role assignments at the narrowest useful scope.
StorageData access impact
Best match
Service SAS vs User Delegation SAS
Choose Service SAS whenUse a service SAS when you intentionally need a SAS signed with account key authority for supported storage resources.
Choose User Delegation SAS whenUse a user delegation SAS for Blob access when Entra-based delegation is available and stronger identity governance is preferred.
A service SAS is signed with storage account credentials; a user delegation SAS is secured with Microsoft Entra credentials.
Decision details
Question: Should access be signed with storage account authority, or delegated from an Entra-authenticated user?
Key differences
- Service SAS relies on storage account key material and can be broad if not scoped carefully.
- User delegation SAS is tied to Entra authentication and is preferred for many Blob scenarios.
- Both still require tight expiry, permissions, IP/protocol restrictions, and evidence of who issued the token.
Common mistake
Issuing a long-lived broad SAS because it is quick, then losing track of who can access the data.
Check before deciding
- Confirm resource type, required permissions, expiry, IP range, and protocol before issuing SAS.
- Prefer user delegation where supported and operationally practical.
- Record the issuing identity, scope, expiry, and revocation/rotation path.
AI + dataSpeech workload choice
Best match
Speech to text vs Speech translation
Choose Speech to text whenUse speech to text when the output should preserve the source language as text.
Choose Speech translation whenUse speech translation when the scenario requires translated text or multilingual speech workflows.
Speech to text transcribes spoken audio; speech translation transcribes and translates speech across languages.
Decision details
Question: Does the app need transcription only, or transcription plus translation?
Key differences
- Speech to text is the base transcription workload.
- Speech translation adds language translation requirements and related quality considerations.
- Both require attention to language, audio quality, region, latency, and privacy requirements.
Common mistake
Choosing translation when the scenario only asks for transcription or captions in the original language.
Check before deciding
- Identify source language, target language, and latency requirement.
- Test representative audio, accents, and noise conditions.
- Check endpoint and key handling before release.
StorageData access impact
Best match
Storage account key vs SAS
Choose Storage account key whenUse storage account keys only when account-level shared-key access is explicitly required and tightly controlled.
Choose SAS whenUse SAS when the need can be scoped to specific resources, permissions, time windows, IP ranges, or protocols.
Storage account keys grant broad shared-key access; SAS tokens delegate scoped access for a time, permission set, and resource scope. Also covers: SAS vs storage account access key.
Decision details
Question: Does the consumer need full account-level key access, or a scoped, time-bound token?
Key differences
- Account keys can grant broad access across the storage account.
- SAS can narrow access but must be generated and governed carefully.
- Disabling shared key, rotating keys, or revoking SAS can break dependent apps if not inventoried first.
Common mistake
Sharing an account key for a narrow upload/download task that should have used a scoped SAS or managed identity.
Check before deciding
- Inventory apps using account keys, connection strings, and SAS before rotation or disabling shared key.
- Prefer the narrowest access method that satisfies the consumer.
- Capture expiry, permissions, and owner for every SAS issued.
StorageData access impact
Best match
Storage Queue vs Service Bus Queue
Choose Storage Queue whenUse Storage Queue for simple asynchronous work items where basic queue semantics are enough.
Choose Service Bus Queue whenUse Service Bus Queue when the workload needs richer broker features such as sessions, dead-lettering, duplicate detection, transactions, or advanced retry behavior.
Storage Queue is simple queue storage; Service Bus Queue is an enterprise broker with sessions, dead-lettering, and advanced messaging. Also covers: Queue Storage vs Service Bus.
Decision details
Question: Is this a simple storage-backed queue, or enterprise messaging with broker features?
Key differences
- Storage Queue is simpler and tied to storage account patterns.
- Service Bus Queue is built for messaging semantics and operational controls.
- Poison-message handling, ordering, lock duration, and delivery guarantees are the deciding factors.
Common mistake
Starting with Storage Queue for a business process that later needs dead-letter inspection, sessions, or stronger delivery semantics.
Check before deciding
- Define ordering, retry, duplicate, poison-message, and dead-letter requirements.
- Inspect queue length, age, failures, and consumer behavior before migration.
- Test failure and replay behavior before production cutover.
Identity & governanceIdentity lifecycle impact
Best match
System-assigned vs User-assigned managed identity
Choose System-assigned managed identity whenUse a system-assigned managed identity when one Azure resource needs its own identity tied to that resource lifecycle.
Choose User-assigned managed identity whenUse a user-assigned managed identity when multiple resources need the same identity or when identity lifecycle must be managed separately.
A system-assigned identity is tied to one Azure resource lifecycle; a user-assigned identity is a standalone reusable identity that can be attached to multiple resources.
Decision details
Question: Should the identity live and die with one resource, or be reusable across resources?
Key differences
- System-assigned identity is created and deleted with the resource.
- User-assigned identity is a standalone Azure resource that can be attached to multiple workloads.
- Role assignments and cleanup differ; deleting a workload may not remove user-assigned identity access.
Common mistake
Using a user-assigned identity for convenience and forgetting that its role assignments survive after workloads are deleted.
Check before deciding
- List attached resources and role assignments for the identity before changing it.
- Choose system-assigned for simple one-resource access; user-assigned for reuse or stable identity needs.
- Audit stale user-assigned identities and remove unused role assignments.
Core platformScope and identity
Best match
Tenant vs subscription
Choose Tenant whenUse tenant when the scenario is users, groups, app registrations, identities, consent, and directory-wide controls.
Choose Subscription whenUse subscription when the scenario is resources, quotas, policies, role assignments, deployments, and billing/cost scope.
A tenant is the Microsoft Entra identity boundary; a subscription is an Azure billing and resource-management boundary.
Decision details
Question: Is the exam scenario asking about identity/directory scope or resource/billing/deployment scope?
Key differences
- Tenant and subscription are related but not interchangeable.
- RBAC role assignments can be scoped under subscriptions, but identities come from a tenant.
- Many mistakes come from changing the wrong account, tenant, or subscription in CLI context.
Common mistake
Answering a subscription question with a tenant control, or running commands in the wrong subscription after switching directories.
Check before deciding
- Run az account show before lab commands.
- Confirm tenant ID and subscription ID separately.
- Use runbooks for RBAC and subscription-scope changes.
StorageData access impact
Best match
User delegation SAS vs Account SAS
Choose User delegation SAS whenUse user delegation SAS for Blob scenarios where Entra-authenticated delegation is supported and preferred.
Choose Account SAS whenUse account SAS only when the required resource type or operation requires account-key signing and the risk is accepted.
User delegation SAS uses Microsoft Entra credentials for Blob access; account SAS relies on storage account keys and can authorize broader account operations.
Decision details
Question: Can the SAS be based on Entra delegation, or must it be signed with account key authority?
Key differences
- User delegation SAS avoids direct account-key use and ties issuance to Entra authorization.
- Account SAS can cover broader service/resource types but inherits account-key risk.
- Both need narrow permissions, short expiry, and owner-recorded evidence.
Common mistake
Using account SAS by habit even when user delegation SAS would provide a better identity-governed path.
Check before deciding
- Confirm the storage service, operation, and client support before choosing SAS type.
- Use short expiry and minimal permissions; record who issued the token and why.
- Review shared-key settings, key rotation impact, and active SAS dependencies.
AI + dataSearch relevance impact
Best match
Vector Search vs Semantic Ranker
Choose Vector Search whenUse vector search when meaning similarity matters, such as finding related passages even when users do not use exact keywords.
Choose Semantic Ranker whenUse semantic ranker when text results need language-aware reranking, captions, or answer-style improvements after retrieval.
Vector search finds embedding similarity; semantic ranker reranks text results with deeper language understanding. Also covers: Semantic ranking vs Vector search; Vector search vs semantic ranker.
Decision details
Question: Do users need similarity over embeddings, language-aware reranking of text results, or a hybrid of both?
Key differences
- Vector search depends on embeddings, vector fields, chunking strategy, and distance similarity.
- Semantic ranker works over text results and semantic configuration; it does not replace an embedding strategy.
- Hybrid retrieval can combine keyword, vector, and semantic ranking, but each layer adds cost and tuning complexity.
Common mistake
Turning on every relevance feature at once and then not knowing whether vector quality, keyword matching, or semantic ranking caused the result.
Check before deciding
- Create a small relevance test set with expected documents before changing ranking behavior.
- Check index fields, vector dimensions, semantic configuration, and query mode before production changes.
- Measure quality and latency separately for keyword, vector, semantic, and hybrid queries.
ArchitectureCompute scale / availability impact
Best match
Virtual Machine Scale Set vs Availability set
Choose Virtual Machine Scale Set whenUse VM Scale Sets when you need autoscale, uniform/flexible orchestration, rolling upgrades, or a fleet of similar VM instances.
Choose Availability set whenUse availability sets when you have individually managed VMs that need fault/update-domain placement without fleet scaling.
A VM Scale Set manages a group of VM instances as a scalable fleet; an availability set spreads individual VMs across fault and update domains.
Decision details
Question: Do you need a managed scalable fleet, or fixed VM placement for availability of individually managed VMs?
Key differences
- Scale sets are about fleet management and scaling.
- Availability sets are about VM placement across fault/update domains.
- Scale sets can integrate with load balancers and autoscale rules; availability sets do not provide that fleet lifecycle by themselves.
Common mistake
Using an availability set when the real requirement is autoscale and rolling instance management.
Check before deciding
- Clarify whether the workload needs instance individuality or fleet behavior.
- Review load balancing, image, upgrade, and autoscale requirements.
- Check VM/disks/network dependencies before migration.
NetworkingConnectivity architecture impact
Best match
Virtual WAN vs hub-spoke VNet
Choose Virtual WAN whenUse Virtual WAN when the scenario emphasizes many branches, global transit, managed hubs, large-scale VPN/ExpressRoute connectivity, and simplified routing operations.
Choose Hub-spoke VNet whenUse hub-spoke VNet when the organization wants direct control of hub resources, peering, firewall placement, route tables, and custom network appliances.
Virtual WAN centralizes large-scale branch, VPN, ExpressRoute, and routing connectivity; hub-spoke VNet uses customer-managed hub networking and peering patterns.
Decision details
Question: Is the design asking for managed global connectivity fabric, or explicit hub networking you design and operate?
Key differences
- Virtual WAN abstracts and manages much of the connectivity fabric.
- Hub-spoke gives more explicit control but more operational responsibility.
- Routing, firewall, DNS, and inspection requirements usually decide the fit.
Common mistake
Choosing hub-spoke because it is familiar even when the scenario asks for many branch sites and simplified global transit.
Check before deciding
- Map sites, regions, inspection points, and routing ownership.
- Check current peering and route-table behavior before migration.
- Design DNS and private endpoint resolution with the chosen hub model.
NetworkingConnectivity / routing impact
Best match
VNet peering vs VPN Gateway
Choose VNet peering whenUse VNet peering for low-latency private connectivity between Azure virtual networks when address spaces do not overlap and transitive routing is not assumed.
Choose VPN Gateway whenUse VPN Gateway when you need IPsec/IKE tunnel connectivity, hybrid connectivity, point-to-site users, or network boundaries that require gateway mediation.
VNet peering connects Azure virtual networks through Microsoft backbone routing; VPN Gateway connects networks through encrypted tunnels, often across on-premises or separate environments.
Decision details
Question: Are you connecting Azure VNets directly, or do you need encrypted tunnel connectivity across on-premises, branches, or separate network boundaries?
Key differences
- Peering is not a VPN tunnel and does not automatically provide transitive routing.
- VPN Gateway introduces gateway SKUs, tunnel configuration, routing, and availability design.
- Peering is usually simpler for same-cloud VNet-to-VNet connectivity; gateways are required for many hybrid scenarios.
Common mistake
Building a hub-and-spoke design with peering but forgetting that traffic does not transit unless routing and gateway transit are explicitly designed.
Check before deciding
- Inventory address spaces and route tables before connecting networks.
- Check DNS resolution and private endpoint dependencies before cutover.
- Use Resource Graph and network runbooks before changing routes.
NetworkingHybrid connectivity availability impact
Best match
VPN Gateway active-active vs active-standby
Choose Active-active VPN whenUse active-active when the scenario requires multiple active tunnels, higher availability, or stronger hybrid connectivity resilience.
Choose Active-standby VPN whenUse active-standby when simpler VPN failover is acceptable and the environment does not need concurrent active tunnel paths.
Active-active VPN Gateway uses multiple active tunnel instances for higher availability and throughput patterns; active-standby relies on a standby instance for failover.
Decision details
Question: Does the hybrid connection need multiple active tunnels, or is standard gateway failover enough?
Key differences
- Active-active requires compatible on-premises configuration and routing behavior.
- Active-standby is simpler but has less concurrent tunnel redundancy.
- BGP, local network gateway setup, and route propagation must match the design.
Common mistake
Turning on active-active without verifying the on-premises device, BGP, and routing expectations.
Check before deciding
- Inventory VPN connections and BGP settings.
- Confirm tunnel count and on-premises device capability.
- Review effective routes before changing gateway mode.
No matching comparison. Try private endpoint, managed identity, RBAC, metric alert, storage access, backup, or app hosting.