You have two microservices in Azure Container Apps: service-a and service-b. You want service-a to call service-b without hardcoding IPs and to benefit from retries/timeouts. You also need to persist shopping cart state using a managed backend without writing storage SDK code. Which two actions should you take?

The correct actions leverage Dapr's capabilities within Azure Container Apps. Dapr (Distributed Application Runtime) provides building blocks for microservices. Enabling Dapr on both Container Apps and using http://localhost:3500/v1.0/invoke/service-b/method/{endpoint} allows service-a to call service-b via Dapr's service invocation building block. This provides service discovery, retries, and timeouts without hardcoding IPs or implementing these features manually. Creating a Dapr state component backed by Azure Cosmos DB and using the Dapr state HTTP API (http://localhost:3500/v1.0/state/{componentname}) allows service-a to persist shopping cart state without writing specific storage SDK code. Dapr abstracts the underlying state store. Routing through Azure Front Door is for global traffic management and security, not inter-service communication within the same environment, and client session cookies are not a robust or scalable state persistence solution for microservices. Mounting Azure Files requires managing file I/O and parsing, which is not "without writing storage SDK code" and is less performant for structured state than a dedicated state store.