Exam AZ-204: Developing Solutions for Microsoft Azure Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the Exam AZ-204: Developing Solutions for Microsoft Azure. We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for Exam AZ-204: Developing Solutions for Microsoft Azure. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Exam AZ-204: Developing Solutions for Microsoft Azure
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for Exam AZ-204: Developing Solutions for Microsoft Azure. It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Develop Azure compute solutions
28%ACR — Azure Container Registry
Private managed container registry: stores, builds, and distributes images; integrates with CI/CD and automation.
Key Insight
ACR stores and builds images (ACR Tasks) and automates triggers — it does NOT run containers; use SP/MI for CI/CD auth.
Often Confused With
Common Mistakes
- Enabling the ACR admin user for CI/CD — use service principals or managed identities for least privilege.
- Treating ACR like a runtime — ACR only stores/distributes images, it doesn't run containers.
- Believing ACR Tasks need a local Docker daemon — Tasks are server-side builds and can use base-image triggers.
ACI & Container Apps — Serverless Containers
ACI: on‑demand single/ephemeral containers; Container Apps: managed microservices with autoscale, revisions, and Dapr.
Key Insight
ACI = fast, single-container, ephemeral runtime; Container Apps = serverless microservice platform — neither requires you to run or manage a K8s node.
Often Confused With
Common Mistakes
- Confusing ACI with AKS — ACI has no Kubernetes orchestration or service-mesh features.
- Assuming images must be in ACR — ACI/Container Apps can pull from Docker Hub or private registries with auth.
- Relying on container local disk for state — ACI containers are ephemeral; mount Azure Files or other external storage for persistence.
App Service Web Apps — Hosting & Containers
PaaS for web apps/APIs: Windows/Linux containers, registry integration, runtime settings, and deployment diagnostics.
Key Insight
App Service is a PaaS host (not an orchestrator): containers need registry auth and the local file system is ephemeral — use Azure Storage for any app
Often Confused With
Common Mistakes
- Treating App Service local disk as durable storage — move uploads/state to Blob/File storage.
- Deploying container without registry auth — configure ACR/Docker Hub credentials or managed identity.
- Assuming deployment slots are separately billed or fully isolated — slots share the same App Service Plan and resources.
App Service Scaling — Scale Out vs Scale Up
Autoscale on the App Service Plan using metric or scheduled rules (min/max, thresholds, cooldowns) while respecting tier
Key Insight
Autoscale runs at the App Service Plan level with evaluation periods and cooldowns — scaling is not instant; externalize session state for scale-out.
Often Confused With
Common Mistakes
- Expecting instant reaction to metric spikes — autoscale uses evaluation windows and cooldowns.
- Relying on in-memory session state across scale-out — use Redis/SQL/Azure Cache for session persistence.
- Configuring autoscale per web app — autoscale settings apply to the App Service Plan (affecting all apps on the plan).
Autoscaling — Telemetry‑Driven Scale Rules
Auto-adjust compute using metric rules, schedules and cooldowns; tune limits to meet SLAs and control cost.
Key Insight
Scaling is bounded and delayed — thresholds, cooldowns, min/max and warm-up dictate speed and bill impact.
Often Confused With
Common Mistakes
- Expecting instantaneous scale‑out — ignore cooldowns and cold‑starts at your peril
- Assuming autoscaling always lowers costs — high min instances or slow scale‑in keeps bills high
- Thinking serverless is free or reserved plans remove scaling trade‑offs
Azure Functions Hosting (Consumption / Premium / App Service / Flexible)
Pick hosting by scale behavior, VNet needs, cold‑start tolerance and billing (per exec vs reserved hosts).
Key Insight
Consumption = per‑exec billing + possible cold‑starts and limited networking; Premium/Flexible add pre‑warm, VNet and predictable latency.
Often Confused With
Common Mistakes
- Believing Consumption never has cold‑starts
- Assuming Consumption supports full VNet integration
- Treating Flexible Consumption as identical to Premium
Deployment Slots & Blue‑Green Swaps
Staging slots for warm‑up and staged promotions; swaps exchange content/config but slot‑sticky settings and some binding
Key Insight
Swap exchanges content/config; slot‑sticky settings stay. Custom hostnames, private TLS certs and scale settings don't swap — in‑process state is lost
Often Confused With
Common Mistakes
- Assume custom hostnames or DNS move with a swap
- Expect all TLS/SSL certs and bindings to swap
- Think all app settings/connection strings auto-move (must mark slot‑sticky)
App Service & Function Slot Nuances
App Service slots enable staging/warm‑up; Function App slots have plan limits, can affect running functions, and warm‑up
Key Insight
Function slots share the app's worker pool and scale together; swaps can terminate in‑flight functions, warm‑up isn't on Consumption, and each slothas
Often Confused With
Common Mistakes
- Assume slot swap guarantees zero downtime for running functions
- Expect the warm‑up/warmup trigger on all hosting plans (not on Consumption)
- Assume slots can scale independently of the app's worker pool
Azure Functions — Triggers & Bindings
Event-driven serverless functions: triggers invoke code; bindings simplify I/O; hosting/runtime control scale and deploy
Key Insight
Triggers start execution; bindings ease input/output but do NOT replace service SDKs; hosting plan dictates cold-starts and scale behavior
Often Confused With
Common Mistakes
- Assuming bindings remove need for service SDKs — bindings are helpers, not full replacements
- Believing serverless removes design for scaling or cold starts — design for retries, idempotency and warm-up
- Using local.settings.json for prod secrets — it's local-only and insecure
Function App — Hosting, Runtime & Settings
Function App is the deployment unit grouping functions by runtime/config; hosting plan and runtime affect scale, cold‑st
Key Insight
Function App settings (runtime stack/version, hosting plan, app settings, networking) determine supported languages, scale limits, cold‑start profile,
Often Confused With
Common Mistakes
- Treating all hosting plans as identical — Consumption, Premium, and Dedicated differ in pre-warm, scale limits, and latency
- Assuming runtime/version changes are harmless — switching runtime can break bindings or language features
- Expecting in-memory state to survive scale-out — instances don't share process memory
Function Triggers — Single Entry Point
The single event source that starts a Function; pick Event Grid, Event Hubs, or Service Bus by delivery and scale needs.
Key Insight
Exactly one trigger starts a function — pick by semantics: Event Hubs=partitioned streaming, Service Bus=durable queues/topics/sessions, Event Grid=軽量
Often Confused With
Common Mistakes
- Assuming a function can have multiple triggers — it's always one trigger per function.
- Treating triggers and bindings as the same — triggers start execution; bindings are declarative I/O.
- Expecting identical delivery, ordering, and scaling across Event Grid, Event Hubs, and Service Bus.
Timers, HTTP/Webhooks & Data Bindings — Start vs I/O
Timers and HTTP/webhooks start Functions; bindings (blob/queue/table) declare input/output so you avoid SDK calls for fl
Key Insight
Triggers start execution; bindings simplify I/O but don't inherit full service semantics — timers can miss runs, webhooks need reachable endpoints, IO
Often Confused With
Common Mistakes
- Believing timer triggers always run if host was offline — missed runs or catch-up depends on configuration.
- Assuming webhook triggers need no public endpoint or auth — webhooks require reachable endpoints and validation.
- Thinking bindings guarantee SDK-level delivery/retry semantics — many bindings have different guarantees and limits.
ACR — Azure Container Registry
Private managed container registry: stores, builds, and distributes images; integrates with CI/CD and automation.
Key Insight
ACR stores and builds images (ACR Tasks) and automates triggers — it does NOT run containers; use SP/MI for CI/CD auth.
Often Confused With
Common Mistakes
- Enabling the ACR admin user for CI/CD — use service principals or managed identities for least privilege.
- Treating ACR like a runtime — ACR only stores/distributes images, it doesn't run containers.
- Believing ACR Tasks need a local Docker daemon — Tasks are server-side builds and can use base-image triggers.
ACI & Container Apps — Serverless Containers
ACI: on‑demand single/ephemeral containers; Container Apps: managed microservices with autoscale, revisions, and Dapr.
Key Insight
ACI = fast, single-container, ephemeral runtime; Container Apps = serverless microservice platform — neither requires you to run or manage a K8s node.
Often Confused With
Common Mistakes
- Confusing ACI with AKS — ACI has no Kubernetes orchestration or service-mesh features.
- Assuming images must be in ACR — ACI/Container Apps can pull from Docker Hub or private registries with auth.
- Relying on container local disk for state — ACI containers are ephemeral; mount Azure Files or other external storage for persistence.
App Service Web Apps — Hosting & Containers
PaaS for web apps/APIs: Windows/Linux containers, registry integration, runtime settings, and deployment diagnostics.
Key Insight
App Service is a PaaS host (not an orchestrator): containers need registry auth and the local file system is ephemeral — use Azure Storage for any app
Often Confused With
Common Mistakes
- Treating App Service local disk as durable storage — move uploads/state to Blob/File storage.
- Deploying container without registry auth — configure ACR/Docker Hub credentials or managed identity.
- Assuming deployment slots are separately billed or fully isolated — slots share the same App Service Plan and resources.
App Service Scaling — Scale Out vs Scale Up
Autoscale on the App Service Plan using metric or scheduled rules (min/max, thresholds, cooldowns) while respecting tier
Key Insight
Autoscale runs at the App Service Plan level with evaluation periods and cooldowns — scaling is not instant; externalize session state for scale-out.
Often Confused With
Common Mistakes
- Expecting instant reaction to metric spikes — autoscale uses evaluation windows and cooldowns.
- Relying on in-memory session state across scale-out — use Redis/SQL/Azure Cache for session persistence.
- Configuring autoscale per web app — autoscale settings apply to the App Service Plan (affecting all apps on the plan).
Autoscaling — Telemetry‑Driven Scale Rules
Auto-adjust compute using metric rules, schedules and cooldowns; tune limits to meet SLAs and control cost.
Key Insight
Scaling is bounded and delayed — thresholds, cooldowns, min/max and warm-up dictate speed and bill impact.
Often Confused With
Common Mistakes
- Expecting instantaneous scale‑out — ignore cooldowns and cold‑starts at your peril
- Assuming autoscaling always lowers costs — high min instances or slow scale‑in keeps bills high
- Thinking serverless is free or reserved plans remove scaling trade‑offs
Azure Functions Hosting (Consumption / Premium / App Service / Flexible)
Pick hosting by scale behavior, VNet needs, cold‑start tolerance and billing (per exec vs reserved hosts).
Key Insight
Consumption = per‑exec billing + possible cold‑starts and limited networking; Premium/Flexible add pre‑warm, VNet and predictable latency.
Often Confused With
Common Mistakes
- Believing Consumption never has cold‑starts
- Assuming Consumption supports full VNet integration
- Treating Flexible Consumption as identical to Premium
Deployment Slots & Blue‑Green Swaps
Staging slots for warm‑up and staged promotions; swaps exchange content/config but slot‑sticky settings and some binding
Key Insight
Swap exchanges content/config; slot‑sticky settings stay. Custom hostnames, private TLS certs and scale settings don't swap — in‑process state is lost
Often Confused With
Common Mistakes
- Assume custom hostnames or DNS move with a swap
- Expect all TLS/SSL certs and bindings to swap
- Think all app settings/connection strings auto-move (must mark slot‑sticky)
App Service & Function Slot Nuances
App Service slots enable staging/warm‑up; Function App slots have plan limits, can affect running functions, and warm‑up
Key Insight
Function slots share the app's worker pool and scale together; swaps can terminate in‑flight functions, warm‑up isn't on Consumption, and each slothas
Often Confused With
Common Mistakes
- Assume slot swap guarantees zero downtime for running functions
- Expect the warm‑up/warmup trigger on all hosting plans (not on Consumption)
- Assume slots can scale independently of the app's worker pool
Azure Functions — Triggers & Bindings
Event-driven serverless functions: triggers invoke code; bindings simplify I/O; hosting/runtime control scale and deploy
Key Insight
Triggers start execution; bindings ease input/output but do NOT replace service SDKs; hosting plan dictates cold-starts and scale behavior
Often Confused With
Common Mistakes
- Assuming bindings remove need for service SDKs — bindings are helpers, not full replacements
- Believing serverless removes design for scaling or cold starts — design for retries, idempotency and warm-up
- Using local.settings.json for prod secrets — it's local-only and insecure
Function App — Hosting, Runtime & Settings
Function App is the deployment unit grouping functions by runtime/config; hosting plan and runtime affect scale, cold‑st
Key Insight
Function App settings (runtime stack/version, hosting plan, app settings, networking) determine supported languages, scale limits, cold‑start profile,
Often Confused With
Common Mistakes
- Treating all hosting plans as identical — Consumption, Premium, and Dedicated differ in pre-warm, scale limits, and latency
- Assuming runtime/version changes are harmless — switching runtime can break bindings or language features
- Expecting in-memory state to survive scale-out — instances don't share process memory
Function Triggers — Single Entry Point
The single event source that starts a Function; pick Event Grid, Event Hubs, or Service Bus by delivery and scale needs.
Key Insight
Exactly one trigger starts a function — pick by semantics: Event Hubs=partitioned streaming, Service Bus=durable queues/topics/sessions, Event Grid=軽量
Often Confused With
Common Mistakes
- Assuming a function can have multiple triggers — it's always one trigger per function.
- Treating triggers and bindings as the same — triggers start execution; bindings are declarative I/O.
- Expecting identical delivery, ordering, and scaling across Event Grid, Event Hubs, and Service Bus.
Timers, HTTP/Webhooks & Data Bindings — Start vs I/O
Timers and HTTP/webhooks start Functions; bindings (blob/queue/table) declare input/output so you avoid SDK calls for fl
Key Insight
Triggers start execution; bindings simplify I/O but don't inherit full service semantics — timers can miss runs, webhooks need reachable endpoints, IO
Often Confused With
Common Mistakes
- Believing timer triggers always run if host was offline — missed runs or catch-up depends on configuration.
- Assuming webhook triggers need no public endpoint or auth — webhooks require reachable endpoints and validation.
- Thinking bindings guarantee SDK-level delivery/retry semantics — many bindings have different guarantees and limits.
Develop for Azure storage
18%Change Feed (Cosmos DB)
Per-partition, ordered append-only stream of inserts/updates for eventing, ETL, replication and resumable processing.
Key Insight
Ordering and checkpoints are per-partition; change feed is at‑least‑once — use leases/continuation tokens and idempotency to resume and dedupe.
Often Confused With
Common Mistakes
- Expecting deletes: change feed does NOT emit deletions by default.
- Assuming exactly-once delivery: it's at‑least‑once; duplicates can appear.
- Skipping a lease/lease container: you need a lease store to checkpoint and coordinate processors.
Cosmos DB Partitioning & RU Scaling
Partition-key creates logical partitions mapped to physical shards; choose keys to spread RU/s and storage, avoid hot‑sh
Key Insight
Logical ≠ physical: throughput and storage limits are enforced by the physical partition hosting your logical keys — design keys to spread load across
Often Confused With
Common Mistakes
- Treating logical partitions as physical shards: many logical partitions can live on one physical partition.
- Believing per-key RU is unlimited: RU limits depend on the physical partition hosting that key.
- Relying on autoscale to eliminate 429s: autoscale helps but won't stop hot‑partition throttling if traffic is skewed.
Blob Storage & Storage Accounts (ARM/Bicep)
Azure object storage; Storage Account controls SKU, kind, replication, tiers, networking and auth; declare with ARM/Bice
Key Insight
Account kind/sku + replication choose features (HNS, tiering); many account-level changes require recreate + data migration
Often Confused With
Common Mistakes
- Treat account kinds as interchangeable; some lack HNS or other features
- Expect to change replication or account kind in-place — often must recreate and migrate
- Assume archive-tier blobs are readable immediately; you must rehydrate before reading
Azure SDKs & REST APIs
Language-specific client libraries and REST endpoints to call/manage Azure services; auth, feature parity and behaviors
Key Insight
SDKs simplify calls but don't remove auth/RBAC, may lag REST on new features, and you must handle retries/idempotency
Often Confused With
Common Mistakes
- Assume an SDK removes the need to present valid credentials or RBAC permissions
- Expect SDKs and REST to expose identical features and timing
- Rely on client libs to fully manage retries, idempotency and long-running operations for you
Implement Azure security
18%Microsoft Entra ID (Entra ID) — Cloud Identity & RBAC
Cloud IAM for users and apps: app registrations, SSO, OAuth/OIDC/SAML and RBAC-based access control.
Key Insight
App registration ≠ service principal; tokens carry only requested/configured claims; SSO authenticates — apps still need scopes/roles for authZ.
Often Confused With
Common Mistakes
- Treating Entra ID as identical to on‑prem AD DS
- Assuming SSO alone grants application permissions
- Expecting one token to always contain every user role/claim
Service Principal — CLI/PowerShell
Tenant-scoped runtime identity for automation; create via az/PowerShell, choose credential type, then assign RBAC to use
Key Insight
Service principal is the runtime instance of an app registration in a tenant; creation does NOT auto-assign RBAC and credentials/expiry must be chosen
Often Confused With
Common Mistakes
- Using an app registration and service principal interchangeably in scripts
- Assuming creating an SP automatically grants subscription/resource RBAC
- Confusing appId with objectId (wrong identifier breaks assignments)
RBAC (Role‑Based Access Control) — Scope & Inheritance
Assign roles to principals at scopes; assignments inherit downward—use least-privilege to separate management vs data‑or
Key Insight
Role assignments apply to the chosen scope and all child resources (downward only); management‑plane rights do not equal data‑plane access.
Often Confused With
Common Mistakes
- Assuming RBAC grants data‑plane access — management vs data plane are separate.
- Defaulting to Owner to manage assignments — grant only assignment rights needed (least‑privilege).
- Believing role on a resource grants permissions on parent scopes — inheritance is downward only.
Managed Identities — System vs User‑Assigned
Azure‑managed service principals that fetch short‑lived OAuth tokens so apps don’t store credentials.
Key Insight
System‑assigned identity = tied to one resource; user‑assigned = reusable across resources; neither exposes long‑lived secrets—still requires RBAC.
Often Confused With
Common Mistakes
- Assuming a managed identity auto‑grants access — you must assign RBAC roles or access policies.
- Expecting system‑assigned identities to be shareable — they're bound to a single resource.
- Treating MI credentials as long‑lived secrets — tokens are short‑lived and not exposed for manual rotation.
Key Vault — Secrets, Keys & Certificates (Purge Protect)
Secure store for secrets, cryptographic keys and certs; pick software vs HSM, SKU, and explicit access control.
Key Insight
Soft-delete lets you recover objects; purge protection prevents permanent deletion — enable both. Creating a vault doesn't grant app access; configure
Often Confused With
Common Mistakes
- Treating purge protection as same as soft-delete — one prevents permanent removal, the other enables recovery.
- Assuming IaC creation of a vault auto-grants app access — you must set RBAC or access policies explicitly.
- Expecting all keys to be HSM-backed/exportable — HSM keys require premium SKU or Managed HSM and are typically non-exportable.
App Config — Env Vars, .env & App Settings (Secretless)
Keep runtime config outside code: use env vars/App Settings with Key Vault refs and managed identities for secretless gl
Key Insight
Use managed identity + Key Vault references in platform App Settings for secretless retrieval; locally use Azure CLI/VS creds — never commit secrets.
Often Confused With
Common Mistakes
- Storing production secrets directly in App Settings or env vars without Key Vault references.
- Thinking managed identity removes access control — the identity still needs RBAC/permissions granted.
- Checking .env or IDE cached secrets into source control as a 'temporary' shortcut.
Monitor, troubleshoot, and optimize Azure solutions
8%App Insights — Telemetry, Sampling & Alerts
APM for Azure apps: instrument via SDK/agent/auto to send traces/requests/deps/exceptions/metrics; use availabilitytests
Key Insight
App Insights is the app-focused part of Azure Monitor — sampling controls volume/cost and alerts diagnose, not fix, incidents
Often Confused With
Common Mistakes
- Treating App Insights as completely separate from Azure Monitor (it's a component)
- Expecting Application Insights to automatically fix performance issues rather than only surface diagnostics
- Assuming infinite/ free retention or that every event is collected (sampling/retention/cost apply)
Log Analytics & KQL — Query App Telemetry
Central log store + Kusto Query Language for App Insights and resource logs; use pipes to filter, aggregate, join, alert
Key Insight
KQL is a read-only, pipe-oriented language (not SQL); operation order, time range and ingestion latency change results
Often Confused With
Common Mistakes
- Treating KQL as SQL — operators and semantics differ (pipes are streaming, not relational JOINs)
- Believing a KQL query can modify or delete stored telemetry (queries are read-only)
- Expecting perfectly up-to-the-second data — ingestion latency and query time windows affect results
Alert Rules & Action Groups
Set metric/log alerts with evaluation window/frequency, aggregation, and action groups to notify or run automation.
Key Insight
Window = aggregation span; Frequency = rule run cadence — tune both to avoid flapping or delayed detection.
Often Confused With
Common Mistakes
- Treating evaluation window and frequency as identical — they serve different roles
- Using very short windows to 'catch faster' — causes false positives and flapping
- Assuming alerts auto-remediate — attach action groups/runbooks to automate responses
Load-test KPIs: Latency, Failures, Throughput
Track response-time percentiles, success rate, failed requests, and throughput to detect SLA/SLO breaches.
Key Insight
Prefer percentiles (p95/p99) over averages; normalize failures by total requests and align throughput to target load.
Often Confused With
Common Mistakes
- Equating high success rate with good UX while ignoring high latency
- Reporting raw failure counts without normalizing by total tests
- Treating a single test failure as a sustained outage
App Insights: Telemetry, API Keys & SDK
SDK-based telemetry: credentials, sampling, enrichment, and auto-collection for Application Insights.
Key Insight
TelemetryClient is thread-safe — reuse via DI; sampling can run client-side; initializers enrich, processors filter/drop.
Often Confused With
Common Mistakes
- Assuming the SDK auto-instruments every component without extra config
- Creating TelemetryClient per request instead of reusing via DI
- Believing sampling or ingestion won't drop custom events or can't be configured client-side
Async Debugging: Correlation, Logs & Replays
Correlate traces + structured logs, use durable patterns and idempotency to locate/fix faults in async flows.
Key Insight
Embed correlation IDs (traceparent/Activity) in messages and logs; collect distributed traces — replays can change outcomes unless processing is idemp
Often Confused With
Common Mistakes
- Relying on centralized logs alone — missing distributed traces and metrics
- Thinking one correlation ID automatically reveals root cause without contextual logs/timestamps
- Assuming event replay is risk-free — side effects and state can change outcomes
Connect to and consume Azure services and third-party services
28%APIM: Import & Policies (OpenAPI / WSDL)
API gateway to import, publish, secure and monitor APIs; enforce policies (validate-jwt, rate-limit, quotas) to protect
Key Insight
Rate-limit = request rate (throttle); quota = total calls over a time window; policies run at global/product/API/operation scopes.
Often Confused With
Common Mistakes
- Treating a Product as the same thing as an API
- Believing policies only work at the API level (they can be global/product/API/operation)
- Confusing rate limits (requests/sec) with quotas (total calls per period)
API Versioning: Path, Header, Query & Version Sets
Expose breaking/non‑breaking changes via path/header/query; use APIM version sets to group and route related versions.
Key Insight
Versioning choice affects routing, caching and client support — path is CDN/cache-friendly; header/query need explicit mapping in APIM.
Often Confused With
Common Mistakes
- Assuming path-based versioning is always the best choice
- Thinking header-based versioning cannot be cached by intermediaries
- Believing a version set automatically migrates clients to new versions
Event Grid — Serverless Pub/Sub Router
Serverless pub/sub router for discrete events; pushes to webhooks, Functions, and topics — for notifications, not raw‑TE
Key Insight
At‑least‑once delivery with no FIFO: filters route events but subscribers must handle duplicates and ordering.
Often Confused With
Common Mistakes
- Expecting exactly‑once or FIFO delivery — Event Grid is at‑least‑once with no ordering guarantee.
- Using Event Grid for high‑volume telemetry ingestion — use Event Hubs for streaming telemetry.
- Assuming Event Grid persists events long‑term — it only stores events transiently for retries.
Event Hubs — High‑Throughput Telemetry Stream
Partitioned, append‑only ingestion for high‑volume telemetry and streaming; use consumer groups for parallel readers.
Key Insight
Ordering is per‑partition only; consumer groups give isolated read positions; it's an ingest/stream, not a point‑to‑point queue.
Often Confused With
Common Mistakes
- Assuming exactly‑once delivery — Event Hubs provides at‑least‑once semantics.
- Treating Event Hubs as a transactional queue — it's an append‑only stream with multiple independent consumers.
- Expecting Event Hubs to do advanced routing/filters — use Event Grid or Stream Analytics for routing.
Service Bus vs Queue Storage — Messaging & Triggers
Service Bus: advanced messaging (sessions, DLQ, transactions). Queue Storage: simple, low-cost, high-throughput, limited
Key Insight
Pick Service Bus when you need ordering, deduplication, DLQ, transactions or sessions; pick Storage queues for cheap, large-scale, eventual-consistent
Often Confused With
Common Mistakes
- Storage queues don't provide a native DLQ — implement your own or use Service Bus
- Service Bus isn't FIFO globally — FIFO is only guaranteed with sessions/single-session ordering
- Duplicate detection keys on MessageId, not body; still design idempotent receivers
Service Bus Namespaces, Queues & Tiers
A namespace scopes queues/topics; tiers (Basic/Standard/Premium) control features, isolation, throughput and cost—choose
Key Insight
Tier dictates capabilities: Premium = dedicated capacity, partitioning and predictable throughput; Standard exposes topics/sessions but shares backend
Often Confused With
Common Mistakes
- Assuming queues enforce FIFO by default — FIFO requires sessions
- Setting --max-size as GB; MaxSize is specified in megabytes (MaxSizeInMegabytes)
- Enabling partitioning simply increases limits — it shards messages and impacts ordering/transaction scope
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet
- Google Cloud Security Operations Engineer Exam Cheat Sheet