Dapr provides portable building blocks for distributed applications. These exercises cover Dapr's pub/sub messaging, virtual actor model, service invocation, and secrets management — the core abstractions for building cloud-native microservices with Dapr.
0 / 5 completed
1 / 5
At standup, a colleague asks what Pub/Sub components in Dapr do. What is the correct answer?
Dapr Pub/Sub components provide a portable messaging API. Your application publishes messages to a topic via the Dapr sidecar HTTP/gRPC API, and subscribes by declaring topic subscriptions. The actual message broker — Kafka, Redis, RabbitMQ, Azure Service Bus, etc. — is configured as a component YAML and can be swapped without changing application code. This portability is a core Dapr value proposition.
2 / 5
During a PR review, a teammate asks what actor state in Dapr provides. Which answer is correct?
Dapr actor state gives each actor instance its own isolated key-value store. State operations go through the Dapr sidecar, which persists them to the configured state store component (Redis, Azure CosmosDB, PostgreSQL, etc.). Because Dapr manages state serialisation and persistence, actors can be deactivated and reactivated transparently — their state is restored from the store when the actor is next invoked.
3 / 5
In a design review, the team discusses actor reminders in Dapr. A junior engineer asks how they differ from actor timers. What is correct?
The key difference is durability. Dapr actor reminders are persisted to the state store and survive actor deactivation, host restarts, and crashes — they will fire even if the actor was dormant. Timers are in-memory and are lost if the actor is deactivated or the host restarts. For production scheduled tasks (payment retries, scheduled notifications), always use reminders. Use timers only for transient in-session scheduling.
4 / 5
An incident report shows a service failing to call another service by hostname. A senior engineer asks how service invocation works in Dapr. What is correct?
Dapr service invocation routes calls through the local Dapr sidecar using the app ID as the address. The call goes to http://localhost:{dapr-port}/v1.0/invoke/{app-id}/method/{method}, and the Dapr sidecar performs service discovery (via Dapr's name resolution component), adds mTLS encryption, automatic retries, distributed tracing, and load balancing. You never need to know the target service's actual hostname or port.
5 / 5
During a code review, a senior engineer asks what the Secrets API in Dapr provides. What is accurate?
Dapr's Secrets API provides a portable secret retrieval interface. Your application calls http://localhost:{dapr-port}/v1.0/secrets/{store-name}/{secret-name}, and the Dapr sidecar fetches the secret from the configured backend — whether that is AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, or Kubernetes Secrets. Switching the secret store only requires changing the component configuration, not application code.