Microsoft AZ-400: Conteinerização e Kubernetes — Guia de estudos

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Faz parte do Microsoft DevOps Engineer Expert AZ-400 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A conteinerização e o Kubernetes sustentam o DevOps moderno no Azure, combinando builds reprodutíveis, distribuição segura e orquestração de tempo de execução declarativa e com autorrecuperação (self-healing). A maestria exige o entendimento de como as imagens são montadas e otimizadas, como os registros (registries) replicam e atestam o conteúdo, como o AKS é projetado e atualizado sem interrupções, como a entrega progressiva é implementada e como proteger as cargas de trabalho (workloads) de ponta a ponta. Além do Kubernetes puro, você utilizará o Helm para empacotamento, o GitOps para reconciliação e — no espaço serverless — o Azure Container Apps com Dapr e KEDA para simplificar padrões de microsserviços e escalonamento orientado a eventos. As seções a seguir resumem as decisões de plataforma e as práticas operacionais que você precisa para implementar pipelines robustos e em conformidade (compliant) e clusters de produção resilientes.

Fundamentos de Build e Registro: Docker e ACR

Uma imagem de contêiner performática começa com um Dockerfile determinístico e um contexto de build (build context) disciplinado. Builds de múltiplos estágios (multi-stage builds) permitem separar os estágios de compilação pesados em ferramentas (toolchain) de imagens de tempo de execução (runtime) pequenas. Por exemplo, compile um binário .NET ou Go em um estágio de builder e, em seguida, copie apenas o artefato compilado para uma imagem base mínima ou “distroless” (por exemplo, mcr.microsoft.com/dotnet/runtime-deps ou gcr.io/distroless/base), resultando em superfícies de ataque menores e tempos de download (pull) mais rápidos. Cada RUN, COPY e ADD cria uma camada (layer); reestruture os Dockerfiles para maximizar os acertos de cache de camada, colocando os passos que mudam com menos frequência mais para o final e agregando comandos com agrupamento lógico, preservando a legibilidade. Sempre inclua um arquivo .dockerignore para excluir bin/obj, node_modules, testes, documentos e segredos (secrets); um contexto de build superdimensionado retarda os uploads e reduz a eficácia do cache remoto. Use instalações de pacotes determinísticas (fixação de versões, arquivos de lock) e argumentos de build com cuidado; arquivos específicos do ambiente devem fluir por meio da configuração de tempo de execução, não de imagens imutáveis.

O Azure Container Registry (ACR) é a espinha dorsal para o armazenamento e a distribuição de imagens. Utilize as ACR Tasks para descarregar os builds para o Azure: tarefas rápidas para builds sob demanda (az acr run), tarefas automatizadas acionadas por commits do Git, atualizações de imagem base ou agendamentos, e YAML de Tarefas de múltiplos passos para imagens multi-arquitetura usando o Buildx. A georreplicação (SKU Premium) espelha artefatos entre regiões, minimizando a latência de download (pull) e os custos de egresso para implantações multi-regionais do AKS/ACA; combine isso com endpoints privados e RBAC com escopo de repositório para o princípio do menor privilégio. Habilite a confiança de conteúdo (content trust) para assinar imagens e verificar a proveniência: o Docker Content Trust/Notary e os ecossistemas de assinatura OCI em evolução (por exemplo, cosign) podem ser impostos na admissão por meio de restrições (constraints) do OPA Gatekeeper que exigem assinaturas para namespaces protegidos. Integre a verificação de vulnerabilidades: o Microsoft Defender for Cloud verifica as imagens no momento do push e em repouso, expõe CVEs com orientações de correção e pode bloquear implantações por meio do Azure Policy e verificações de CI; inclua a automação de atualização da imagem base para reduzir as camadas com vulnerabilidades conhecidas.

Plataforma e Entrega de Cargas de Trabalho no AKS

Crie clusters AKS com configurações seguras por padrão: identidade gerenciada, integração com Azure AD para RBAC, Azure CNI para integração com VNET, network policy (Azure ou Calico), provedor Azure Key Vault (Secrets Store CSI) para consumo de secrets e clusters privados com faixas de IP autorizadas. Escolha node pools apropriados para a carga de trabalho: system pools para componentes críticos do control plane; user pools para aplicações; GPU pools para ML; spot pools para trabalhos stateless visando economia de custos; Windows node pools para contêineres Windows. Use taints/tolerations e topology spread constraints para controlar o agendamento e a resiliência. Faça o autoescalonamento com o cluster autoscaler e o Horizontal Pod Autoscaler por deployment; considere discos de SO efêmeros e zonas de disponibilidade para desempenho e resiliência.

