Microsoft AZ-204: Soluções de Contêineres do Azure — Guia de estudos

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Azure oferece um espectro de opções de contêineres que abrangem desde a execução de contêineres únicos, clusters orquestrados, até uma cadeia de suprimentos de imagens segura e de nível empresarial. O Azure Container Instances (ACI) é o caminho mais rápido para executar contêineres Linux ou Windows sem gerenciar servidores. O Azure Kubernetes Service (AKS) é um plano de controle Kubernetes gerenciado que dimensiona microsserviços com agendamento avançado, rede, segurança e integrações de DevOps. O Azure Container Registry (ACR) é o registro privado e com replicação geográfica que ancora seus fluxos de build, tagueamento, push/pull e distribuição de Helm. Dominar a construção de imagens Docker e o gerenciamento do ciclo de vida é fundamental para implantações confiáveis em qualquer uma dessas plataformas. Esta seção estabelece uma visão prática e centrada no desenvolvedor de como as peças se encaixam, incluindo implantações orientadas por YAML, empacotamento com Helm, exposição de serviços e padrões de identidade/segurança.

Docker e Azure Container Registry (ACR)

A entrega confiável de contêineres começa com fundamentos sólidos de Docker. Cada imagem é composta por camadas formadas por instruções do Dockerfile; a reutilização de camadas e os acertos de cache (cache hits) são críticos para builds rápidos.

• Instruções comuns do Dockerfile e orientações:
  • FROM define a imagem base. Prefira imagens mínimas (por exemplo, distroless, alpine quando apropriado) para reduzir a superfície de ataque e o tamanho.
  • RUN executa comandos para instalar dependências. Combine comandos relacionados para reduzir o número de camadas, mas evite linhas RUN monolíticas que dificultam a identificação de falhas.
  • COPY e ADD inserem artefatos da aplicação. Use .dockerignore para evitar inchar os contextos; fixe o COPY em caminhos explícitos.
  • WORKDIR define o diretório de trabalho; use-o em vez de encadear cd no RUN.
  • EXPOSE documenta as portas de escuta pretendidas (não é um firewall).
  • ENV e ARG configuram variáveis de ambiente e de tempo de build; promova o determinismo do tempo de build fixando os padrões de ARG ou passando valores explícitos.
  • ENTRYPOINT define o executável principal; use CMD para argumentos padrão. Prefira a forma exec (array JSON) para preservar o tratamento de sinais para um desligamento gracioso (graceful shutdown).
  • HEALTHCHECK habilita a avaliação de liveness para que os orquestradores possam reagir.
• Builds de múltiplos estágios (multi-stage builds) separam os estágios de build e de tempo de execução, copiando apenas os artefatos necessários para uma imagem de tempo de execução limpa, reduzindo drasticamente o tamanho e a pegada de CVEs. Por exemplo, construa com o SDK, publique os binários e, em seguida, copie-os para uma base de tempo de execução.
• As camadas da imagem são imutáveis e endereçadas por conteúdo (content-addressed). Reordenar as instruções altera o cache. Coloque as instruções que mudam com frequência (por exemplo, a origem do COPY) no final do Dockerfile para maximizar os acertos de cache.

Com o ACR, armazene e distribua imagens e charts Helm de forma privada:

• Repositórios e tagueamento: Faça o push de imagens como <registry>.azurecr.io/<repo>:<tag>. Prefira tags semânticas ou baseadas em Git (por exemplo, 1.4.0, SHA do build) e use digests imutáveis em implantações de produção para repetibilidade.
• Push e pull:
  • Autentique-se no ACR usando az acr login -n <acr-name> ou docker login com um token do Azure AD. Evite habilitar o usuário administrador do ACR em produção.
  • Tagueie e faça o push: docker tag app:1.0 <acr>.azurecr.io/apps/app:1.0; docker push <acr>.azurecr.io/apps/app:1.0. Faça o pull com docker pull ou por meio de referências de imagem do Kubernetes.
  • Importe imagens upstream para o ACR para controlar a cadeia de suprimentos: az acr import -n <acr> –source docker.io/library/nginx:1.25 –image base/nginx:1.25.
