Technical Lab: Provision a container by using Azure Container Apps
Questions
Question 1 — Multiple Choice
A team needs to deploy an application that processes messages from an Azure Service Bus queue. The message volume varies greatly throughout the day: practically zero during early morning hours and intense peaks during business hours. The team wants the infrastructure to automatically scale based on the number of messages in the queue and not pay for idle resources.
Which Azure Container Apps feature directly meets this requirement?
A) Configure minimum and maximum replicas in the environment's consumption profile, using HTTP scaling rules with a threshold based on requests per second.
B) Enable KEDA-based scaling rules pointing to Azure Service Bus as the event source, with minimum replicas set to zero.
C) Use a Dapr sidecar configured with the Service Bus pub/sub component, which automatically adjusts the number of replicas as the queue grows.
D) Create a Job in Container Apps with a schedule trigger that periodically checks the queue size and triggers new containers as needed.
Question 2 — Technical Scenario
A developer deployed a container app with the following command:
az containerapp create \
--name minha-api \
--resource-group rg-producao \
--environment meu-ambiente \
--image mcr.microsoft.com/azuredocs/containerapps-helloworld:latest \
--target-port 80 \
--ingress external \
--min-replicas 1 \
--max-replicas 5
After deployment, the developer verifies in the portal that the application is running, but when trying to access the returned public URL, receives a 404 Not Found error. The container is healthy and the logs show no application errors.
What is the most likely cause of the problem?
A) The --ingress external parameter requires that the Container Apps environment be created with a dedicated Virtual Network; without this, external ingress is not provisioned.
B) The --target-port 80 parameter is incorrect because Container Apps reserves port 80 for internal use; the application should expose port 8080.
C) The container was deployed successfully, but the active revision has not yet received traffic because the revision mode is configured as multiple and no traffic rule has been defined for the new revision.
D) The mcr.microsoft.com/azuredocs/containerapps-helloworld:latest image is not compatible with the Container Apps consumption plan; the Dedicated plan is required for Microsoft Container Registry images.
Question 3 — True or False
In Azure Container Apps, an environment can host applications that communicate with each other via internal service name, but applications in different environments cannot communicate directly, even if both environments are in the same virtual network and region.
Question 4 — Technical Scenario
An operations team needs to deploy a new version of a container app in production with minimal risk. The requirement is that only 10% of traffic be directed to the new version initially, while 90% continues to the previous version. If the new version behaves well after an observation period, traffic will be completely migrated.
The team executes the deployment of the new image, but after deployment finds that 100% of traffic was immediately directed to the new version, ignoring the planned strategy.
Which configuration was missing or incorrect?
A) The health probe for the new revision was not configured, so Container Apps assumed it was ready and migrated all traffic automatically.
B) The container app's revision mode was set to single, which immediately replaces the active revision; to control traffic splitting, the mode must be multiple.
C) The new image was deployed without the --no-wait flag, which makes the CLI wait for the revision to become healthy and then transfer all traffic before returning control.
D) Traffic splitting between revisions is only supported in Container Apps Dedicated plan; in the consumption plan, traffic always goes entirely to the most recent revision.
Question 5 — Multiple Choice
When creating an Azure Container Apps environment, what is the most relevant functional difference between an environment created without a custom virtual network and an environment created with a customer-managed virtual network?
A) Only environments with custom virtual network support HTTPS with custom TLS; environments without virtual network use exclusively Microsoft-managed certificates.
B) Environments without custom virtual network do not support internal communication between applications within the same environment; this functionality requires a dedicated VNet.
C) Only environments with custom virtual network allow applications to access private resources within a VNet, such as databases without public endpoints; without VNet, all access is through the public internet.
D) Environments with custom virtual network automatically disable external ingress for all hosted applications, forcing the use of API Management as the entry gateway.
Answer Key and Explanations
Answer Key — Question 1
Answer: B
Azure Container Apps natively integrates KEDA (Kubernetes Event-Driven Autoscaler), which allows scaling based on external event sources like Service Bus queues, Event Hubs, Storage Queues, and others. Setting minimum replicas to zero is essential for the application to scale to zero during periods without messages, eliminating costs of idle resources. This is exactly the recommended model for event-driven workloads.
The main misconception in the distractors is confusing scaling mechanisms: Dapr manages communication and access to components, but does not control the number of replicas. Jobs with schedule triggers are for periodic executions, not for reactive scaling. HTTP scaling rules are suitable for APIs, not for queue processing.
Answer Key — Question 2
Answer: C
When a container app's revision mode is configured as multiple, new revisions are deployed but do not automatically receive traffic. The operator needs to explicitly configure traffic distribution rules between revisions. If no rule is defined for the new revision, 0% of traffic is routed to it, resulting in 404 when trying to access the URL, as the request does not reach any active replica with traffic enabled.
The other distractors represent common misconceptions: there is no VNet restriction for external ingress in basic deployments, port 80 is valid, and there is no image incompatibility between plans for MCR images.
Answer Key — Question 3
False
The statement is false. Different environments are network isolation boundaries in Container Apps: even if they are in the same region and integrated into the same VNet, applications in different environments do not communicate via internal service name. Internal communication via service DNS only exists within the same environment. For communication between environments, external endpoints or VNet connectivity configuration is required, which increases complexity and is not the expected default behavior. This limitation is often underestimated when designing architectures with multiple environments.
Answer Key — Question 4
Answer: B
The described behavior is exactly what happens when the revision mode is in single: each new deployment immediately replaces the previous active revision, and 100% of traffic is transferred to the new revision without possibility of gradual splitting. To implement strategies like canary release or blue/green, the mode must be configured as multiple, which allows maintaining multiple active revisions simultaneously and explicitly controlling the percentage of traffic for each one.
The absence of health probe does not interfere with traffic routing. The --no-wait flag only affects CLI behavior, not traffic logic. Traffic splitting between revisions is supported in all Container Apps plans.
Answer Key — Question 5
Answer: C
The most relevant functional difference is access to private resources within a VNet. Without a custom virtual network, applications in Container Apps have no way to reach resources without public endpoints, such as database instances with VNet-restricted access, internal servers, or private endpoints. With a customer-managed VNet, applications are deployed in subnets of that VNet and inherit its private connectivity.
The other distractors invert real behaviors: custom TLS does not require VNet, internal communication between apps in the same environment works regardless of VNet, and custom VNet does not automatically disable external ingress. The environment can have external ingress enabled even with custom VNet, as long as the subnet has internet access.