AZ-204 Developing Solutions for Microsoft Azure

What programming experience do you need for the AZ-204 exam?

The AZ-204 requires proficiency in at least one Azure-supported programming language -- Microsoft specifically recommends one to two years of experience developing solutions in C#, Java, JavaScript, Python, or another supported language. Beyond programming skills, you need hands-on experience with Azure SDKs, Azure CLI, and Azure services including App Service, Azure Functions, Storage, Cosmos DB, and authentication libraries.

---

The Microsoft Certified: Azure Developer Associate credential, earned by passing the AZ-204 exam, validates that you can design, build, test, and maintain cloud applications and services on Azure. This is the developer-focused counterpart to the administrator-focused AZ-104 -- where administrators manage infrastructure, developers build applications that run on it.

Azure developers are among the most in-demand cloud professionals in the market. The 2024 Stack Overflow Developer Survey found that Azure is used by 28% of professional developers, making it the second most widely used cloud platform. Organizations transitioning workloads to Azure need developers who understand not just how to write code, but how to architect cloud-native applications, integrate Azure services, implement authentication, handle distributed system failures, and optimize for performance and cost.

The AZ-204 is considered moderately difficult at the associate level -- harder than the AZ-104 for candidates without development backgrounds, comparable for those with strong coding skills. The exam includes case studies and scenario questions that test judgment about which Azure development approach suits a described scenario, not just knowledge of individual service APIs.

---

AZ-204 Exam Overview

The AZ-204 exam contains 40-60 questions with 180 minutes (3 hours) allowed. The passing score is 700 out of 1000. The exam includes multiple choice, multiple select, drag-and-drop, and case study questions. Performance-based labs may appear in some exam versions, requiring task completion in a simulated environment.

Domain	Approximate 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%

Objectives verified at learn.microsoft.com/certifications/azure-developer. Microsoft revises exam content periodically.

---

Domain 1: Develop Azure Compute Solutions (25-30%)

Azure App Service

Azure App Service is the most frequently tested compute service on the AZ-204. Developers need to know beyond basic deployment -- the exam tests configuration, scaling, deployment strategies, and troubleshooting.

Deployment slots allow developers to deploy to a staging slot before swapping to production with zero downtime. Traffic can be gradually shifted to a slot before full swap, enabling progressive rollouts. The exam tests:

• az webapp deployment slot swap CLI command for swapping slots
• Traffic routing percentage configuration for A/B testing
• Slot-sticky settings that do not swap with the code (connection strings, app settings marked as slot settings)

Autoscale rules trigger scaling based on metrics (CPU percentage, memory, request count, HTTP queue length) or on schedules. The AZ-204 tests the difference between scale out (add more instances) and scale up (change to a larger instance size), and the appropriate metrics for each.

Deployment methods:

• Git deployment: App Service deploys from a Git repository automatically on push
• ZIP deployment: Upload a compressed archive via az webapp deployment source config-zip
• Docker container deployment: Deploy a containerized application from Azure Container Registry or Docker Hub
• Azure Pipelines/GitHub Actions: CI/CD pipeline integration for automated deployments

Azure Functions

Azure Functions provides serverless compute that executes code in response to triggers. The AZ-204 extensively tests Functions development patterns.

Function triggers and bindings are the core of Functions development:

Trigger Type	When It Fires
HTTP trigger	On HTTP request
Timer trigger	On a schedule (CRON expression)
Blob trigger	When a blob is created or modified
Queue trigger	When a message arrives in a storage queue
Service Bus trigger	When a message arrives in a Service Bus queue or topic
Event Hubs trigger	When events arrive in an Event Hub
Cosmos DB trigger	When documents are created or modified

Output bindings allow functions to write to Azure services without writing SDK code directly. A function can read from a queue (trigger), transform data, and write to Cosmos DB (output binding) with no explicit SDK calls.

Durable Functions extend Azure Functions with stateful, long-running workflows:

• Orchestrator function: Coordinates the workflow, calling activity functions
• Activity function: Does the actual work (individual steps)
• Entity function: Manages durable state (actor pattern)

Durable Functions patterns tested on the exam:

1. Function chaining: Execute a series of functions in sequence, passing output as input
2. Fan-out/fan-in: Execute multiple functions in parallel, wait for all to complete
3. Async HTTP APIs: Expose long-running operations as HTTP endpoints with polling
4. Monitor: Implement a recurring polling pattern that adapts its sleep interval

"Azure Functions fundamentally changed how we architect event-driven systems. The binding model means your code focuses on business logic while Azure handles all the infrastructure -- queues, databases, storage -- as first-class inputs and outputs. That abstraction is both powerful and testable." -- Jeff Hollan, Principal Program Manager for Azure Functions at Microsoft, from the Azure Developer Community Series

Azure Container Solutions

Azure Container Registry (ACR) stores and manages private Docker container images. Key developer operations: docker login, docker push, docker pull, and az acr build for building images directly in Azure without a local Docker installation.

