Azure AZ-204 common mistakes
Azure AZ-204 · Understand the traps and how to avoid them.
When a question asks whether an Azure Function can run longer than 10 minutes or scale to many instances, the candidate answers from Consumption-plan defaults without first identifying the hosting plan named in the scenario.
Most study material introduces Functions on the Consumption plan first, so the 5-minute default / 10-minute maximum timeout and the cold-start/scale behaviour get memorised as universal rules. Premium, Dedicated (App Service plan) and container-hosted functions behave differently, and the exam frequently makes the plan the deciding detail.
What to do instead
Build a four-row table (Consumption, Flex/Premium, Dedicated, Container Apps) with columns for max timeout, always-ready instances, VNet integration and cold start, and rehearse re-reading the scenario for the plan keyword (e.g. 'must run for 30 minutes', 'must connect to a private endpoint', 'no cold starts') before answering any Functions question.
On App Service deployment-slot questions the candidate says a swap exchanges all configuration, or forgets that settings marked as slot settings ('deployment slot setting' / sticky) do not move during a swap, and ignores the warm-up requirement before traffic is redirected.
Swapping feels like 'copy slot A onto slot B', which suggests everything transfers. The exam instead tests the exceptions: sticky app settings and connection strings stay with the slot, and a poorly warmed-up slot causes errors right after a swap.
What to do instead
Memorise the rule 'swap moves code and non-sticky configuration; sticky settings stay put', and when a scenario mentions environment-specific values (a staging database, a different Key Vault) choose to mark those as deployment slot settings rather than duplicating app settings.
The candidate selects the Archive access tier for data described as 'rarely accessed but must be readable immediately', or assumes a blob in Archive can be read, copied or have its tier changed without a rehydration step (Standard vs High priority) that takes hours.
Archive is presented as the cheapest tier, so 'cold data = cheapest tier' becomes the reflex. The offline/rehydration latency and the fact that blob metadata can be read but content cannot are easy to skim past, and lifecycle-policy questions lean on exactly that distinction.
What to do instead
Anchor the tiers to access latency, not price: Hot (immediate), Cool (immediate, 30-day minimum), Cold (immediate, 90-day minimum), Archive (offline, rehydration required, 180-day minimum). For each scenario ask 'how fast must the first byte be available?' before choosing a tier.
On Cosmos DB questions the candidate picks a partition key based on uniqueness alone (often /id), or chooses Strong consistency for a globally distributed, multi-write account, and then also expects cross-partition queries to be cheap.
Partition key and consistency level are taught as separate chapters, so they are recalled as vocabulary rather than as design constraints. The exam scenarios are written so the stated access pattern (a tenant, a device, a category) and the stated latency/availability requirement rule out the default-sounding answers.
What to do instead
For every Cosmos DB scenario, write down the dominant query predicate and the write distribution first, then pick a partition key with high cardinality and even write spread that appears in that predicate. Separately rank consistency levels by cost (Strong > Bounded staleness > Session > Consistent prefix > Eventual) and remember that multi-region writes forbid Strong.
The candidate answers 'create an app registration, generate a client secret, and store it in App Service application settings' when the scenario involves an Azure-hosted app calling Key Vault, Storage or another Azure resource - and also assumes a system-assigned managed identity survives deletion of the resource or can be shared between two resources.
Secret-based service-principal auth is the pattern shown in most tutorials and feels like the 'real' way to authenticate. Managed identity is then treated as a nice-to-have rather than the default, and its lifecycle rules (system-assigned dies with the resource; user-assigned is standalone and reusable) are never internalised.
What to do instead
Adopt the rule 'if the caller is an Azure resource and the target is an Azure resource, the answer is managed identity with an RBAC role assignment - no secret in code or config'. Then memorise: system-assigned = 1:1 lifecycle with the resource; user-assigned = independent resource, can be attached to many and survives deletion of any one.
For authentication/authorization questions the candidate picks the authorization code flow for a daemon or background job, confuses delegated permissions (scopes) with application permissions (app roles), or forgets that the client credentials flow requires admin consent and cannot run in a public client.
The auth-code flow is the most familiar sample, so it is selected whenever 'user signs in' or 'app calls an API' appears. The exam instead tests which flow is possible given the actor: no user present means client credentials; a public client such as a desktop or mobile app must use PKCE and must never hold a secret.
What to do instead
Answer two questions before choosing a flow: (1) Is there a signed-in user? (2) Is the client confidential (server, can keep a secret) or public? Map the pair to the flow - user + public = auth code with PKCE; no user = client credentials; device or restricted input = device code. Then check whether the scenario needs delegated scopes or app roles.
When asked how to detect and diagnose a slow or failing dependency call, the candidate selects a metric alert on CPU or response time, or relies on default logging, instead of enabling Application Insights dependency tracking, sampling configuration and custom telemetry (TrackEvent/TrackDependency) needed to see the call chain.
Azure Monitor, Log Analytics and Application Insights are learned as three interchangeable 'monitoring' answers, so the features get mixed up. In particular, candidates forget that Application Insights is what gives request/dependency correlation and end-to-end transaction views, and that sampling can hide the events they expect to see.
What to do instead
Learn one sentence per feature: metrics = numeric time series and alert rules; Log Analytics = KQL over collected logs; Application Insights = distributed tracing, dependency calls, exceptions and custom events. When a scenario says 'trace a request across services' or 'find which SQL call is slow', the answer must involve Application Insights telemetry, and mention adaptive sampling before concluding events are missing.
The candidate applies a blanket retry policy to every call in a resilience question - retrying 400/404 responses, retrying a non-idempotent POST, or retrying without backoff or a circuit breaker - and treats a retry as a substitute for handling the failure.
Retry is remembered as 'always good', so any question containing a transient failure gets 'add retries'. The exam instead tests classification of the failure and the side effects of repeating the operation, plus the fact that a retry storm can worsen an outage without exponential backoff and jitter.
What to do instead
Before choosing a retry strategy, classify the error: transient (timeouts, 429, 5xx, connection resets) versus non-transient (400, 401, 404, validation). Retry only transient errors, only idempotent operations or ones made idempotent with a message/operation ID, and pair exponential backoff with jitter and a circuit breaker.
Asked to deliver notifications or stream telemetry, the candidate picks between Event Grid, Event Hubs and Service Bus by name familiarity - e.g. using Event Hubs for discrete resource-change events with multiple subscribers, or assuming Event Grid guarantees ordered, exactly-once delivery so handlers need no idempotency.
All three are 'messaging', so the selection is remembered as a vague category rather than by delivery model, payload size, ordering and consumption pattern. The delivery-guarantee detail (at-least-once everywhere, so handlers must be idempotent) is frequently skipped because it is not a configuration setting.
What to do instead
Use a three-line decision rule: Event Grid = reactive, discrete events from Azure resources or custom topics, push, filtered subscriptions; Event Hubs = high-volume telemetry streaming with partitions, consumer groups and checkpoints; Service Bus = enterprise messaging with queues/topics, peek-lock settlement, sessions, duplicate detection and dead-lettering. Always add idempotent handlers because delivery is at-least-once.
On API Management questions the candidate places a rate-limiting or transformation policy in the wrong section (e.g. rate-limit-by-key in <outbound>, or a rewrite in <inbound> after the backend call), assumes <rate-limit> is per-caller rather than per-subscription, or thinks subscription keys authenticate end users.
Policy XML is unfamiliar syntax, so the sections are treated as decoration and the candidate focuses on the policy name only. The exam deliberately tests section semantics (inbound runs before the backend, outbound after) and the difference between a subscription key (identifies a product subscription, not a user) and real authentication via OAuth/JWT validation.
What to do instead
Memorise the pipeline order inbound → backend → outbound → on-error, and place each policy by when it must run. Distinguish rate-limit (per subscription) from rate-limit-by-key (per extracted key such as a user ID or IP), and answer 'identify the calling application' with subscription keys versus 'identify the end user' with validate-jwt plus OAuth tokens.