Planeje as atualizações para minimizar interrupções. O AKS atualiza primeiro o control plane e, em seguida, os node pools. Use max-surge nas atualizações de node pools para adicionar capacidade extra, drenar os nós de forma controlada (gracefully) e respeitar os PodDisruptionBudgets. Adote canais de atualização automática (rápido/estável/somente patch) para uma cadência previsível; separe as atualizações dos system e user pools para limitar o raio de impacto. Realize atualizações da imagem do nó regularmente para obter correções de kernel/runtime, mesmo sem um aumento na versão do Kubernetes, e fixe versões compatíveis de CNI/CSI. Use node pools blue-green para alterações de plataforma sem tempo de inatividade — isole/drene (cordon/drain) o pool verde no azul e faça a transição via nodeSelector/affinity.

Os Deployments no Kubernetes suportam nativamente rolling updates com maxUnavailable e maxSurge para manter a capacidade durante o rollout; combine-os com readiness/liveness probes e startup probes para evitar tráfego prematuro. A entrega blue-green no Kubernetes é implementada executando Deployments paralelos (blue e green) e alternando um seletor de Service estável ou um objeto Endpoint para a revisão de destino; isso resulta em uma reversão quase instantânea ao trocar os labels. A entrega canary é melhor implementada na borda via ingress: o NGINX Ingress suporta canary ponderado via anotações; o Application Gateway Ingress Controller (AGIC) pode dividir o tráfego entre backends; service meshes oferecem traffic shifting com políticas granulares e telemetria. Para pipelines robustos, valide com smoke tests e verificações de disponibilidade do App Insights antes de promover os pesos do tráfego.

