Pular para o conteúdo principal

Laboratório Técnico: Manage sizing and scaling for containers, including Azure Container Instances and Azure Container Apps

Questões​

Questão 1 — Múltipla Escolha​

Uma equipe precisa executar um job de processamento em lote que deve rodar até sua conclusão e encerrar automaticamente. O workload é stateless, dura cerca de 40 minutos e não requer orquestração contínua. Qual comportamento de restart policy do Azure Container Instances é o mais adequado para esse cenário?

A) Always, pois garante que o container seja reiniciado em caso de falha durante o processamento.

B) Never, pois impede qualquer reinicialização e encerra o container ao término da execução.

C) OnFailure, pois reinicia o container apenas se ele terminar com código de saída diferente de zero.

D) Always, pois é o padrão e garante alta disponibilidade para workloads de longa duração.

Questão 2 — Cenário Técnico​

Um desenvolvedor implantou uma aplicação no Azure Container Apps com a seguinte configuração de escalonamento:

{
  "scale": {
    "minReplicas": 0,
    "maxReplicas": 5,
    "rules": [
      {
        "name": "http-rule",
        "http": {
          "metadata": {
            "concurrentRequests": "10"
          }
        }
      }
    ]
  }
}

Durante horários de baixo tráfego, a aplicação some completamente do ambiente e novas requisições demoram vários segundos para serem atendidas. Qual é a causa direta desse comportamento?

A) O valor de concurrentRequests está baixo demais, forçando o escalonamento para zero prematuramente.

B) minReplicas: 0 permite que o ambiente reduza a contagem de réplicas a zero quando não há tráfego, causando cold start nas primeiras requisições.

C) O Azure Container Apps não suporta escalonamento baseado em HTTP; é necessário usar uma regra KEDA customizada.

D) maxReplicas: 5 é insuficiente e causa throttling, que o ambiente interpreta como ausência de demanda.

Questão 3 — Verdadeiro ou Falso​

No Azure Container Instances, é possível alterar o número de CPUs e a quantidade de memória de um container group já implantado por meio de uma operação de atualização in-place, sem necessidade de recriar o recurso.

Questão 4 — Cenário Técnico​

Uma aplicação implantada no Azure Container Apps processa mensagens de uma fila do Azure Service Bus. A equipe configurou uma regra de escalonamento baseada em KEDA para essa fila. Durante testes de carga, observou-se que novas réplicas são criadas corretamente, mas o número de réplicas nunca ultrapassa 3, mesmo com centenas de mensagens pendentes.

Qual é a causa mais provável desse comportamento?

A) O KEDA não é compatível com Azure Service Bus no Azure Container Apps; o escalonamento baseado em fila requer o uso de Azure Event Hubs.

B) O ambiente do Container Apps atingiu o limite de recursos do plano de consumo, impedindo novas réplicas.

C) O valor de maxReplicas na configuração de escalonamento está definido como 3, limitando o número máximo de instâncias.

D) A regra KEDA está configurada com messageCount em vez de queueLength, o que impede a leitura correta da métrica.

Questão 5 — Múltipla Escolha​

Ao comparar o modelo de escalonamento do Azure Container Instances com o do Azure Container Apps, qual afirmação descreve corretamente uma diferença fundamental entre os dois serviços?

A) O Azure Container Instances suporta escalonamento automático horizontal nativo, enquanto o Azure Container Apps exige configuração manual de réplicas.

B) O Azure Container Apps oferece escalonamento automático horizontal com suporte a KEDA, enquanto o Azure Container Instances não possui escalonamento automático nativo.

C) Ambos os serviços suportam escalonamento automático horizontal, mas o Azure Container Instances utiliza KEDA e o Container Apps utiliza métricas do Azure Monitor.

D) O Azure Container Instances escala verticalmente de forma automática com base na carga da CPU, enquanto o Container Apps escala apenas horizontalmente.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: C

A política OnFailure reinicia o container somente quando ele encerra com um código de saída diferente de zero, ou seja, em caso de erro. Para um job de processamento em lote que deve rodar até o fim e encerrar normalmente, esse comportamento é o correto: se a execução for bem-sucedida, o container para; se falhar, ele tenta novamente.

A alternativa Never eliminaria a possibilidade de retry em caso de falha intermediária, o que é inadequado para jobs onde a resiliência mínima é desejável. A política Always manteria o container reiniciando indefinidamente após a conclusão bem-sucedida, consumindo recursos desnecessários e nunca encerrando o job conforme esperado.

Gabarito — Questão 2​

Resposta: B

Quando minReplicas é definido como 0, o Azure Container Apps permite que o ambiente reduza a zero o número de réplicas ativas durante períodos sem tráfego. Ao receber uma nova requisição, o ambiente precisa provisionar uma réplica do zero, o que gera o cold start observado como latência inicial elevada.

Esse comportamento é intencional e útil para reduzir custos, mas tem como trade-off a latência nas primeiras requisições. A solução para ambientes que não toleram cold start é definir minReplicas como pelo menos 1. O valor de concurrentRequests controla apenas quando novas réplicas são adicionadas durante escalonamento, não o scale-to-zero.

Gabarito — Questão 3​

Resposta: Falso

O Azure Container Instances não suporta atualização in-place de recursos de CPU e memória de um container group já implantado. Alterações nesses parâmetros exigem a exclusão e recriação do container group. Isso é uma limitação arquitetural relevante do serviço, que o diferencia de plataformas com suporte a mutação de recursos em execução. Planejar o sizing inicial corretamente é essencial, pois ajustes posteriores implicam downtime do container group.

Gabarito — Questão 4​

Resposta: C

O parâmetro maxReplicas define o teto absoluto de instâncias que o Azure Container Apps pode provisionar para uma revisão, independentemente da demanda. Se esse valor estiver configurado como 3, o escalonador nunca criará uma quarta réplica, mesmo com centenas de mensagens pendentes na fila.

Esse é um erro de configuração comum: a regra KEDA pode estar corretamente definida para reagir à fila, mas o maxReplicas atua como limitador rígido acima da lógica do KEDA. A compatibilidade entre KEDA e Azure Service Bus no Container Apps é nativa e bem suportada, tornando as alternativas A e D incorretas. O limite de recursos do plano de consumo (alternativa B) produziria um comportamento diferente, geralmente com erro de provisionamento, não um limite silencioso em 3 réplicas.

Gabarito — Questão 5​

Resposta: B

O Azure Container Apps é projetado para workloads que exigem escalonamento dinâmico, utilizando o KEDA (Kubernetes Event-Driven Autoscaling) como motor de escalonamento horizontal, com suporte a múltiplas fontes de eventos como filas, tópicos, métricas HTTP e outras.

O Azure Container Instances, por sua vez, é um serviço de execução de containers sob demanda sem escalonamento automático horizontal nativo. Cada container group é uma unidade isolada; para escalar horizontalmente no ACI, é necessário provisionar múltiplos container groups por mecanismos externos (como Azure Logic Apps, scripts ou integrações com AKS). Confundir os modelos de escalonamento dos dois serviços é um erro conceitual frequente na preparação para o AZ-104.