The AZ-204 has a reputation problem. Developers approach it expecting to write code on the exam. Operations engineers approach it expecting Azure configuration tasks. Both end up surprised by what actually appears. The exam occupies a specific middle ground that neither group naturally prepares for — and understanding that middle ground is the difference between a confident pass and a frustrating failure.
This is what AZ-204 actually tests, without the gaps in most study guides.
The Core Premise: Configuration + Code Integration
AZ-204 tests whether you know how Azure services behave and how to integrate them from code — not whether you can write production-quality applications and not whether you can configure Azure infrastructure. The exam sits between developer and administrator: you need to know enough configuration to make services work, and enough SDK knowledge to use them correctly.
| Domain | Weight |
|---|---|
| Develop Azure compute solutions | 25-30% |
| Develop for Azure storage | 15-20% |
| Implement Azure security | 20-25% |
| Monitor, troubleshoot, and optimize Azure solutions | 15-20% |
| Connect to and consume Azure services and third-party services | 15-20% |
The compute and security domains together account for 45-55% of the exam. Candidates who are strong in those two areas have a strong foundation for passing.
Domain 1: Develop Azure Compute Solutions (25-30%)
Azure App Service
App Service knowledge on AZ-204 goes deeper than on AZ-104. The exam tests deployment mechanisms and configuration details:
Deployment options:
Deployment slots: staging environments for zero-downtime deployments. Slot swap warms up the staging slot, then swaps routing. Sticky settings (connection strings, app settings marked as slot-specific) don't swap — they stay in the slot.
ZIP deployment: upload a ZIP archive and App Service extracts it. Used by
az webapp deploy.Container deployment: App Service can run Docker containers. Configuration specifies the container registry, image, and tag.
Scale rules: App Service autoscale requires Standard or Premium plan. Scale-out rules trigger on CPU percentage, memory, HTTP queue length, or custom metrics. Scale-in rules follow similar patterns. The exam tests scale rule configuration — specifically minimum/maximum instance counts and cool-down periods.
App Service environments (ASE): isolated, dedicated environments for high-security or high-scale workloads. AZ-204 tests when ASE is appropriate vs a standard App Service plan.
Azure Functions
Azure Functions is tested more deeply on AZ-204 than on any other exam.
Triggers and bindings: the exam distinguishes between triggers (what starts the function) and bindings (declarative connections to other services). A function has exactly one trigger. It can have multiple input and output bindings.
Common trigger/binding combinations tested:
HTTP trigger: responds to HTTP requests. Output binding to Queue Storage sends a message.
Timer trigger: runs on a CRON schedule. Output binding to Table Storage writes a record.
Queue Storage trigger: fires when a message arrives. Input binding from Blob Storage reads a file.
Cosmos DB trigger: fires when documents are created or updated using change feed.
Durable Functions: extensions to Azure Functions that enable stateful workflows. Four patterns tested on AZ-204:
| Pattern | Description | When to use |
|---|---|---|
| Function chaining | Execute functions in sequence, output of one to input of next | Sequential multi-step processes |
| Fan-out/fan-in | Execute multiple functions in parallel, wait for all to complete | Parallel processing with aggregation |
| Async HTTP APIs | Expose long-running operations via HTTP with polling | Long operations that clients can poll |
| Monitor | Recurring, flexible polling | Dynamic polling intervals, complex conditions |
Scaling behavior: Azure Functions on the Consumption plan scale automatically, with instances added based on trigger load. The Consumption plan has a cold start problem — functions that haven't executed recently have latency on first invocation. The Premium plan keeps instances warm using pre-warmed instances.
"The most common AZ-204 failure point isn't knowing Azure Functions — it's knowing Durable Functions specifically. The orchestration patterns, the entity functions, the activity functions. That content appears regularly and candidates who skipped Durable Functions in their study are exposed." — Scott Duffy, Azure developer instructor, Udemy
Azure Container Solutions
Azure Container Registry (ACR): private container registry. The exam tests ACR tiers (Basic, Standard, Premium — differ in storage, throughput, geo-replication), authentication methods (admin user, service principal, managed identity), and ACR Tasks (automated image building from git commits or base image updates).
Azure Container Instances (ACI): for quick container deployment without orchestration. The exam tests multi-container groups, volume mounts (Azure Files volumes for persistent storage), and environment variables for container configuration.
Domain 2: Develop for Azure Storage (15-20%)
Azure Blob Storage SDK
AZ-204 tests Blob Storage SDK usage at a code level. Expect questions about which client classes to instantiate for specific operations:
BlobServiceClient: account-level operations (create/delete containers, list containers)BlobContainerClient: container-level operations (create/delete blobs, list blobs, set container policies)BlobClient: individual blob operations (upload, download, set metadata, set tier)
Access tiers programmatically: SetAccessTier(AccessTier.Cool) changes blob tier without re-uploading. The exam tests both CLI commands and SDK method calls for tier changes.
Concurrency: two strategies tested:
Optimistic concurrency: use ETags. Read blob with ETag, write with
If-Match: <etag>header. Server rejects write if ETag doesn't match (someone else modified the blob).Pessimistic concurrency: acquire a lease (BlobLeaseClient). Only the lease holder can write. Other writers are blocked.
Azure Cosmos DB
Cosmos DB receives significant coverage on AZ-204. The exam tests:
Consistency levels: five consistency levels ranked from strongest to weakest:
Strong: reads always return most recent committed write
Bounded staleness: reads lag behind writes by at most a defined bound
Session: reads within a session see writes in that session
Consistent prefix: reads never see out-of-order writes
Eventual: no ordering guarantees, but data converges
The exam presents scenarios with conflicting requirements: "A global application needs the lowest latency but can tolerate slightly stale reads." That's Eventual or Consistent Prefix — choosing between them depends on whether ordering matters for the application.
Partition keys: the partition key determines how Cosmos DB distributes data. A bad partition key creates "hot partitions" that receive disproportionate read/write traffic. Exam scenarios test partition key selection: "A social application stores user posts with a timestamp. Why shouldn't timestamp be used as partition key?" Because all writes go to the current timestamp range, creating a hot partition.
Change feed: Cosmos DB change feed exposes a sequential log of all document changes. Azure Functions Cosmos DB trigger uses change feed. Applications can also read change feed directly using the change feed processor library.
Domain 3: Implement Azure Security (20-25%)
Security is the domain where AZ-204 diverges most from other developer exams. The questions are highly specific about authentication mechanisms and secret management.
Microsoft Identity Platform and MSAL
OAuth 2.0 flows tested:
| Flow | Use case |
|---|---|
| Authorization code + PKCE | Web apps and SPAs where user interaction is possible |
| Client credentials | Service-to-service (no user involved) |
| Device code | Devices without browsers |
| On-behalf-of | Middle-tier service calling another service with delegated user permissions |
MSAL (Microsoft Authentication Library): the SDK for acquiring tokens. Key method: AcquireTokenInteractive() for user-facing authentication, AcquireTokenForClient() for client credentials, AcquireTokenSilent() to use cached tokens before prompting the user.
Token cache: MSAL maintains a token cache. Applications should call AcquireTokenSilent() first — it returns cached tokens if valid. Only call interactive token acquisition if silent acquisition fails (typically on first run or after token expiration).
Azure Key Vault
Key Vault stores secrets, keys, and certificates. AZ-204 tests:
SDK operations: SecretClient for secrets, KeyClient for keys, CertificateClient for certificates. Each follows the same pattern: create client with vault URI and credential, call get/set/delete methods.
Managed identities: the recommended way for Azure resources to authenticate to Key Vault. No credentials stored in code or configuration. The Azure platform manages the identity lifecycle.
System-assigned managed identity: tied to a specific resource lifecycle. Deleted when the resource is deleted.
User-assigned managed identity: independent resource that can be assigned to multiple other resources. Persists independent of any single resource.
Key Vault access policies vs RBAC: the exam tests both. Key Vault can use its own access policies model (grant permissions to an identity for specific operations) or Azure RBAC (use role assignments). RBAC is the newer approach and required for Key Vault Managed HSM.
Domain 4: Monitor, Troubleshoot, and Optimize (15-20%)
Application Insights
Application Insights provides APM (Application Performance Monitoring) for Azure applications. AZ-204 tests:
Telemetry types:
Requests: incoming HTTP requests
Dependencies: outgoing calls (databases, external services)
Exceptions: unhandled exceptions and caught exceptions tracked manually
Custom events: business-level events tracked with
TelemetryClient.TrackEvent()Custom metrics: numerical measurements tracked with
TelemetryClient.TrackMetric()
Sampling: Application Insights can sample telemetry to reduce data volume. Adaptive sampling automatically adjusts the sampling rate based on traffic. Fixed-rate sampling uses a defined percentage. The exam tests when sampling is appropriate and what data is lost.
Distributed tracing: correlation IDs propagated across services so you can trace a request from front-end to back-end to database in a single trace view. Requires the SDK to be configured in each service, or OpenTelemetry integration.
Azure Cache for Redis
The exam tests Redis use cases and configuration:
Cache-aside pattern: application checks cache before hitting database. On cache miss, fetch from database and populate cache.
Eviction policies:
allkeys-lru(evict least recently used keys when memory is full),volatile-lru(evict LRU keys with expiration set),noeviction(return errors when memory is full).Data types: strings, lists, sets, sorted sets, hashes. The exam doesn't test Redis commands deeply but does test which data types are appropriate for specific use cases.
Domain 5: Connect to and Consume Azure Services (15-20%)
Azure API Management
APIM positions itself as a gateway in front of backend APIs. AZ-204 tests:
Policies: XML-based transformations applied at different scopes (global, product, API, operation). Common policies tested:
rate-limit-by-key: limit calls per key per time windowcache-lookup/cache-store: cache API responsesset-header: add or modify HTTP headersrewrite-uri: transform the inbound URL before forwarding to backendvalidate-jwt: validate JWT tokens in requests
Policy execution order: inbound → backend → outbound → on-error. The exam tests which section a policy belongs in: rate limiting goes in inbound, caching goes in both inbound (lookup) and outbound (store).
Azure Event Grid vs Service Bus vs Event Hubs
This three-way comparison appears on almost every AZ-204 exam:
| Service | Pattern | Message type | Use case |
|---|---|---|---|
| Event Grid | Pub/sub, event-driven | Discrete events (up to 1 MB) | React to state changes in Azure resources |
| Service Bus | Queue / pub-sub | Business messages (up to 100 MB) | Reliable message delivery, ordering, transactions |
| Event Hubs | Streaming | Telemetry streams | High-volume event ingestion, time-series data |
The exam gives scenarios and asks which service fits. "An application needs to process IoT sensor data from 10,000 devices at high throughput" — Event Hubs. "An application must ensure each order is processed exactly once and in order" — Service Bus with sessions. "A function must trigger when a blob is uploaded to Azure Storage" — Event Grid.
Practice Exam Strategy for AZ-204
AZ-204 has a higher failure rate than most developer associate exams because the content scope is unusually wide — compute, storage, security, monitoring, and messaging — and each domain requires actual knowledge, not just recognition.
Diagnostic approach: take one practice exam before studying. Identify which domains you score below 60% on. Those are your real gaps. Domains you score 70%+ on require only light review.
Code questions: some AZ-204 questions show code snippets and ask what the code does or what's wrong with it. Familiarity with the Azure SDK patterns (client instantiation, async/await patterns, exception types) helps significantly. The .NET SDK is most common in practice questions, but concepts apply across SDK languages.
Target score before exam: 75% on Whizlabs or MeasureUp practice exams. AZ-204 is graded 700/1000 to pass.
AZ-204 Domain Breakdown
| Domain | Weight | What Distinguishes AZ-204 Coverage |
|---|---|---|
| Develop Azure compute solutions | 25-30% | App Service deployment mechanics, Azure Functions triggers/bindings/durable patterns, container registry |
| Develop for Azure storage | 15-20% | Blob Storage SDK client classes, SAS tokens, lifecycle management, Cosmos DB consistency |
| Implement Azure security | 20-25% | OAuth 2.0 flows, MSAL token acquisition, managed identities, Key Vault SDK operations |
| Monitor, troubleshoot, and optimize | 15-20% | Application Insights telemetry types, sampling, distributed tracing, Redis patterns |
| Connect to and consume Azure services | 15-20% | API Management policies, Event Grid vs Service Bus vs Event Hubs three-way comparison |
The compute and security domains together represent 45-55% of the exam. Candidates who are strong in Azure Functions and MSAL/OAuth have a strong foundation. The three-way messaging comparison (Event Grid, Service Bus, Event Hubs) and the Durable Functions patterns are the highest-value topics to know cold.
Blob Storage: What AZ-204 Specifically Tests
AZ-204 tests Blob Storage from a developer's perspective — SDK operations, access control from code, and lifecycle management configuration.
SAS token types and their security implications:
| SAS Type | Signed By | Revocation Method | Best For |
|---|---|---|---|
| Service SAS | Storage account key | Rotate the signing key (revokes all SAS signed with that key) | Single-service access for external partners |
| Account SAS | Storage account key | Rotate the signing key | Multi-service access |
| User delegation SAS | Azure AD credential | Revoke delegating user's Azure AD permissions | Preferred method — no storage key required |
The exam tests user delegation SAS as the preferred approach because it eliminates the need to distribute storage account keys. Questions framed as "a developer needs to grant temporary read access to a blob without sharing the storage account key" → user delegation SAS with appropriate validity period.
Access tier management from code: BlobClient.SetAccessTierAsync(AccessTier.Cool) moves a blob to Cool tier without re-uploading it. The exam tests this as the answer for "change the access tier of blobs meeting a specific condition" — you don't need to download and re-upload; tier changes are metadata operations on existing blobs.
Lifecycle management policies: JSON-based policies that automatically transition blobs between tiers or delete them based on age and access patterns. The exam tests the policy structure: a rule with filters (blob prefix, blob type) and actions (tierToArchive, tierToCool, delete) with conditions (daysAfterModificationGreaterThan, daysAfterCreationGreaterThan). Questions present a retention requirement and ask candidates to identify the correct rule structure.
Static website hosting in Blob Storage: enabling static website hosting on a Blob Storage account creates a special $web container. Files in $web are served as a static website with a storage-assigned hostname. The exam tests this as the answer for "host a static single-page application at low cost without a web server."
Azure Functions Deep Dive: What AZ-204 Tests That Other Exams Don't
Durable Functions: The High-Frequency Topic
Durable Functions is specifically called out as an AZ-204 failure point, and the exam goes deeper than most study guides cover.
The four patterns — what the exam tests about each:
Function chaining: activity functions are called sequentially, with the output of each passed to the next. The orchestrator function uses await on each activity call. If any activity fails, the orchestrator handles the exception. Use case: an order processing workflow where payment must succeed before fulfillment starts.
Fan-out/fan-in: the orchestrator calls multiple activity functions in parallel using Task.WhenAll(). All parallel activities must complete before the orchestrator proceeds. Use case: process multiple files in parallel and aggregate the results. The exam tests the code pattern: create a list of tasks, pass to Task.WhenAll(), await the result.
Async HTTP APIs (external event pattern): the orchestrator pauses waiting for an external event (context.WaitForExternalEvent()). A client calls an HTTP endpoint to raise the event. The orchestrator resumes. Use case: an approval workflow where the orchestrator waits for a human to approve via a web form.
Monitor pattern: the orchestrator polls a condition on a recurring basis with flexible intervals. Unlike a timer trigger (fixed interval), the monitor can check a condition, wait a variable amount of time based on the result, and continue until a terminal condition is met. Use case: polling an external system until a long-running job completes.
Entity functions (counter pattern): stateful entities that hold state and process operations sequentially. Used for shared state management (counters, accumulators) without concurrency conflicts. The exam tests entity functions when a question mentions "multiple concurrent invocations updating shared state."
Consumption Plan vs Premium Plan: Specific Differences
| Feature | Consumption Plan | Premium Plan |
|---|---|---|
| Billing | Per execution + GB-seconds | Per vCPU-second + GB-second (minimum) |
| Cold start | Yes — function may be cold | No — pre-warmed instances |
| Scale | Auto-scale from 0 | Auto-scale from minimum instances |
| VNet integration | Not supported | Supported |
| Execution time limit | 5 minutes (configurable to 10) | Unlimited (configurable) |
| Best for | Infrequent or burst workloads | Low-latency, VNet-connected, always-on |
AZ-204 tests the Premium plan specifically for scenarios involving VNet integration ("a function must access an on-premises database through a VNet gateway"), consistently low latency ("customer-facing function cannot have cold starts"), and long-running executions ("function processes large files and may run for 30+ minutes").
Application Insights: AZ-204 Testing Depth
Application Insights is tested on AZ-204 at a developer integration level — not just "enable it" but "write the code to use it correctly."
SDK integration patterns the exam tests:
// Track custom event
var telemetry = new TelemetryClient();
telemetry.TrackEvent("OrderPlaced", new Dictionary<string, string>
{
{ "OrderId", orderId },
{ "UserId", userId }
});
// Track custom metric
telemetry.TrackMetric("OrderValue", orderAmount);
// Track dependency (external call)
var dependency = new DependencyTelemetry("HTTP", "payment-api", "ProcessPayment", startTime, duration, success);
telemetry.TrackDependency(dependency);
Sampling types and when to use each:
Adaptive sampling: Application Insights SDK automatically adjusts sampling rate to keep telemetry volume under a target. Default mode for SDK integration. The SDK decides which requests to sample.
Fixed-rate sampling: you configure a specific percentage (e.g., 10%). Both client SDK and server SDK must be set to the same rate for correlation to work.
Ingestion sampling: applied at the Application Insights service level, not the SDK. Useful when you can't modify the SDK configuration.
The exam tests: "An application generates excessive telemetry volume and is approaching the daily data cap. The telemetry must remain statistically representative." Adaptive sampling is the answer — it reduces volume while maintaining representative coverage.
Distributed tracing with correlation IDs: Application Insights automatically propagates correlation IDs across HTTP calls when the SDK is installed in all services. The Operation.Id links all telemetry from a single user request across multiple services. The exam tests this when questions ask about tracing requests across microservices.
"The most common AZ-204 failure point isn't knowing Azure Functions — it's knowing Durable Functions specifically. The orchestration patterns, the entity functions, the activity functions. That content appears regularly and candidates who skipped Durable Functions in their study are exposed." — Scott Duffy, Azure developer instructor, Udemy
References
Microsoft. Exam AZ-204: Developing Solutions for Microsoft Azure — Skills Measured. Microsoft Learn, 2024. https://learn.microsoft.com/en-us/certifications/exams/az-204/
Duffy, Scott. AZ-204 Developing Solutions for Microsoft Azure. Udemy, 2024. (Widely recommended AZ-204 course with consistent updates as exam content changes)
Microsoft. Azure Functions Durable Extensions — Patterns and Concepts. Azure Documentation, 2024. https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview
Microsoft. Azure Cosmos DB Developer Documentation. Azure Documentation, 2024. https://learn.microsoft.com/en-us/azure/cosmos-db/
Whizlabs. AZ-204 Developing Solutions for Microsoft Azure Practice Tests. Whizlabs, 2024. https://www.whizlabs.com (Practice exam platform with detailed explanations)
Microsoft. Microsoft Identity Platform Documentation. Azure Documentation, 2024. https://learn.microsoft.com/en-us/azure/active-directory/develop/
Frequently Asked Questions
Do you need to write code on the AZ-204 exam?
Some questions show code snippets and ask what the code does or what's wrong with it. You don't write code from scratch, but you need to read Azure SDK patterns — client instantiation, async/await, exception types. The .NET SDK appears most frequently in practice questions.
How heavily is Durable Functions tested on AZ-204?
Durable Functions is one of the highest-failure areas on AZ-204. The four orchestration patterns (function chaining, fan-out/fan-in, async HTTP APIs, monitor) are tested directly. Candidates who skip Durable Functions in their study are exposed on a meaningful portion of the exam.
What is the difference between Event Grid, Service Bus, and Event Hubs on AZ-204?
Event Grid handles discrete events for reactive architectures (blob created, resource changed). Service Bus handles reliable business message delivery with ordering and transactions. Event Hubs handles high-throughput telemetry streaming with multiple consumers. The exam gives scenarios and asks which fits.
What Cosmos DB concepts are tested on AZ-204?
Consistency levels (Strong, Bounded staleness, Session, Consistent prefix, Eventual), partition key selection and hot partition avoidance, change feed for event-driven processing, and SDK usage (BlobServiceClient, BlobContainerClient, BlobClient hierarchy).
Is AZ-104 required before AZ-204?
No. Microsoft accepts AZ-104 or AZ-204 independently. However, AZ-204 has infrastructure content (App Service plans, Container Registry, deployment slots) that AZ-104 covers. Developers without AZ-104 background need supplementary study on Azure infrastructure topics.