Laboratório Técnico: Provision a container by using Azure Container Apps
Questões
Questão 1 — Múltipla Escolha
Uma equipe precisa implantar uma aplicação que processa mensagens de uma fila do Azure Service Bus. O volume de mensagens varia muito ao longo do dia: praticamente zero durante a madrugada e picos intensos no horário comercial. A equipe quer que a infraestrutura escale automaticamente com base no número de mensagens na fila e não pague por recursos ociosos.
Qual recurso do Azure Container Apps atende diretamente a esse requisito?
A) Configurar réplicas mínimas e máximas no perfil de consumo do ambiente, usando HTTP scaling rules com threshold baseado em requisições por segundo.
B) Habilitar KEDA-based scaling rules apontando para o Azure Service Bus como fonte de eventos, com réplicas mínimas definidas como zero.
C) Usar um Dapr sidecar configurado com o componente pub/sub do Service Bus, que automaticamente ajusta o número de réplicas conforme a fila cresce.
D) Criar um Job no Container Apps com schedule trigger que verifica periodicamente o tamanho da fila e dispara novos contêineres conforme necessário.
Questão 2 — Cenário Técnico
Um desenvolvedor implantou um container app com o seguinte comando:
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
Após a implantação, o desenvolvedor verifica no portal que a aplicação está em execução, mas ao tentar acessar a URL pública retornada, recebe erro 404 Not Found. O contêiner está saudável e os logs não mostram erros da aplicação.
Qual é a causa mais provável do problema?
A) O parâmetro --ingress external exige que o ambiente do Container Apps seja criado com um Virtual Network dedicado; sem isso, o ingress externo não é provisionado.
B) O parâmetro --target-port 80 está incorreto porque o Container Apps reserva a porta 80 para uso interno; a aplicação deveria expor a porta 8080.
C) O contêiner foi implantado com sucesso, mas a revisão ativa ainda não recebeu tráfego porque o modo de revisão está configurado como multiple e nenhuma regra de tráfego foi definida para a nova revisão.
D) A imagem mcr.microsoft.com/azuredocs/containerapps-helloworld:latest não é compatível com o plano de consumo do Container Apps; é necessário usar o plano Dedicated para imagens do Microsoft Container Registry.
Questão 3 — Verdadeiro ou Falso
No Azure Container Apps, um ambiente (environment) pode hospedar aplicações que se comunicam entre si via nome de serviço interno, mas aplicações em ambientes diferentes não conseguem se comunicar diretamente, mesmo que ambos os ambientes estejam na mesma rede virtual e região.
Questão 4 — Cenário Técnico
Uma equipe de operações precisa implantar uma nova versão de um container app em produção com risco mínimo. O requisito é que apenas 10% do tráfego seja direcionado para a nova versão inicialmente, enquanto 90% continua na versão anterior. Se a nova versão se comportar bem após um período de observação, o tráfego será migrado completamente.
A equipe executa o deploy da nova imagem, mas após a implantação constata que 100% do tráfego foi imediatamente direcionado para a nova versão, ignorando a estratégia planejada.
Qual configuração estava ausente ou incorreta?
A) O health probe da nova revisão não foi configurado, então o Container Apps assumiu que ela estava pronta e migrou todo o tráfego automaticamente.
B) O modo de revisão do container app estava definido como single, que substitui a revisão ativa imediatamente; para controlar a divisão de tráfego, o modo deve ser multiple.
C) A nova imagem foi implantada sem a flag --no-wait, o que faz o CLI aguardar a revisão ficar saudável e então transferir todo o tráfego antes de retornar o controle.
D) A divisão de tráfego entre revisões só é suportada no plano Dedicated do Container Apps; no plano de consumo, o tráfego sempre vai integralmente para a revisão mais recente.
Questão 5 — Múltipla Escolha
Ao criar um ambiente do Azure Container Apps, qual é a diferença funcional mais relevante entre um ambiente criado sem uma rede virtual personalizada e um ambiente criado com uma rede virtual gerenciada pelo cliente?
A) Apenas ambientes com rede virtual personalizada suportam HTTPS com TLS personalizado; ambientes sem rede virtual usam exclusivamente certificados gerenciados pela Microsoft.
B) Ambientes sem rede virtual personalizada não suportam comunicação interna entre aplicações dentro do mesmo ambiente; essa funcionalidade exige VNet dedicada.
C) Apenas ambientes com rede virtual personalizada permitem que as aplicações acessem recursos privados dentro de uma VNet, como bancos de dados sem endpoint público; sem VNet, todo acesso é pela internet pública.
D) Ambientes com rede virtual personalizada desabilitam automaticamente o ingress externo para todas as aplicações hospedadas, forçando o uso de API Management como gateway de entrada.
Gabarito e Explicações
Gabarito — Questão 1
Resposta: B
O Azure Container Apps integra nativamente o KEDA (Kubernetes Event-Driven Autoscaler), que permite escalar com base em fontes de eventos externas como filas do Service Bus, Event Hubs, Storage Queues e outros. Definir réplicas mínimas como zero é essencial para que a aplicação escale para zero durante períodos sem mensagens, eliminando custos de recursos ociosos. Esse é exatamente o modelo recomendado para workloads orientadas a eventos.
O principal equívoco dos distratores é confundir mecanismos de escalonamento: o Dapr gerencia comunicação e acesso a componentes, mas não controla o número de réplicas. Jobs com schedule trigger são para execuções periódicas, não para escalonamento reativo. HTTP scaling rules são adequadas para APIs, não para processamento de filas.
Gabarito — Questão 2
Resposta: C
Quando o modo de revisão de um container app está configurado como multiple, novas revisões são implantadas mas não recebem tráfego automaticamente. O operador precisa configurar explicitamente as regras de distribuição de tráfego entre revisões. Se nenhuma regra for definida para a nova revisão, 0% do tráfego é roteado para ela, resultando em 404 ao tentar acessar a URL, pois a requisição não chega a nenhuma réplica ativa com tráfego habilitado.
Os outros distratores representam equívocos comuns: não há restrição de VNet para ingress externo em implantações básicas, a porta 80 é válida, e não existe incompatibilidade de imagem entre planos para imagens do MCR.
Gabarito — Questão 3
Falso
A afirmação é falsa. Ambientes diferentes são fronteiras de isolamento de rede no Container Apps: mesmo que estejam na mesma região e integrados à mesma VNet, aplicações em ambientes distintos não se comunicam via nome de serviço interno. A comunicação interna por DNS de serviço só existe dentro do mesmo ambiente. Para comunicação entre ambientes, é necessário usar endpoints externos ou configurar conectividade via VNet, o que aumenta a complexidade e não é o comportamento padrão esperado. Esse limite é frequentemente subestimado ao projetar arquiteturas com múltiplos ambientes.
Gabarito — Questão 4
Resposta: B
O comportamento descrito é exatamente o que acontece quando o modo de revisão está em single: cada novo deploy substitui imediatamente a revisão ativa anterior, e 100% do tráfego é transferido para a nova revisão sem possibilidade de divisão gradual. Para implementar estratégias como canary release ou blue/green, o modo deve ser configurado como multiple, que permite manter múltiplas revisões ativas simultaneamente e controlar explicitamente a porcentagem de tráfego de cada uma.
A ausência de health probe não interfere no roteamento de tráfego. A flag --no-wait afeta apenas o comportamento do CLI, não a lógica de tráfego. A divisão de tráfego entre revisões é suportada em todos os planos do Container Apps.
Gabarito — Questão 5
Resposta: C
A diferença funcional mais relevante é o acesso a recursos privados dentro de uma VNet. Sem uma rede virtual personalizada, as aplicações no Container Apps não têm como alcançar recursos sem endpoint público, como instâncias de banco de dados com acesso restrito à VNet, servidores internos ou endpoints privados. Com uma VNet gerenciada pelo cliente, as aplicações são implantadas em subnets dessa VNet e herdam sua conectividade privada.
Os outros distratores invertem comportamentos reais: TLS personalizado não exige VNet, comunicação interna entre apps no mesmo ambiente funciona independentemente de VNet, e VNet personalizada não desabilita ingress externo automaticamente. O ambiente pode ter ingress externo habilitado mesmo com VNet personalizada, desde que a subnet tenha acesso à internet.