• ACR Tasks: Construa, teste e aplique patches em imagens nativamente no Azure. Use az acr build -r <acr> -t apps/app:1.0 . para builds sob demanda; automatize atualizações com az acr task create para disparar a partir de commits do Git ou atualizações da imagem base, permitindo a remediação de CVEs sem alterar o código da aplicação.
• Replicação geográfica (SKU Premium) fornece localidade de pull multirregional e resiliência. Configure réplicas em regiões próximas aos clusters AKS para reduzir a latência de pull e o tráfego de saída (egress) entre regiões.
• Controle de acesso:
  • Integre com o Azure AD e atribua funções internas como AcrPull à identidade do kubelet do AKS, e AcrPush aos pipelines de CI. Permissões com escopo de repositório estão disponíveis por meio de tokens e mapas de escopo (scope maps) para um controle refinado.
  • Restrinja o acesso à rede com private endpoints, service endpoints e regras de firewall. Prefira private endpoints para produção.
  • Anexe o ACR ao AKS com az aks update –attach-acr <acr> para simplificar a atribuição da função AcrPull.

Azure Container Instances (ACI)

O ACI executa contêineres sob demanda sem o gerenciamento de um cluster. A unidade primária é um grupo de contêineres (container group), um conjunto de contêineres agendados em conjunto que compartilham o mesmo kernel do sistema operacional hospedeiro, ciclo de vida, IP e volumes. Use grupos de contêineres para implementar o padrão sidecar (por exemplo, coletores de log, proxies) ou para combinar um processo principal com um auxiliar (helper).

• Grupos de múltiplos contêineres compartilham um namespace de rede, permitindo a comunicação entre contêineres via localhost. Eles também compartilham volumes montados (Azure Files, emptyDir) e o ciclo de vida, tornando-os adequados para tarefas coesas e pontuais que exigem acoplamento forte.
• Políticas de reinicialização (restart policies) controlam a semântica de execução:
  • Always reinicia os contêineres quando eles terminam. Ideal para serviços de longa duração.
  • OnFailure reinicia apenas em códigos de saída diferentes de zero. Adequado para tarefas em lote (batch) que devem tentar novamente em caso de falha.
  • Never executa os contêineres uma vez e nunca os reinicia, ideal para jobs idempotentes.
• As integrações de rede incluem IP público com um rótulo DNS, IPs privados em uma sub-rede delegada da Azure VNet e saída (egress) segura via NAT ou firewall. O ACI injetado em uma VNet (VNet-injected) permite o acesso privado a serviços (bancos de dados, armazenamento) sem exposição pública.
• Considerações operacionais:
  • Injete segredos usando variáveis de ambiente seguras ou montando Azure Files; para uma postura mais forte, recupere segredos em tempo de execução via identidade gerenciada (managed identity) do Key Vault.
  • Observe com az container logs e az container attach; execute comandos interativos com az container exec.
  • O faturamento é por segundo para vCPU e GiB de memória. Os contêineres iniciam rapidamente e se encaixam em cargas de trabalho com picos de uso (bursty workloads), tarefas auxiliares de CI, testes de integração e jobs acionados por filas onde a sobrecarga (overhead) do Kubernetes é desnecessária.

Azure Kubernetes Service (AKS)

O AKS fornece um plano de controle gerenciado com pools de nós, autoescalonamento e opções avançadas de rede/identidade.

Pools de nós estruturam a capacidade e o posicionamento da carga de trabalho. Pools de nós do sistema executam serviços essenciais; pools de nós de usuário executam pods de aplicação. Use múltiplos pools para segregar cargas de trabalho por necessidades de CPU/Memória/GPU, SO (Linux/Windows), tamanho de VM e zona de disponibilidade. Empregue taints/tolerations para proteger pools do sistema, labels para seleção e o cluster autoscaler para adicionar/remover nós com base em pods pendentes. Considere o maxPods por nó e a densidade de pods ao dimensionar.

O agendamento de pods é orientado por requisições/limites de recursos, classes de QoS (Guaranteed/Burstable/BestEffort) e restrições. Use nodeSelector/afinidade e anti-afinidade para direcionar pods para os pools apropriados e distribuir réplicas entre zonas e domínios de falha. As restrições de distribuição de topologia (topology spread constraints) melhoram a distribuição uniforme. Para serviços críticos, defina PodDisruptionBudgets e PriorityClasses para moldar interrupções voluntárias e o comportamento de preempção. DaemonSets posicionam agentes por nó (logging, monitoramento), e CronJobs agendam contêineres para tarefas periódicas.

