AZ-204 Develop Azure compute solutions Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable external ingress at the environment level and use network policies to restrict access.

  Why it's wrong here

  Enabling external ingress at the environment level in Azure Container Apps would expose *all* container apps within that environment to public internet traffic by default, which is not the desired behavior for services intended to be internal. Furthermore, Azure Container Apps does not currently support the application of granular network policies, such as Network Security Groups or Azure Firewall rules, directly to individual container app ingress to selectively restrict access when environment-level ingress is enabled. This approach lacks the fine-grained control necessary for a mixed external and internal access scenario.

• ✗

  Deploy the external service in a different environment and use an internal load balancer.

  Why it's wrong here

  Deploying services requiring different ingress types into separate Azure Container Apps environments introduces unnecessary operational overhead and management complexity. While technically feasible, it would necessitate configuring cross-environment communication, potentially involving an internal load balancer or VNet peering, which complicates networking and service discovery. Azure Container Apps is specifically designed to efficiently host both externally and internally accessible services within a single environment, simplifying the overall architecture and reducing management burden.

• ✓

  Configure each container app's ingress: set the external service to 'External' and the internal services to 'Internal'.

  Why this is correct

  Azure Container Apps provides granular control over ingress at the individual container app level, making this the correct and most efficient solution. For the external service, configuring its ingress as 'External' makes it publicly accessible via a fully qualified domain name (FQDN) generated by the platform. Conversely, setting the ingress for internal services to 'Internal' ensures they are only reachable by other container apps within the same environment, or via VNet integration, without exposing them to the public internet. This approach directly addresses the requirement for mixed external and internal access within a single, unified environment.

• ✗

  Use a Dapr sidecar to route requests between services.

  Why it's wrong here

  Dapr (Distributed Application Runtime) sidecars are designed to provide common capabilities for microservices, such as service invocation, state management, and pub/sub messaging, primarily facilitating communication *between* services. While Dapr can enhance service-to-service communication within an environment, it does not directly manage or configure the external or internal ingress settings for a container app itself. Dapr operates at the application layer, whereas ingress configuration is a platform-level networking concern for exposing or restricting access to the application from outside the container app.

Go deeper

Related to this question