Azure Container Apps (ACA) is a serverless container hosting platform built on Kubernetes but without Kubernetes management overhead. It supports:

• Automatic scaling based on HTTP traffic, messages, or custom metrics (including scale to zero)
• Dapr integration for microservice communication, state management, and pub/sub
• Traffic splitting between container revisions for gradual rollouts

Azure Container Instances (ACI) is appropriate for simple containerized tasks, batch processing, and CI/CD pipeline execution -- scenarios that do not need orchestration or persistent scale.

---

Domain 2: Develop for Azure Storage (15-20%)

Azure Blob Storage SDK

The AZ-204 tests working knowledge of the Azure Blob Storage SDK. Core client classes:

• BlobServiceClient: Client for the storage account, creates containers
• BlobContainerClient: Client for a container, lists and manages blobs
• BlobClient: Client for a single blob, upload, download, set metadata

Blob lifecycle management policies automate transitions between access tiers (Hot, Cool, Cold, Archive) and blob deletion based on last modified date or last accessed date, critical for cost optimization in large storage implementations.

Blob storage access control:

• Access keys: Root credentials providing full account access (store securely in Key Vault, rotate regularly)
• Shared Access Signatures (SAS): Time-limited, permission-scoped tokens (user delegation SAS is most secure)
• Azure RBAC: Grant Entra ID identities specific permissions at account, container, or blob level
• Anonymous public access: Container and blob level (disable unless specifically required)

Azure Cosmos DB SDK

The AZ-204 tests Cosmos DB application development using the Core (SQL) API:

• CosmosClient: Thread-safe, should be instantiated as a singleton and reused
• CosmosDatabase: Logical container for collections
• CosmosContainer: Container for items; partition key is set at creation and cannot change
• CosmosItem: Individual document with required id and partition key fields

Optimistic concurrency control in Cosmos DB uses ETags. When retrieving an item, the ETag is returned. When updating, the client can specify IfMatch: <etag> to fail if another process updated the item since retrieval.

Change feed -- Cosmos DB automatically generates a change feed (ordered log of changes) for each container. Applications can read the change feed to process events triggered by document creates and updates, enabling event-driven architectures.

---

Domain 3: Implement Azure Security (20-25%)

Authentication with Microsoft Identity Platform

Microsoft Identity Platform (MSAL) -- the authentication platform that enables developers to build applications that sign in users with Microsoft, work, or school accounts.

OAuth 2.0 flows tested on AZ-204:

• Authorization Code Flow: Used by web applications that run on a server, supports refresh tokens for long-lived sessions
• Authorization Code Flow with PKCE: Used by single-page apps and mobile apps where the client secret cannot be kept confidential
• Client Credentials Flow: Used for daemon applications running without user interaction (service-to-service)
• Device Code Flow: Used for devices that cannot display a browser (IoT, CLI tools)

MSAL.NET library (Microsoft.Identity.Client) is the primary authentication library for .NET developers. Key usage:

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithClientSecret(clientSecret)
    .WithTenantId(tenantId)
    .Build();

var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();
string accessToken = result.AccessToken;

Azure Key Vault

Azure Key Vault provides secure storage for secrets (connection strings, API keys), cryptographic keys (used for encryption operations), and certificates (TLS/SSL). Developers interact with Key Vault through:

• The Azure.Security.KeyVault.Secrets SDK package
• Managed identities: Application authenticates to Key Vault using the application's Azure identity, eliminating the need to store credentials in configuration

Managed identities are the recommended approach for application authentication to Azure services:

• System-assigned managed identity: Created for a specific resource, deleted with the resource
• User-assigned managed identity: Created independently, can be assigned to multiple resources

The key benefit: no secrets in code or configuration files. The managed identity authenticates to Entra ID, which returns a token the application uses to access Azure services including Key Vault, Cosmos DB, Service Bus, and Storage.

"The shift to managed identities in production Azure applications is the single most impactful security improvement developers can make. Eliminating credential strings from configuration files, environment variables, and code repositories removes an entire category of security incidents." -- Mark Simos, Lead Cybersecurity Architect at Microsoft, from the Azure Developer Security Guide

Azure API Management

Azure API Management (APIM) acts as a proxy layer in front of backend APIs, providing:

• Authentication and authorization enforcement (OAuth, API keys, subscriptions)
• Rate limiting and quota enforcement per subscription or API key
• Request and response transformation using policies
• Developer portal for API documentation and testing
• Caching of responses for frequently requested, slowly changing data

The AZ-204 tests APIM policy writing. Policies are XML documents applied at different scopes (global, product, API, operation). Common policies: rate-limit, cache-lookup, set-header, validate-jwt, rewrite-uri.

---

Domain 4: Monitor, Troubleshoot, and Optimize (15-20%)

Application Insights

Application Insights -- an Application Performance Monitoring (APM) service that provides:

• Request and dependency tracking (how long calls to databases, HTTP services, and other dependencies take)
• Exception tracking with full stack traces
• Performance profiling (identify slow code paths in production)
• User session analytics
• Availability testing (configured HTTP ping tests that alert when a URL returns errors or exceeds latency thresholds)

