A municipal newsroom’s microservices on Azure Container Apps need service invocation and pub/sub without each team writing a custom HTTP client mesh. What is the appropriate way to add those building blocks?
Select an answer to reveal the explanation.
Short Explanation
Dapr on Container Apps is like plugging a shared intercom into each apartment instead of every neighbor wiring their own phones. You flip on the sidecar features for invocation and pub/sub—you do not rebuild the whole block as AKS just to get the intercom.
Full Explanation
Dapr is available as an optional sidecar integration on Azure Container Apps. Enabling it gives municipal newsroom microservices service invocation and pub/sub building blocks without each team writing a custom HTTP client mesh—like plugging a shared intercom into each apartment instead of wiring private phones.
Installing an AKS cluster, deploying Dapr operators cluster-wide, and migrating every Container App onto Kubernetes pods abandons the managed Container Apps path for an unnecessary platform rewrite. Replacing Container Apps with Logic Apps connectors because “Dapr is not supported outside AKS” is false for Container Apps’ documented Dapr integration. Adding Redis only as an in-process cache library is caching, not the official service-invocation and pub/sub fabric Dapr provides.
Exam caveat: Dapr components and scopes still sit inside the Container Apps environment boundary. Enabling Dapr does not by itself make cross-environment invocation safe; keep untrusted apps out of the production environment.
Operational check: enable Dapr on two trusted apps in the same environment, invoke one from the other via the Dapr service-invocation API, publish a test message through a Dapr pub/sub component, and confirm neither team needed a hand-rolled mesh client.