Laboratório Técnico: Create and manage an Azure Container Registry
Questões
Questão 1 — Múltipla Escolha
Você precisa garantir que apenas serviços rodando em uma rede virtual específica consigam fazer pull de imagens de um Azure Container Registry. Qual configuração atende a esse requisito?
A) Habilitar o Public network access para "Selected networks" e associar a sub-rede desejada via Service Endpoint
B) Configurar um Private Endpoint e desabilitar o acesso público, mantendo o DNS padrão do registry
C) Definir a SKU como Premium e habilitar a opção "Allow trusted Microsoft services"
D) Criar uma regra de firewall com o intervalo de IP da sub-rede no painel de Networking do registry
Questão 2 — Cenário Técnico
Um pipeline de CI/CD executa o seguinte comando com sucesso:
az acr build --registry meuregistry --image app:v1 .
Na sequência, a equipe tenta executar:
docker pull meuregistry.azurecr.io/app:v1
O comando falha com erro de autenticação, mesmo com o Docker instalado e o usuário com acesso à assinatura Azure. Qual é a causa mais provável?
A) O comando az acr build armazena a imagem em cache temporário e ela não foi promovida ao repositório
B) A SKU Basic do registry não suporta pull externo via Docker CLI
C) O Docker local não está autenticado no registry; é necessário executar az acr login antes do pull
D) O usuário precisa da role AcrPush atribuída explicitamente para realizar pulls
Questão 3 — Verdadeiro ou Falso
A replicação geográfica de um Azure Container Registry, disponível na SKU Premium, garante automaticamente que todas as regiões replicadas recebam novas imagens sem nenhuma configuração adicional de webhook ou pipeline.
Questão 4 — Cenário Técnico
Uma equipe configura o seguinte no registry:
{
"quarantinePolicy": { "status": "enabled" },
"retentionPolicy": { "days": 7, "status": "enabled" },
"trustPolicy": { "type": "Notary", "status": "enabled" }
}
Após o push de uma nova imagem, ela não aparece disponível para pull imediatamente. O que explica esse comportamento?
A) A retention policy retém imagens recentes por 7 dias antes de liberá-las
B) A quarantine policy coloca imagens recém-enviadas em quarentena até que uma verificação de segurança as libere
C) A trust policy exige que a imagem seja assinada digitalmente antes de qualquer pull ser permitido
D) O registry requer um webhook de aprovação manual vinculado ao Microsoft Defender for Containers
Questão 5 — Múltipla Escolha
Ao comparar as SKUs do Azure Container Registry, qual afirmação descreve corretamente uma diferença funcional entre Basic e Premium?
A) Apenas a SKU Premium permite o uso de az acr build para builds no lado do servidor
B) Apenas a SKU Premium suporta replicação geográfica e acesso com Private Endpoint
C) A SKU Basic não oferece integração com Microsoft Entra ID para autenticação
D) A SKU Standard e a Premium têm limites idênticos de armazenamento e throughput
Gabarito e Explicações
Gabarito — Questão 1
Resposta: A
Restringir acesso a uma rede virtual específica é feito via Service Endpoint com a opção "Selected networks" no painel de Networking do registry. Essa configuração permite que apenas tráfego originado da sub-rede associada alcance o registry, sem expô-lo publicamente.
A alternativa B é plausível, mas incompleta como única resposta: um Private Endpoint isola o acesso via IP privado, porém o DNS padrão (*.azurecr.io) continuaria resolvendo para o endereço público, quebrando a conectividade. A configuração correta de DNS privado seria necessária.
A alternativa C (trusted Microsoft services) libera serviços Azure de primeiro partido como Azure Pipelines, não redes virtuais arbitrárias. A alternativa D, regra de firewall por IP, funciona para IPs públicos conhecidos, não para sub-redes de VNet de forma nativa e gerenciável.
Gabarito — Questão 2
Resposta: C
O comando az acr build usa uma identidade gerenciada da Azure CLI para enviar o contexto de build e armazenar a imagem, mas isso não autentica o daemon Docker local. Para que o Docker CLI possa interagir com o registry, é necessário executar az acr login --name meuregistry, que obtém um token temporário e configura o Docker localmente.
A alternativa A é um equívoco comum: az acr build de fato armazena a imagem no repositório do registry, não em cache temporário. A alternativa B é falsa; todas as SKUs suportam pull externo. A alternativa D confunde as roles: AcrPull é a role necessária para pull, e AcrPush é para push. O erro aqui, porém, é de autenticação, não de autorização.
Gabarito — Questão 3
Resposta: Verdadeiro
A replicação geográfica da SKU Premium é gerenciada automaticamente pelo Azure. Ao habilitar uma replicação para uma região adicional, o registry passa a sincronizar imagens para essa região sem que o operador precise configurar pipelines, webhooks de cópia ou tarefas adicionais. O Azure garante a consistência eventual das imagens entre todas as réplicas.
O ponto de atenção é que webhooks podem ser configurados opcionalmente por região para notificações de eventos, mas não são necessários para que a replicação ocorra. Confundir webhooks de notificação com mecanismo de replicação é um erro conceitual frequente neste tema.
Gabarito — Questão 4
Resposta: B
A quarantine policy, quando habilitada, coloca automaticamente toda imagem recém-enviada em estado de quarentena. A imagem só fica disponível para pull após ser explicitamente liberada, tipicamente por uma ferramenta de varredura de vulnerabilidades integrada ao fluxo, como o Microsoft Defender for Containers ou uma solução terceira via API.
A alternativa A representa um equívoco sobre a retention policy: ela define por quantos dias imagens sem tags (untagged) são mantidas antes de serem excluídas, não um período de carência antes da disponibilização. A alternativa C é parcialmente verdadeira em termos de assinatura de conteúdo, mas a trust policy bloqueia pulls de imagens não assinadas, não impede a visualização imediata de imagens enviadas. A alternativa D não existe como mecanismo nativo do registry.
Gabarito — Questão 5
Resposta: B
A SKU Premium é a única que oferece suporte a replicação geográfica (geo-replication) e a integração com Private Endpoint para acesso via rede privada. Essas são capacidades exclusivas dessa camada e são frequentemente exigidas em cenários enterprise.
A alternativa A é falsa: az acr build está disponível em todas as SKUs, pois é uma funcionalidade de execução de tarefas no servidor, independente da camada. A alternativa C é falsa: todas as SKUs se integram com Microsoft Entra ID para autenticação. A alternativa D é incorreta: Standard e Premium diferem em limites de armazenamento incluído, throughput e funcionalidades como replicação, sendo a Premium substancialmente superior.