Developers instrument applications using the Application Insights SDK. For .NET applications, Microsoft.ApplicationInsights NuGet package enables automatic collection of HTTP requests, dependencies, and exceptions. Custom telemetry:

var client = new TelemetryClient();
client.TrackEvent("UserRegistered", new Dictionary<string, string> { { "region", userRegion } });
client.TrackMetric("OrderValue", orderTotal);

Caching with Azure Cache for Redis

Azure Cache for Redis -- a managed Redis service providing in-memory data store capabilities for caching, session state, and message brokering. Developer patterns tested on AZ-204:

• Cache-aside pattern: Application checks cache before querying database; on cache miss, loads from database and populates cache with TTL
• Session state provider: Store ASP.NET session state in Redis for stateless, scalable web applications
• Pub/sub: Redis supports lightweight publish/subscribe messaging between components

Redis Data Structure	Use Case
String	Simple key-value caching, counters
Hash	Object caching (field-level access)
List	Queues, recent items
Set	Tags, unique visitor tracking
Sorted Set	Leaderboards, time-series events

---

Domain 5: Connect to and Consume Services (15-20%)

Azure Service Bus

Azure Service Bus -- an enterprise message broker providing reliable, asynchronous message delivery between distributed application components. Key concepts:

• Queues: Point-to-point messaging, one sender and one receiver per message
• Topics and subscriptions: Publish/subscribe messaging, one sender and multiple independent receivers via subscriptions with filter rules
• Dead-letter queue: Messages that cannot be processed are moved here for investigation
• Message sessions: Group related messages and deliver them to a single consumer in order (required for ordered processing scenarios)

Azure Event Grid -- an event routing service that delivers events from Azure services (Blob Storage, Cosmos DB, Resource Manager) and custom sources to subscriber endpoints. Designed for low-latency, at-least-once delivery of discrete events rather than high-throughput message streaming.

The exam tests the distinction: Event Grid is for reactive event handling (a blob was uploaded, respond); Event Hubs is for high-volume event streaming (millions of IoT readings per second); Service Bus is for reliable, ordered enterprise message processing.

---

Preparation Strategy

Prerequisites and Experience Level

Microsoft recommends 1-2 years of professional development experience and familiarity with Azure development before attempting AZ-204. Candidates without at least 6 months of hands-on Azure SDK experience will struggle with scenario questions that assume practical knowledge.

Lab Setup

A personal Azure subscription is essential. The AZ-204 candidate needs experience deploying App Service applications, writing and deploying Azure Functions, configuring Key Vault and managed identity authentication, and querying Cosmos DB and Storage with SDK code. These skills are not developed through reading alone.

Primary Study Resources

Resource	Focus
Microsoft Learn AZ-204 path	All objectives, structured progression
Azure SDK documentation	Language-specific SDK usage
John Savill AZ-204 YouTube series	Deep scenario walkthroughs
A Cloud Guru / Pluralsight AZ-204	Video + interactive labs
GitHub Azure SDK samples	Working code examples for all services

---

Frequently Asked Questions

What programming experience do you need for the AZ-204 exam?

The AZ-204 requires proficiency in at least one Azure-supported programming language -- Microsoft specifically recommends one to two years of experience developing solutions in C#, Java, JavaScript, Python, or another supported language. Beyond programming skills, you need hands-on experience with Azure SDKs, Azure CLI, and Azure services including App Service, Azure Functions, Storage, Cosmos DB, and authentication libraries.

Should I take AZ-900 before AZ-204?

The AZ-900 is not a prerequisite for AZ-204 and experienced developers often skip it. However, developers without Azure exposure benefit from the AZ-900 conceptual foundation before diving into AZ-204's hands-on content. Candidates with strong cloud development experience from AWS or other platforms can typically proceed directly to AZ-204 with focused Azure service study.

How does AZ-204 relate to AZ-400 DevOps Engineer?

The AZ-204 is a standalone associate certification focused on application development. The AZ-400 (DevOps Engineer Expert) is an expert-level certification that combines AZ-204 or AZ-104 with DevOps practices. Many DevOps engineers pursue AZ-204 first to build the development foundation, then AZ-400 to expand into CI/CD pipelines, infrastructure as code, and release management.

---

References

1. Microsoft. "Exam AZ-204: Developing Solutions for Microsoft Azure." Microsoft Learn, 2024.
2. Microsoft. "Azure SDK for .NET documentation." learn.microsoft.com/dotnet/azure, 2024.
3. Microsoft. "Azure Functions documentation." Microsoft Learn, 2024.
4. Hollan, Jeff. "Building event-driven applications with Azure Functions." Azure Developer Community Series, 2023.
5. Simos, Mark. "Azure Developer Security Guide." Microsoft Security documentation, 2024.
6. Stack Overflow. "Developer Survey 2024." Stack Overflow, 2024.
7. Microsoft. "Microsoft Authentication Library (MSAL) documentation." Microsoft Learn, 2024.