Deployments no AKS são declarativos. Manifestos YAML definem apiVersion, kind, metadata e spec para Deployments, StatefulSets, Jobs, Services e Ingress. Mantenha os manifestos em controle de versão, parametrize com overlays do Kustomize para diferenças de ambiente e aplique com kubectl apply -f. O server-side apply e labels/annotations adequados ajudam na identificação de propriedade e na detecção de desvio (drift). Para empacotar aplicações reutilizáveis, o Helm 3 agrupa templates e valores. Hospede charts do Helm como artefatos OCI no ACR e instale com helm upgrade –install <release> oci://<acr>.azurecr.io/helm/<chart> -f values.yaml. Use arquivos de valores (values) por ambiente, rastreie versões de chart e reverta com helm rollback para uma recuperação rápida.

Comandos kubectl que você usará diariamente:

• Acessar o contexto do cluster: az aks get-credentials -g <rg> -n <cluster> mescla o kubeconfig; usar uma máquina ingressada no Azure AD com o kubectl é suficiente — o Docker não é necessário para implantar manifestos.
• Inspecionar e operar: kubectl get nodes,pods,deploy,svc -A; kubectl describe pod <name>; kubectl logs -f <pod>; kubectl exec -it <pod> – sh; kubectl rollout status deploy/<name>; kubectl set image deploy/<name> container=<image>:<tag>; kubectl top pods; kubectl cordon/drain nodes para manutenção; kubectl auth can-i para verificar o RBAC.
• Aplicar/corrigir: kubectl apply -f k8s/; kubectl patch deploy <name> –type merge -p ‘{…}’.

A rede no AKS expõe pods e serviços com responsabilidades claras:

• ClusterIP fornece IPs virtuais e DNS internos, com escopo de cluster, para descoberta de serviços. Este é o padrão para o tráfego leste-oeste entre microsserviços.
• NodePort abre a mesma porta em cada nó; é melhor usado atrás de um Ingress ou LB externo do que consumido diretamente.
• LoadBalancer provisiona um frontend do Azure Load Balancer que tem como alvo os NodePorts. Marque os serviços como internos anotando service.beta.kubernetes.io/azure-load-balancer-internal: “true”, ou atribua um IP público estático para um DNS estável.
• Controladores de Ingress fornecem roteamento L7, terminação TLS e regras de caminho/host. O NGINX Ingress Controller é um padrão versátil com anotações ricas. O Application Gateway Ingress Controller (AGIC) se integra com o Azure Application Gateway para WAF, autoescalonamento e capacidades L7 empresariais, mantendo manifestos nativos do Kubernetes. Use o cert-manager para automatizar o TLS com ACME, ou sincronize certificados do Key Vault em segredos do Kubernetes com o CSI Secret Store.

A identidade e a autorização integram o Azure AD sem segredos dentro do cluster:

• Identidades gerenciadas para AKS consistem na identidade do cluster/plano de controle e na identidade do kubelet. Conceda a permissão AcrPull do ACR ao kubelet (az aks update –attach-acr <acr>) para que os nós possam puxar imagens de forma segura.
• A identidade de carga de trabalho (Workload identity) permite que os pods acessem recursos do Azure usando credenciais federadas do Azure AD mapeadas para contas de serviço do Kubernetes — sem credenciais no nível do nó ou sidecars. Habilite o emissor OIDC no cluster, crie uma identidade gerenciada atribuída pelo usuário, configure uma FederatedIdentityCredential para a conta de serviço/namespace e use o SDK do Azure Identity na aplicação. Isso substitui o modelo mais antigo AAD Pod Identity e se alinha com padrões abertos.
• O RBAC governa as permissões da API do Kubernetes. Vincule Roles/ClusterRoles do Kubernetes a usuários ou grupos do Azure AD por meio de RoleBindings/ClusterRoleBindings quando o AKS estiver integrado ao Azure AD. Alternativamente, habilite o Azure RBAC para Autorização do Kubernetes para gerenciar o acesso com papéis do Azure RBAC, como Azure Kubernetes Service RBAC Reader, Writer e Admin. Siga o princípio do menor privilégio, separe namespaces por equipe ou carga de trabalho e controle o acesso à produção por meio de vínculos baseados em grupos.

