Pular para o conteúdo principal

Laboratório Técnico: Provision a container by using Azure Container Instances

Questões​

Questão 1 — Múltipla Escolha​

Você precisa implantar um contêiner no Azure Container Instances que deve se comunicar com outros contêineres do mesmo grupo, compartilhando endereço IP e ciclo de vida. Qual é o mecanismo correto para isso?

A) Criar instâncias separadas de ACI e conectá-las via Azure Virtual Network com peering configurado.

B) Definir múltiplos contêineres dentro do mesmo container group, que compartilham o mesmo endereço IP e namespace de rede.

C) Usar um Azure Container App para orquestrar os contêineres, pois o ACI não suporta múltiplos contêineres por instância.

D) Configurar um sidecar como serviço separado no ACI e expor a comunicação via Azure Load Balancer interno.

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

Um desenvolvedor executou o seguinte comando para implantar um contêiner:

az container create \
  --resource-group rg-producao \
  --name meu-app \
  --image meuregistry.azurecr.io/app:v1 \
  --cpu 1 \
  --memory 1.5 \
  --restart-policy OnFailure

Após a execução, o contêiner não inicia e o log de eventos indica falha de autenticação ao tentar baixar a imagem. Qual é a causa mais provável e a correção adequada?

A) A política OnFailure impede a execução inicial; deve-se usar Always.

B) O parâmetro --memory 1.5 é inválido para a região selecionada; deve-se usar um valor inteiro.

C) O comando não incluiu credenciais para o Azure Container Registry; é necessário adicionar --registry-login-server, --registry-username e --registry-password (ou configurar a identidade gerenciada).

D) O ACI não suporta imagens hospedadas no Azure Container Registry; a imagem deve estar no Docker Hub.

Questão 3 — Verdadeiro ou Falso​

Um container group do Azure Container Instances implantado com o tipo de SO Windows pode incluir contêineres que executam imagens Linux no mesmo grupo, desde que cada contêiner declare seu próprio sistema operacional na definição YAML.

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

Você precisa implantar um contêiner que processa arquivos enviados por usuários. O contêiner deve ter acesso persistente a um diretório /dados, onde os arquivos sobrevivam ao reinício do contêiner. Você configurou o seguinte trecho em um arquivo YAML:

volumes:
  - name: dados-vol
    azureFile:
      shareName: arquivos
      storageAccountName: mystorageaccount
      storageAccountKey: <chave>
containers:
  - name: processador
    image: meuregistry.azurecr.io/processador:latest
    volumeMounts:
      - name: dados-vol
        mountPath: /dados

Ao aplicar o YAML, o volume não é montado corretamente. Qual é o erro mais provável nessa configuração?

A) O ACI não suporta montagem de volumes do tipo Azure Files; é necessário usar um Azure Blob Storage montado via blobfuse.

B) A chave da conta de armazenamento não pode ser fornecida diretamente no YAML; deve ser referenciada via Azure Key Vault.

C) A definição do volume está no nível correto, mas o volumeMounts deve estar dentro da seção properties do contêiner conforme o esquema do ACI, e um erro de estrutura YAML pode causar falha silenciosa na montagem.

D) O shareName deve corresponder ao nome do contêiner ACI; nomes diferentes causam falha na resolução do volume.

Questão 5 — Múltipla Escolha​

Ao comparar as opções de restart policy disponíveis no Azure Container Instances, qual combinação de comportamento é tecnicamente correta?

PolíticaComportamento
AlwaysReinicia o contêiner independentemente do código de saída
OnFailureReinicia apenas se o contêiner encerrar com código diferente de zero
NeverO contêiner executa uma vez e não é reiniciado em nenhum caso

A) A tabela está correta para todas as três políticas.

B) A tabela está errada apenas para OnFailure; essa política reinicia o contêiner independentemente do código de saída, assim como Always.

C) A tabela está errada apenas para Never; essa política ainda permite reinicialização se o contêiner falhar por erro de infraestrutura do Azure.

D) A tabela está errada para Always; essa política só se aplica a contêineres que não receberam um comando de encerramento explícito.

Gabarito e Explicações​

Gabarito — Questão 1​

Resposta: B

No Azure Container Instances, o container group é a unidade de implantação que agrupa múltiplos contêineres em um único host lógico. Contêineres dentro do mesmo group compartilham o endereço IP, as portas expostas e o ciclo de vida, comunicando-se entre si via localhost. Essa arquitetura é análoga ao conceito de Pod no Kubernetes.

As alternativas A e D representam o equívoco de tratar cada contêiner ACI como uma instância completamente isolada que precisaria de infraestrutura de rede externa para se comunicar. A alternativa C é incorreta porque o ACI suporta sim múltiplos contêineres por grupo; o Azure Container Apps é uma camada de abstração diferente, não um requisito para isso.

Gabarito — Questão 2​

Resposta: C

O Azure Container Registry é um registro privado. Ao usar o ACI para puxar uma imagem de um registro privado, é obrigatório fornecer credenciais de autenticação. O comando omitiu completamente os parâmetros --registry-login-server, --registry-username e --registry-password. Uma alternativa mais segura é atribuir uma identidade gerenciada ao container group e conceder a ela a role AcrPull no registro.

A alternativa A é incorreta porque a restart-policy não interfere no processo de pull da imagem. A alternativa B é incorreta porque o ACI aceita valores decimais para memória, como 1.5 GB. A alternativa D é factualmente errada; o ACI tem suporte nativo ao Azure Container Registry.

Gabarito — Questão 3​

Resposta: Falso

Um container group no ACI tem um único tipo de SO definido para todo o grupo. Não é possível misturar contêineres Linux e Windows dentro do mesmo group. Se o grupo for declarado como Windows, todos os contêineres devem executar imagens Windows. A tentativa de declarar o SO por contêiner individualmente no YAML não é suportada pela plataforma. Essa limitação é relevante em cenários de migração ou de implantação de sidecars que usam imagens de SO diferente.

Gabarito — Questão 4​

Resposta: C

O ACI suporta plenamente volumes do tipo Azure Files, portanto a alternativa A está errada. A alternativa D é incorreta; não há relação entre o shareName e o nome do contêiner ACI.

A alternativa B descreve uma boa prática de segurança, mas não é a causa de uma falha de montagem na configuração apresentada. O problema mais comum nesse cenário é um erro estrutural no arquivo YAML. No esquema do ACI, a seção volumeMounts deve estar aninhada corretamente dentro de properties do contêiner. Um desalinhamento de indentação ou posicionamento incorreto no YAML resulta em falha silenciosa de montagem, onde o contêiner inicia, mas o diretório /dados não está mapeado para o Azure Files. Revisar o esquema com az container create --help ou validar o YAML contra o schema ARM é a abordagem correta de diagnóstico.

Gabarito — Questão 5​

Resposta: A

A tabela está correta para as três políticas. Always é adequada para serviços de longa duração que devem permanecer em execução. OnFailure é ideal para tarefas em lote onde um encerramento com código zero indica sucesso e não exige reinicialização. Never é usada para cargas de trabalho de execução única onde qualquer reinicialização seria indesejada, como pipelines de processamento pontual.

Os distratores exploram a suspeita de que o comportamento real difere do documentado. A alternativa C representa um equívoco comum: falhas de infraestrutura do Azure (como realocação de host) são tratadas pela plataforma de forma transparente e não são expostas como evento de reinicialização ao nível da política do contêiner. A política Never se aplica ao comportamento do contêiner em si, não à disponibilidade da infraestrutura subjacente.