O Helm empacota manifestos do Kubernetes em charts, que compreendem o arquivo Chart.yaml, templates e um values.yaml padrão. Os arquivos de values são aplicados em camadas de forma determinística; use sobreposições com values.<env>.yaml e um bloco “global” para configurações entre sub-charts. Prefira o Helm 3 com armazenamento de charts baseado em OCI no ACR (helm registry login && helm push oci://…), habilitando paridade com imagens em RBAC e georreplicação. No Azure Pipelines, instale o Helm em uma versão fixa (HelmInstaller) e faça o deploy (HelmDeploy) através de uma service connection do tipo Kubernetes/Azure Resource Manager; a validação (linting) de templates, juntamente com dry-run e diff (plugin helm diff), deve controlar os releases. Evite commitar secrets nos arquivos de values; integre com external-secrets ou o CSI Key Vault para materializar os secrets em tempo de execução. Versione os charts semanticamente e fixe o appVersion ao digest da imagem para rastreabilidade.

Operações, Segurança e Controle de Tráfego

GitOps com Flux ou Argo CD garante que os clusters convirjam continuamente para um estado declarado. O Flux v2 se integra nativamente com o AKS através da Azure CLI/extensão, reconciliando Sources (Git/OCI/Bucket) e Kustomizations em um intervalo definido, e inclui automação de imagem para atualizar o Helm/Kustomize para novas tags com base em políticas. O Argo CD monitora Applications e sua saúde (health), suporta SSO com Azure AD e pode operar em modelos pull-based e app-of-apps para separação multi-tenant. Ambos detectam desvios (drift) e podem se autocorrigir, emitem eventos/alertas e suportam entrega progressiva; combine-os com o Flagger para automatizar canaries e testes A/B usando NGINX, Istio ou Linkerd, promovendo com base em métricas e revertendo em caso de violação de SLOs.

A segurança começa na cadeia de suprimentos (supply chain) e é aplicada na admissão e em tempo de execução. Verifique continuamente as imagens com o Defender for Cloud e integre validações (gates) no CI/CD. Adote os Kubernetes Pod Security Standards (baseline/restricted) com labels de Pod Security Admission nos namespaces para bloquear por padrão contêineres privilegiados, hostPath e sysctls inseguros. Aplique políticas organizacionais com o OPA Gatekeeper: constraint templates proíbem contêineres privilegiados, exigem registros aprovados, impõem limites de recursos e demandam imagens assinadas ou a presença de um SBOM. Aplique network policies para definir o tráfego permitido entre pods e de saída (egress); o AKS suporta Azure Network Policies (com Azure CNI) e Calico. Complemente com controle de egress via Azure Firewall ou NVA e ingress com WAF do Application Gateway. Fortaleça (harden) as cargas de trabalho com usuários não-root, sistemas de arquivos raiz somente leitura, perfis seccomp e AppArmor, e atualizações regulares da imagem do nó. Habilite auditoria e detecção de ameaças via Defender for Kubernetes e agregue a telemetria no Azure Monitor Container Insights; padronize logs/traces com OpenTelemetry.

Um service mesh (Istio ou Linkerd) adiciona gerenciamento de tráfego, criptografia e observabilidade de forma uniforme. Use DestinationRules/VirtualServices (Istio) ou ServiceProfiles (Linkerd) para definir retentativas (retries), timeouts, circuit breaking e roteamento ponderado. Habilite mTLS (mutual TLS) para criptografia e identidade de serviço a serviço; aplique políticas como mTLS “STRICT” para fechar brechas de segurança. Exporte métricas para o Prometheus e dashboards para o Grafana; capture traces distribuídos (Jaeger/Zipkin) e envie-os para o Application Insights ou Azure Monitor através de coletores OpenTelemetry. Canaries baseados em mesh e injeção de falhas (fault injection) potencializam testes confiáveis e entrega progressiva, com o Flagger automatizando a análise em relação aos SLOs.

Produtividade do Desenvolvedor e Contêineres Serverless no Azure

As ferramentas de integração de DevOps do AKS otimizam os ciclos de desenvolvimento internos (inner loops). O Draft detecta frameworks de linguagem e cria o scaffolding de Dockerfiles, charts do Helm e configurações de inicialização, acelerando a conteinerização. O Bridge to Kubernetes redireciona chamadas de serviço de um cluster ativo para sua estação de trabalho local, permitindo que você itere e depure um único microsserviço localmente enquanto o restante é executado no cluster com dados e dependências reais. O Azure Dev Spaces foi descontinuado; o Bridge to Kubernetes é a experiência de desenvolvimento local suportada e se integra com o VS Code e o Visual Studio.

O Azure Container Apps (ACA) oferece um runtime serverless e totalmente gerenciado para microsserviços e jobs sem a necessidade de gerenciar o Kubernetes. Cada implantação cria uma revisão; você pode rotear o tráfego entre as revisões por porcentagem para implantações no estilo blue-green ou canary com um único comando ou alteração no YAML. A integração nativa com o Dapr habilita invocação de serviços, pub/sub, bindings, repositórios de estado (state stores) e segredos sem a necessidade de implementações personalizadas; componentes conectáveis (pluggable) (ex: Azure Service Bus, Key Vault, Cosmos DB) aceleram a criação de funcionalidades consistentes entre serviços. O KEDA potencializa o autoescalonamento orientado a eventos com base na simultaneidade HTTP e em mais de 60 scalers (Azure Queue/Service Bus, Kafka, Prometheus, personalizados), escalando até zero para eficiência de custos. Use os Ambientes do ACA (ACA Environments) para isolamento de rede e integração com VNET, conecte o ACR via identidade gerenciada (managed identity) e gerencie a configuração através do YAML do containerapps para manter a paridade declarativa com as práticas de GitOps.

Cenário de Problema Prático

A Adobe precisa modernizar um serviço de análise de clientes multirregional, reduzindo o risco de lançamento e, ao mesmo tempo, reforçando a segurança da cadeia de suprimentos (supply chain) e do runtime. A equipe deve padronizar os builds, automatizar implantações seguras (rollouts) e garantir entregas rápidas e em conformidade nos EUA e na UE.

Implementar Dockerfiles de múltiplos estágios (multi-stage) e .dockerignore para todos os serviços

Por quê: Minimiza o tamanho da imagem e a superfície de ataque, melhora os acertos de cache de build (build cache hits) e evita a inclusão acidental de segredos ou grandes ativos de teste na imagem.

Construir e assinar imagens com ACR Tasks, enviar para um ACR com replicação geográfica

Por quê: Builds na nuvem eliminam variações locais; gatilhos de atualização da imagem base reduzem a exposição a CVEs. A replicação geográfica do ACR Premium colocaliza os artefatos com os clusters AKS, reduzindo a latência e o tráfego de saída (egress). As assinaturas garantem a proveniência.

Habilitar a varredura de imagens do Defender for Cloud e aplicar a política via gates de CI e OPA Gatekeeper

Por quê: Varreduras no momento do push e em repouso (at rest) detectam CVEs precocemente. As restrições (constraints) do Gatekeeper impõem políticas como “somente registros aprovados”, “imagens assinadas são obrigatórias” e limites de recursos, impedindo a admissão de cargas de trabalho (workloads) inseguras.

Provisionar clusters AKS privados por região com Azure CNI, políticas de rede (network policies) e identidade gerenciada (managed identity)

Por quê: Endpoints privados restringem a exposição do painel de controle (control plane); o Azure CNI se integra com VNETs corporativas; políticas de rede restringem o movimento lateral; a identidade gerenciada elimina a proliferação de segredos (secret sprawl).

Criar pools de nós (node pools) de sistema e de usuário separados, adicionar pools spot para jobs em lote (batch)

Por quê: Isola pods críticos da plataforma, fornece capacidade com custo-benefício para cargas de trabalho não críticas e simplifica atualizações e o gerenciamento de SLOs.

Adotar o Helm para empacotamento com charts armazenados no ACR (OCI), implantar via Azure Pipelines

Por quê: Lançamentos consistentes e versionados com valores por ambiente. Os pipelines executam helm lint, dry-run e diff antes do helm upgrade, usando uma conexão de serviço do Kubernetes para os clusters de destino.

Implantar o Flux v2 para reconciliação de GitOps e detecção de desvio (drift), integrar o Flagger para canaries

Por quê: A sincronização declarativa baseada em pull reduz as credenciais no CI e garante a convergência. O Flagger automatiza canaries ponderados com base em SLOs usando métricas do NGINX Ingress, revertendo (rolling back) em caso de erros ou picos de latência.

Configurar atualizações contínuas (rolling updates) com PDBs e probes de prontidão (readiness) e inicialização (startup); usar blue-green para componentes de risco

Por quê: Atualizações contínuas preservam a capacidade; os probes protegem o tráfego do usuário. A estratégia blue-green com uma troca de label no Service permite reversão instantânea para componentes de alto risco, como o gateway de API.

Introduzir a malha de serviços (service mesh) Istio com mTLS estrito, novas tentativas (retries) e timeouts; exportar telemetria para o Application Insights

Por quê: Criptografia em toda a malha, políticas de tráfego robustas e observabilidade uniforme. Coletores OpenTelemetry enviam traces e métricas para um repositório central para monitoramento de SLOs e triagem de incidentes.

Estabelecer uma estratégia de atualização controlada com o canal de atualização automática (auto-upgrade) do AKS e atualizações de imagem de nó

Por quê: Atualizações de plataforma regulares e previsíveis reduzem a exposição a vulnerabilidades de dia zero (zero-day). Max-surge e PDBs garantem interrupção mínima; atualizações separadas do pool de usuários limitam o raio de impacto (blast radius).

Usar o Bridge to Kubernetes para o desenvolvimento no ciclo interno (inner-loop); criar scaffolding com o Draft

Por quê: Os desenvolvedores depuram localmente com base nas dependências do cluster, sem a necessidade de mocks. O Draft acelera a conteinerização consistente e a criação de scaffolding do Helm entre as equipes.

Descarregar serviços de cauda longa (long-tail) para o Azure Container Apps com Dapr e KEDA

Por quê: Microsserviços orientados a eventos que escalam até zero (ex: ingestão e enriquecimento) são executados a baixo custo com divisão de tráfego integrada para canaries; os componentes do Dapr padronizam as chamadas entre serviços e o pub/sub sem código personalizado.

Este design de ponta a ponta alinha o determinismo do build com distribuição segura, operações declarativas e entrega progressiva, proporcionando à Adobe lançamentos rápidos e de baixo risco e um runtime reforçado (hardened) em todas as regiões.

← Infraestrutura como Código e Gerenciamento de Configuração · Todos os domínios · Gerenciamento de Lançamentos e Estratégias de Implantação →

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