This chapter covers Distributed Application Runtime (Dapr) integration with Azure Container Apps, a key topic for the AZ-204 exam under Compute objective 1.2. You will learn how Dapr simplifies microservices development by providing building blocks for state management, service invocation, pub/sub, and more, all as a sidecar pattern. Expect 5-10% of exam questions to touch Dapr concepts, often asking about its purpose, configuration in Container Apps, or comparing it to alternatives like Service Bus or Redis directly. Mastery of Dapr's role in Container Apps is essential for passing the compute section.
Jump to a section
Imagine a large hotel with hundreds of guests (microservices). Each guest has a personal butler (Dapr sidecar) that handles all communication with hotel services: ordering room service (state management), calling other guests (service invocation), sending mail (pub/sub), and managing secrets. The butler never leaves the guest's side—it runs as a separate process on the same floor (sidecar container in same pod). Guests don't need to know the hotel's internal phone system; they just tell their butler what they need. The hotel's front desk (Azure Container Apps environment) orchestrates the butlers, ensuring each guest has exactly one butler with a pre-configured set of skills (enabled building blocks). If a guest moves to a different floor (scaling), a new butler is assigned with the same training. The butlers communicate via a standardized protocol (gRPC or HTTP), and the hotel provides additional services like a central registry (Dapr placement service) for actors. This abstraction allows guests to focus on their core job (business logic) without worrying about plumbing.
What is Dapr and Why It Exists
Dapr (Distributed Application Runtime) is an open-source, portable, event-driven runtime that makes it easy for developers to build resilient, microservices-based applications that run on the cloud and edge. It addresses common challenges in distributed systems such as state management, service-to-service invocation, publish/subscribe messaging, and secret management. Instead of writing boilerplate code to integrate with Azure Storage, Service Bus, or Redis, developers use Dapr's standardized APIs. Dapr runs as a sidecar—a separate container that accompanies each microservice container in the same pod. This sidecar intercepts all network calls, providing the required capabilities without modifying application code.
How Dapr Works Internally
When a microservice wants to save state, it sends an HTTP or gRPC request to the local Dapr sidecar on a well-known port (default 3500 for HTTP, 50001 for gRPC). The sidecar then communicates with the configured state store component (e.g., Azure Cosmos DB, Redis) using its own connection. The application never directly touches the state store. Similarly, for service invocation, the application calls the sidecar with the target service ID (e.g., http://localhost:3500/v1.0/invoke/orders/method/get). Dapr resolves the target service via its name resolution component (mDNS in Kubernetes, or Azure Container Apps' built-in DNS) and forwards the request. For pub/sub, the application publishes messages to the sidecar, which then delivers them to the configured message broker (e.g., Azure Service Bus, Kafka).
Key Components, Values, and Defaults
Dapr Sidecar: Runs as a separate container in the same pod. Version 1.10+ is supported in Azure Container Apps. It listens on HTTP port 3500 and gRPC port 50001 by default.
Building Blocks: The core APIs: State Management, Service Invocation, Pub/Sub, Bindings, Actors, Secrets, Configuration, and Observability.
Components: YAML files that define the concrete implementation of a building block (e.g., a state store component using Redis). Each component has metadata like metadata.url for the Redis host, metadata.password for authentication.
Dapr Placement Service: Required only for Actors. It maintains a consistent hash ring to locate actor instances. In Azure Container Apps, this is managed automatically when you enable Actors.
Dapr Dashboard: A web UI for debugging, available at http://localhost:8080 when running locally with dapr dashboard.
Configuration in Azure Container Apps
Azure Container Apps natively supports Dapr. When you create a Container App, you can enable Dapr by setting --enable-dapr in the Azure CLI or via the portal. You must specify:
- Dapr Application ID: A unique identifier for the microservice (e.g., order-service). This is used for service invocation.
- Dapr Application Port: The port your application listens on (e.g., 8080).
- Dapr Protocol: HTTP or gRPC (default HTTP).
- Dapr Log Level: debug, info, warn, or error.
Example CLI command to create a Container App with Dapr enabled:
az containerapp create \
--name order-service \
--resource-group my-rg \
--environment my-env \
--image myregistry.azurecr.io/order-service:v1 \
--target-port 8080 \
--ingress external \
--enable-dapr \
--dapr-app-id order-service \
--dapr-app-port 8080Dapr components are configured via Azure Container Apps' component management. For example, to add a Redis state store:
az containerapp dapr component set \
--name statestore \
--resource-group my-rg \
--environment my-env \
--component-type state.redis \
--version v1 \
--metadata "redisHost=myredis.redis.cache.windows.net:6380" "redisPassword=..."Interaction with Related Technologies
Dapr complements Azure Container Apps by offloading distributed system concerns. It works with: - Azure Service Bus: As a pub/sub component. Dapr abstracts the topic/queue details. - Azure Cosmos DB: As a state store. Dapr handles consistency and retry. - Azure Key Vault: For secret management via the Secrets building block. - Azure Monitor: Dapr emits metrics and traces that can be collected by Azure Monitor for observability.
Dapr is not a replacement for message brokers or databases; it is a middleware that standardizes interactions. The exam often tests whether you know that Dapr reduces boilerplate but does not eliminate the need for the underlying service.
Verification Commands
To verify Dapr is running in a Container App, check logs:
az containerapp logs show --name order-service --resource-group my-rgLook for lines like time="..." level=info msg="Dapr sidecar started". You can also invoke the Dapr health endpoint:
curl http://localhost:3500/v1.0/healthzIf healthy, returns "OK".
Internal Mechanism Details
When Dapr sidecar starts, it initializes all configured components. It uses a component hot-reload mechanism: if a component YAML changes, Dapr reloads it without restarting the sidecar (supported in Kubernetes but not yet in Container Apps—requires update). For service invocation, Dapr uses mDNS in Kubernetes; in Container Apps, it relies on the environment's internal DNS. The sidecar caches the resolved endpoints for a default TTL of 30 seconds. For state management, Dapr supports multiple consistency models: eventual and strong. The default is eventual. For pub/sub, Dapr ensures at-least-once delivery by default; exactly-once requires idempotent consumers.
Default Timeouts and Retries
HTTP client timeout: 30 seconds (configurable via --dapr-http-read-buffer-size).
gRPC timeout: 60 seconds.
Retry: Dapr uses exponential backoff with jitter for component calls. Initial retry delay: 1 second, max delay: 60 seconds.
Actor idle timeout: 60 minutes (if no requests, actor deactivated).
Actor scan interval: 10 seconds to check for idle actors.
Security
Dapr supports mTLS for sidecar-to-sidecar communication. In Azure Container Apps, this is enabled by default when Dapr is enabled. The sidecar injects a sidecar certificate that is rotated every 24 hours. For component authentication, you can reference Azure Key Vault secrets using the secretStore component.
Limitations in Azure Container Apps
Not all Dapr components are supported; only those that integrate with Azure services (e.g., state stores: Azure Cosmos DB, Azure SQL, Redis; pub/sub: Azure Service Bus, Event Hubs, Kafka).
Dapr configuration is per Container App, not per revision. Changing Dapr settings creates a new revision.
Dapr sidecar resource usage is limited; the sidecar uses 50 MB memory and 0.5 CPU by default (configurable via --dapr-sidecar-cpu and --dapr-sidecar-memory).
Exam-Relevant Details
Dapr is open-source, not Microsoft proprietary. The exam may ask about its origins.
Dapr sidecar runs as a separate container in the same pod. Not as a daemon set or standalone process.
Dapr building blocks are accessed via HTTP/gRPC endpoints on localhost.
Dapr components are configured via YAML, but in Container Apps, you use Azure CLI or ARM templates.
Dapr Actors require a placement service; in Container Apps, it's managed automatically.
Dapr does NOT replace the underlying infrastructure (e.g., you still need a Redis instance).
Enable Dapr in Container App
First, you create or update a Container App with Dapr enabled. In the Azure portal, you toggle 'Enable Dapr' and set the Application ID and port. Using the CLI, you add `--enable-dapr --dapr-app-id myapp --dapr-app-port 8080`. This instructs the Container Apps runtime to inject a Dapr sidecar container alongside your application container. The sidecar is pre-configured with the specified ID and port. The environment also prepares the Dapr placement service if needed. Without this step, Dapr is not available.
Configure Dapr Components
After enabling Dapr, you define components like state stores or pub/sub brokers. In Container Apps, you use `az containerapp dapr component set` to create a component resource. Each component has a type (e.g., `state.redis`), version, and metadata. For example, a Redis state store requires the Redis host and password. The component is stored in the environment and referenced by the sidecar. When the sidecar starts, it loads all components from the environment. If a component fails to load, the sidecar logs an error but continues running.
Application Invokes Dapr API
Your application code calls the Dapr sidecar via HTTP or gRPC on localhost. For example, to save state, you POST to `http://localhost:3500/v1.0/state/statestore` with a JSON body containing the key and value. The sidecar receives the request, looks up the component configuration for `statestore`, and connects to the actual Redis instance. It serializes the data and sends it using the Redis protocol. The sidecar handles retries, timeouts, and error responses. The application does not need to know the Redis endpoint or credentials.
Dapr Resolves Service for Invocation
For service invocation, the application sends a request to `http://localhost:3500/v1.0/invoke/target-service/method/endpoint`. The sidecar parses the target service ID (`target-service`). It uses the name resolution component (in Container Apps, the environment's DNS) to find the IP address of the target service's sidecar. It then forwards the request over HTTP or gRPC to that sidecar, which forwards it to the actual application container on the configured port. The response is relayed back. If the target is not found, Dapr returns a 500 error.
Dapr Publishes or Subscribes to Messages
For pub/sub, the application publishes a message by POSTing to `http://localhost:3500/v1.0/publish/pubsubname/topicname`. The sidecar sends the message to the configured broker (e.g., Azure Service Bus). Subscriptions are configured either programmatically (via Dapr API) or declaratively (via component YAML). When a message arrives, the sidecar receives it from the broker and calls the application's endpoint (e.g., `/events`) with the message payload. The application must respond with HTTP 200 to acknowledge. If it fails, Dapr retries according to the broker's retry policy.
Enterprise Scenario 1: E-Commerce Order Processing A large e-commerce platform uses microservices for orders, inventory, payments, and shipping. Each service is deployed as an Azure Container App with Dapr enabled. The order service uses Dapr state management to store orders in Azure Cosmos DB. It invokes the inventory service via Dapr service invocation to check stock. After payment, it publishes an 'order-placed' event to an Azure Service Bus topic via Dapr pub/sub. The shipping service subscribes to that topic. This architecture eliminates direct HTTP calls and SDK dependencies. In production, the platform handles 10,000 orders per minute. Dapr's built-in retry and circuit breaking prevent cascading failures. Misconfiguration: If the Dapr application ID is misspelled, service invocation fails with a 500 error. The team uses Dapr observability with Azure Monitor to trace requests across services.
Enterprise Scenario 2: IoT Telemetry Ingestion An IoT solution ingests millions of device telemetry messages per hour. Each device sends data to an Azure Event Hubs instance. A Container App with Dapr bindings reads from Event Hubs (input binding) and processes the data. It uses Dapr state management to store device state in Redis for fast lookups. Dapr's output binding sends alerts to Twilio. The sidecar handles checkpointing for Event Hubs, so even if the container restarts, it resumes from the last checkpoint. Performance consideration: Dapr sidecar CPU and memory limits must be set appropriately; default 0.5 CPU may be insufficient for high-throughput scenarios. The team increased the sidecar CPU to 1.0 and memory to 128 MB. Common mistake: Forgetting to configure the Event Hubs consumer group correctly in the binding component, causing duplicate processing.
Enterprise Scenario 3: Multi-Region Active-Active A financial services company runs active-active in two Azure regions. Each region has a set of Container Apps with Dapr. For state, they use Azure Cosmos DB with multi-region writes. Dapr's state management API abstracts the regional endpoint. For pub/sub, they use Azure Service Bus with geo-replication. Dapr's sidecar automatically routes messages to the local broker. When a region fails, Dapr's service invocation retries with a different region via the name resolution component. However, Dapr does not handle cross-region failover automatically; the application must implement a retry with a different target ID. The exam may test that Dapr is not a full disaster recovery solution.
What AZ-204 Tests on Dapr with Container Apps The exam objective 1.2 includes 'Implement Dapr with Azure Container Apps'. Questions typically focus on:
Understanding Dapr's role as a sidecar for abstraction
Configuring Dapr in Container Apps (CLI commands, parameters)
Identifying which Dapr building block to use for a given scenario (e.g., state, pub/sub, secrets)
Recognizing that Dapr does not replace underlying services
Knowing the default ports (3500 HTTP, 50001 gRPC)
Understanding that Dapr is open-source
Common Wrong Answers and Why Candidates Choose Them 1. 'Dapr replaces Azure Service Bus' – Wrong. Dapr uses Service Bus as a component; it does not replace it. Candidates see 'pub/sub' and think Dapr is a broker itself. 2. 'Dapr runs as a separate deployment' – Wrong. Dapr runs as a sidecar in the same pod. Candidates confuse it with a separate service like an API gateway. 3. 'Dapr requires Kubernetes' – Wrong. Dapr works on any platform; Azure Container Apps is not Kubernetes, even though it's built on it. 4. 'Dapr is only for state management' – Wrong. Dapr provides multiple building blocks. Candidates may only remember state.
Specific Numbers and Terms That Appear on Exam - Default Dapr HTTP port: 3500 - Default Dapr gRPC port: 50001 - Dapr application ID is required - Dapr sidecar resource limits: 0.5 CPU, 50 MB memory (default) - Dapr version 1.10+ supported in Container Apps - Component types: state.redis, pubsub.servicebus, secretstores.azurekeyvault
Edge Cases and Exceptions
- If you don't specify a Dapr application port, Dapr assumes 80. If your app listens on 8080, invocation fails.
- Dapr does not support all component versions; e.g., state.azurecosmosdb requires specific API version.
- When using Actors, you must enable the placement service; in Container Apps, this is automatic but you must set --dapr-app-protocol correctly.
- Dapr sidecar logs are separate from application logs; you must query both to debug.
How to Eliminate Wrong Answers - If the question asks for 'abstraction layer', think Dapr. - If the question mentions 'sidecar', think Dapr. - If the question lists multiple Azure services (Cosmos DB, Service Bus, Key Vault) and asks for a unified API, think Dapr. - Eliminate answers that claim Dapr replaces infrastructure; Dapr always works with existing services.
Dapr is an open-source, CNCF-graduated runtime that runs as a sidecar alongside microservices.
In Azure Container Apps, Dapr is enabled via `--enable-dapr` and configured with an app ID and port.
Default Dapr HTTP port is 3500; default gRPC port is 50001.
Dapr building blocks include state management, service invocation, pub/sub, bindings, actors, secrets, configuration, and observability.
Dapr does not replace underlying services like Azure Service Bus or Cosmos DB; it abstracts them.
Dapr sidecar uses 0.5 CPU and 50 MB memory by default (configurable).
Dapr supports both HTTP and gRPC protocols for sidecar communication.
Dapr Actors require a placement service; in Container Apps, it's managed automatically.
Dapr components are configured via YAML or Azure CLI in Container Apps.
Dapr provides at-least-once delivery for pub/sub by default; exactly-once requires idempotent consumers.
These come up on the exam all the time. Here's how to tell them apart.
Dapr
Abstraction layer: same API for different backends (e.g., Redis vs Cosmos DB).
Sidecar pattern: no code changes needed to switch backends.
Supports multiple building blocks beyond state (pub/sub, actors, etc.).
Open-source, portable across clouds and on-premises.
Built-in retries, observability, and mTLS.
Azure SDK Direct Usage
Tightly coupled to specific SDK (e.g., Azure.Storage.Blobs).
Requires code changes to switch backends.
Only provides the functionality you code (e.g., no built-in pub/sub abstraction).
Vendor-specific; porting requires rewriting.
You must implement retries, logging, and security yourself.
Mistake
Dapr is a Microsoft-only product.
Correct
Dapr is an open-source project under the CNCF (Cloud Native Computing Foundation). Microsoft is a major contributor, but it is not proprietary.
Mistake
Dapr runs as a separate service in a different pod.
Correct
Dapr runs as a sidecar container in the same pod as the application container. It shares the pod's network namespace, so it can communicate via localhost.
Mistake
Dapr replaces the need for Azure Service Bus or Cosmos DB.
Correct
Dapr provides an abstraction layer but still requires the underlying service. For example, Dapr pub/sub uses Azure Service Bus as a message broker; you must still create the Service Bus namespace.
Mistake
Dapr only works with HTTP.
Correct
Dapr supports both HTTP and gRPC. The default protocol is HTTP, but you can configure it to use gRPC for better performance.
Mistake
Dapr is only for state management.
Correct
Dapr provides multiple building blocks including service invocation, pub/sub, bindings, actors, secrets, configuration, and observability.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Dapr (Distributed Application Runtime) is an open-source sidecar runtime that provides building blocks for microservices, such as state management, service invocation, and pub/sub. In Azure Container Apps, Dapr runs as a sidecar container in the same pod as your application, intercepting API calls on localhost (default port 3500 HTTP, 50001 gRPC). You enable Dapr when creating the Container App using `--enable-dapr` and specify an application ID. Dapr components (e.g., state stores, pub/sub brokers) are configured separately and referenced by the sidecar. This abstraction allows you to change backends without code changes.
First, ensure you have a Redis instance (e.g., Azure Cache for Redis). Then, use the Azure CLI to add a Dapr component: `az containerapp dapr component set --name statestore --resource-group my-rg --environment my-env --component-type state.redis --version v1 --metadata "redisHost=myredis.redis.cache.windows.net:6380" "redisPassword=..."`. Replace the host and password with your Redis details. Your application can then access the state store via Dapr API: POST to `http://localhost:3500/v1.0/state/statestore`.
Dapr is a runtime that provides an abstraction layer for pub/sub messaging, among other building blocks. Azure Service Bus is a fully managed message broker. Dapr uses Service Bus as a component to implement pub/sub; you still need a Service Bus namespace. Dapr simplifies the code by providing a consistent API, but it does not replace the broker itself. The exam may test that Dapr is not a message broker but a runtime that works with one.
Yes, Dapr can run on any platform: Kubernetes, VMs, or even on-premises. Azure Container Apps provides built-in support for Dapr, making it easy to enable and configure. But Dapr itself is platform-agnostic. The exam focuses on the integration with Container Apps, but you should know that Dapr is not exclusive to Azure.
Dapr building blocks are APIs that provide common microservices patterns. The main ones are: State Management (store and retrieve key-value data), Service Invocation (call other services via HTTP/gRPC), Pub/Sub (publish and subscribe to messages), Bindings (trigger from or send to external systems), Actors (virtual actors pattern), Secrets (retrieve secrets from stores), Configuration (retrieve configuration items), and Observability (metrics, logs, and traces). Each building block can be backed by various components.
In Azure Container Apps, Dapr uses the environment's internal DNS for service discovery. When you invoke a service by its Dapr application ID, the sidecar resolves the target using DNS. The target service must have Dapr enabled and the same app ID. The resolution is cached for 30 seconds by default. If the target is not found, Dapr returns an error.
The default HTTP client timeout in Dapr is 30 seconds. This can be configured via the `--dapr-http-read-buffer-size` parameter (though that's for buffer size, not timeout). For gRPC, the default timeout is 60 seconds. The sidecar also has retry policies with exponential backoff (initial delay 1 second, max 60 seconds).
You've just covered Dapr with Azure Container Apps — now see how well it sticks with free AZ-204 practice questions. Full explanations included, no account needed.
Done with this chapter?