O fluxo de imagem de ponta a ponta para o AKS é direto e seguro. Construa imagens multi-stage, marque com versões imutáveis, envie para o ACR e implante no AKS com manifestos ou Helm. O AKS puxa do ACR usando a identidade gerenciada do kubelet, e os pods consomem recursos do Azure via workload identity. Os serviços são expostos via ClusterIP/LoadBalancer e refinados com um controlador de ingress que centraliza o TLS e o roteamento.

Cenário de Problema Prático

A equipe do Creative Cloud da Adobe está decompondo um serviço monolítico de processamento de mídia em microsserviços, visando entrega global de baixa latência e uma cadeia de suprimentos (supply chain) fortalecida.

1. Construir e armazenar imagens usando Dockerfiles multi-stage em CI

• Use o Docker multi-stage para compilar codecs de mídia e copiar apenas os binários de tempo de execução para uma imagem base enxuta, minimizando o tamanho e as CVEs. Envie as imagens como <acr>.azurecr.io/processing/encoder:<git-sha> para o ACR. Isso garante artefatos reproduzíveis e seguros com digests imutáveis para fixação (pinning) no deploy.

2. Fortalecer o registro e automatizar a aplicação de patches

• Crie um registro ACR Premium com endpoints privados em cada rede virtual que hospeda o AKS. Habilite a georreplicação para o Norte da Europa e Leste dos EUA para manter os pulls locais. Configure o ACR Tasks para acionar reconstruções em atualizações da imagem base de origem (upstream), propagando automaticamente as camadas com patches. Isso equilibra desempenho com segurança e reduz o egresso de dados.

3. Instalar o AKS com pools de nós e identidade separados

• Implante o AKS com Azure CNI e pools de nós de sistema/usuário: um pequeno pool de sistema para add-ons do plano de controle, pools de usuário com GPU habilitada para transcodificação e pools de uso geral para APIs. Habilite a integração com o Azure AD, o emissor OIDC e a workload identity. Atribua a permissão AcrPull à identidade do kubelet via az aks update –attach-acr. Isso isola as cargas de trabalho, escala eficientemente e remove a necessidade de segredos para puxar imagens.

4. Definir deployments declarativos e empacotamento

• Crie YAML do Kubernetes para Deployments, StatefulSets onde a persistência é necessária, Services, HorizontalPodAutoscaler e PodDisruptionBudgets. Empacote o serviço de codificador e o gateway de API como charts do Helm, publique-os como artefatos OCI no ACR e implante com helm upgrade –install usando valores específicos do ambiente. Isso proporciona lançamentos versionados e consistentes, além de rollbacks simples.

5. Expor serviços e aplicar segurança L7

• Use ClusterIP para microsserviços internos e um serviço LoadBalancer com o Application Gateway Ingress Controller para APIs públicas. Termine o TLS no Application Gateway com uma política de WAF, gerencie certificados usando o cert-manager integrado com o Azure DNS para desafios ACME e roteie para os backends por host/caminho. Isso resulta em segurança L7 de nível empresarial com configuração nativa do Kubernetes.

6. Implementar acesso seguro da carga de trabalho aos recursos do Azure

• Para um serviço de criação de miniaturas (thumbnails) que grava no Blob Storage e lê segredos, crie uma identidade gerenciada atribuída pelo usuário, federe-a com a conta de serviço via workload identity e conceda os papéis Storage Blob Data Contributor e Key Vault Secrets User. O pod se autentica com o Azure AD, eliminando a montagem de segredos e permitindo acesso granular e auditável.

7. Operar o excedente de processamento em lote com ACI

• Para excedentes de lote esporádicos e de alta prioridade, acione grupos de múltiplos contêineres do ACI (codificador + coletor de métricas sidecar) com restartPolicy: Never dentro de uma sub-rede com injeção de VNet. Isso absorve picos sem precisar escalar o AKS para a capacidade máxima e preserva os caminhos de dados privados para as contas de armazenamento.

Cada escolha apoia diretamente os objetivos da Adobe: o ACR Premium com georreplicação e endpoints privados protege e acelera os pulls de imagem; o AKS com pools de nós especializados e workload identity impõe isolamento e acesso de menor privilégio; o Helm e o YAML declarativo padronizam deployments e rollbacks; o AGIC com WAF oferece um ingresso L7 resiliente e seguro; e o ACI lida com o processamento em lote de pico sem o custo de um cluster persistente.

← Azure Cosmos DB · Todos os domínios · Autenticação →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Microsoft →