Microsoft AZ-400: Gerenciamento de Lançamentos e Estratégias de Implantação — 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

O gerenciamento de releases no Azure se baseia em uma entrega repetível e governada por políticas que protege a disponibilidade enquanto acelera o feedback. Dominar estratégias de implantação, validações com portões (gates), exposição baseada em anéis (rings) e lançamentos ocultos (dark launches) com feature flags permite que as equipes entreguem continuamente sem sacrificar a segurança. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager e Azure App Configuration fornecem um conjunto de ferramentas coeso para entrega progressiva, orquestração de múltiplos ambientes e controle de mudanças auditável. Esta seção explica quando e como usar cada capacidade, como conectá-las e quais práticas de rollback e documentação são esperadas em pipelines de produção.

Estratégias de Implantação e Entrega Progressiva

A implantação blue-green (ou red/black) implanta a nova versão em um ambiente paralelo (green) enquanto o atual (blue) atende ao tráfego. No Azure App Service, os slots de implantação implementam o blue-green: implante no slot de staging, faça o aquecimento (warm up) e, em seguida, realize uma troca de slot (slot swap). O rollback é instantâneo ao trocar de volta, razão pela qual o blue-green é a opção de rollback mais rápida. Combine as trocas de slot com a funcionalidade “Swap with preview” para validar bindings e configurações do aplicativo antes que o tráfego seja movido.

A implantação canary (canário) libera para uma pequena fatia de usuários primeiro e, em seguida, aumenta progressivamente o tráfego conforme a saúde do sistema se mantém. No Azure, implemente o canary com:

• Roteamento ponderado do Azure Front Door para dividir o tráfego entre os backends antigo e novo na camada de aplicação, com sondas de saúde (health probes) e WAF.
• Endpoints ponderados do Azure Traffic Manager para canaries globais baseados em DNS quando você precisa de controle em nível de região.
• Canary no AKS via Ingress (por exemplo, anotações de canary do NGINX) ou divisão de tráfego com service mesh. Os gates devem avaliar orçamentos de erro (error budgets), percentis de latência e saturação antes de avançar.

As atualizações contínuas (rolling updates) substituem as instâncias gradualmente, evitando o custo de manter duas frotas. No AKS, configure o rollingUpdate com maxSurge e maxUnavailable; garanta que as readiness/liveness probes e os PDBs protejam a disponibilidade. Para VM Scale Sets, use políticas de atualização contínua (rolling upgrade) com sondas de saúde da aplicação (application health probes). A estratégia rolling é econômica, mas a recuperação de regressões sistêmicas é mais lenta do que no blue-green.

As feature flags desacoplam o lançamento (release) da implantação (deploy). O lançamento oculto (dark launching) entrega caminhos de código desabilitados por padrão, exercitando a infraestrutura sem expor as funcionalidades. Use flags para controlar migrações caras, revelar progressivamente a UI e desativar rapidamente comportamentos problemáticos. Isso complementa as estratégias canary e de anéis: implante amplamente e, em seguida, habilite progressivamente.

A implantação baseada em anéis (ring-based deployment) formaliza a exposição progressiva entre coortes (grupos de usuários). Defina anéis como R0 (interno), R1 (clientes canary), R2 (uma região) e R3+ (global). Os critérios de avanço devem ser objetivos: conformidade com SLOs, ausência de incidentes Sev2+ e KPIs de negócio aceitáveis. Combine os anéis com o desvio de tráfego (Front Door/Traffic Manager), verificações de ambiente e portões de aprovação para parar ou reverter precocemente.

Azure Front Door versus Traffic Manager para desvio de tráfego progressivo: O Front Door opera na camada 7 com alterações instantâneas, sondas de saúde, afinidade de sessão, roteamento baseado em caminho e divisões ponderadas — ideal para canaries na camada de aplicação e testes A/B. O Traffic Manager opera no nível do DNS; é melhor para roteamento geográfico (geo-routing), failover entre nuvens ou canaries em nível de região, mas possui considerações de TTL de DNS e não oferece recursos de camada de aplicação.

Ambientes, Aprovações e Gates

O Azure Deployment Environments padroniza o provisionamento de ambientes de dev/test com barreiras de proteção (guardrails). As definições de ambiente são templates de infraestrutura como código (Bicep/ARM/Terraform) que descrevem pilhas (stacks) repetíveis. As definições residem em catálogos — repositórios Git registrados no serviço — permitindo projetos de ambiente (blueprints) versionados e detectáveis. Os desenvolvedores provisionam por autoatendimento (self-serve) instâncias de dev/test, restringidos por políticas corporativas (cotas, RBAC, rede), eliminando ambientes únicos (snowflakes) e alinhando os ambientes inferiores com a topologia de produção.

As aprovações estabelecem controles com intervenção humana (human-in-the-loop) onde necessário. No Azure Pipelines:

• As aprovações de pré-implantação bloqueiam um estágio até que os aprovadores designados consintam. Use para transições de alto risco, por exemplo, de staging para produção ou escalonamento de anel além do canary.
• As aprovações de pós-implantação confirmam as atividades de validação (aprovação de UAT, etapas de auditoria) antes que o release seja marcado como concluído.
• Configure timeouts de aprovação para que as solicitações expirem automaticamente; aprovações expiradas causam a falha do estágio e evitam desvios não controlados (drift). Exija múltiplos aprovadores ou sequencie as aprovações quando a separação de funções for necessária. Aplique aprovações a ambientes e conexões de serviço através de “Approvals and checks” para uma governança consistente.

Os portões de release (release gates) impõem evidências objetivas antes da promoção. O Azure Pipelines suporta verificações (checks) como:

• Verificações do Azure Monitor que consultam métricas ou alertas (por exemplo, nenhum alerta Sev2 ativo, taxa de erro abaixo do limiar, latência p95 abaixo da meta). Os gates reavaliam em um intervalo definido até o sucesso/falha ou timeout.
• Verificações de ‘Invoke REST API’ para chamar serviços de qualidade externos, testes de carga ou endpoints de conformidade internos. Analise as respostas e bloqueie se os critérios não forem atendidos.
• Verificações de consulta de work items para garantir que tarefas, bugs ou solicitações de mudança necessárias estejam nos estados corretos antes do release (por exemplo, todos os defeitos “Must Fix” resolvidos). Use consultas com escopo para o release ou para o intervalo de commits.

Implemente gates nas fronteiras dos anéis e durante a fase canary para mudar de decisões de promoção subjetivas para mensuráveis.

Pipelines Multi-Ambiente, Variáveis e Dependências

Projete pipelines YAML multi-estágio com dependências explícitas e escopo de ambiente. Use jobs de implantação com blocos de estratégia (runOnce, rolling, canary) para modelar a distribuição progressiva e inclua hooks para preDeploy, routeTraffic, postRouteTraffic e on: failure para reversão automatizada. Os estágios devem declarar dependsOn e conditions para que ambientes posteriores só sejam executados após os anteriores passarem por gates (portões) e aprovações.

Gerencie a configuração específica do ambiente por meio de:

• Grupos de variáveis com escopo por ambiente, vinculados ao Azure Key Vault para segredos. Referencie os grupos por estágio e mantenha valores sensíveis fora do controle de versão.
• Templates YAML e parâmetros de tempo de execução para padronizar as implantações entre serviços e passar valores específicos do ambiente (strings de conexão, padrões de feature flags, pesos do Front Door).
• Tarefas de tokenização ou transformação para appsettings e manifestos do Kubernetes, garantindo uma configuração como código livre de desvios (drift-free).

Para implantações em múltiplos ambientes, prefira artefatos imutáveis com promoção (compilar uma vez, implantar várias). Vincule work items a commits e builds para manter a rastreabilidade à medida que o mesmo artefato flui de dev para prod, permitindo notas de release e auditorias precisas.

Estratégias de Rollback e Considerações de Banco de Dados

Planeje os rollbacks antes de implantar:

• O rollback automático usa sinais de saúde (health signals) para reverter sem ação humana. No AKS, defina maxSurge/maxUnavailable de forma conservadora e habilite o rollback automático em rollouts com falha; use kubectl rollout undo ou confie nos hooks de falha da estratégia de implantação para acionar um ReplicaSet anterior. No Azure App Service, a retroca de slots (slot swap back) é instantânea; combine-a com verificações de saúde (health checks) e gates de implantação para decidir automaticamente.
• O rollback manual é apropriado quando a recuperação exige o julgamento do operador (risco de dados, falha parcial). Forneça tarefas de pipeline de um clique que redirecionam os pesos do Front Door/Traffic Manager, desfazem trocas de slot ou reimplantam o último build sabidamente bom. Mantenha o artefato anterior prontamente disponível e documente o processo de decisão.
• O rollback de banco de dados exige cuidado extra. Evite alterações incompatíveis com versões anteriores. Use a abordagem expandir-contrair (expand-contract): adicione colunas/tabelas e popule-as enquanto as leituras/escritas permanecem compatíveis; implante código que escreve em ambos os esquemas, se necessário; só depois remova os elementos obsoletos. Para o Azure SQL Database, combine:
  • DACPAC ou frameworks de migração (EF Core) com scripts idempotentes e versionados e validação pré e pós-implantação.
  • Operações online (reconstrução de índices com resumable, troca de partição) para minimizar a contenção de locks.
  • Restauração para um ponto no tempo (point-in-time restore) e georreplicação ativa como último recurso, reconhecendo o risco de perda de dados. Desative funcionalidades por meio de flags antes de qualquer downgrade de esquema. Condicione as promoções à saúde do banco de dados (DTU/CPU, deadlocks) capturados no Azure Monitor e no Query Store.

Feature Flags com Azure App Configuration e Automação de Notas de Lançamento

O Azure App Configuration centraliza o gerenciamento de features com SDKs para .NET, Java, Node.js e outros. Use rótulos (labels) para escopar as flags por ambiente ou anel (ring) e habilite a atualização dinâmica para que as aplicações apliquem as mudanças sem precisar de um novo deploy.

• Filtros de direcionamento (targeting filters) permitem uma habilitação granular com base em usuário/grupo, claims, dispositivo ou atributos personalizados. Defina coortes (por exemplo, tenants internos, clientes VIP) para alinhar com os anéis (rings).
• O rollout por porcentagem (percentage rollout) expõe gradualmente as features a um subconjunto aleatório. Comece com 1–5%, valide os KPIs e, em seguida, aumente. Coordene com o balanceamento de peso (weighting) do Front Door para um controle em camadas nos níveis de usuário e tráfego.
• Kill switches desativam instantaneamente uma feature quando ocorrem incidentes. Proteja caminhos de alto risco (pagamentos, escritas de dados) com um seletor de desativação global que não exige nenhum deploy para ser executado. Registre todos os acionamentos de toggles para auditoria e correlacione com incidentes.

Automatize as notas de lançamento (release notes) para fornecer rastreabilidade e comunicação:

• Exija a vinculação de work items, requerendo que mensagens de commit e PRs referenciem IDs. O Azure DevOps associa automaticamente builds e releases a work items e commits.
• Gere changelogs em pipelines usando a tarefa Generate Release Notes ou chamadas à API REST para listar as alterações e work items desde o último deploy bem-sucedido para o ambiente de destino. Gere um Markdown com seções para features, correções, breaking changes e migrações de banco de dados.
• Publique as notas na Wiki do projeto, empacote-as como um artefato de build e anexe-as à release. Inclua metadados do deploy (número do build, SHA do commit, ambiente, aprovadores, gates aprovados) para fins de conformidade (compliance).

Cenário de Problema Prático

A Adobe precisa introduzir um novo motor de personalização em seus sites de marketing hospedados no Azure sem arriscar as taxas de conversão durante campanhas de pico. A equipe deve fazer deploys frequentes, expor a feature progressivamente, validar os SLOs e fazer rollback instantaneamente se os KPIs se degradarem.

1. Defina ambientes com o Azure Deployment Environments

• Crie definições de ambiente (Bicep) para a aplicação, AKS, Azure SQL e Front Door em um catálogo baseado em Git. Os desenvolvedores autoaprovisionam ambientes de dev/teste com segurança, garantindo paridade com a produção e permitindo pilhas de teste efêmeras para experimentos. O ADE impõe cotas e RBAC para controlar gastos e acesso.

2. Construa uma vez, implante várias vezes com YAML multi-estágio

• Um único artefato é promovido através dos estágios (stages) ring-r0, ring-r1, ring-r2 e prod. Os estágios dependem uns dos outros e usam jobs de implantação com estratégias: canary e rolling onde apropriado, garantindo binários consistentes entre os anéis (rings).

3. Use blue-green com slots do App Service para a camada web legada

• Faça o deploy para um slot de staging, aqueça-o e, em seguida, troque (swap) para os usuários internos do ring-r0. Se os SLOs da Adobe regredirem, a retroca do slot (slot swap back) fornece o rollback mais rápido com tempo de inatividade quase zero.

4. Introduza canary via roteamento ponderado (weighted routing) do Azure Front Door

• Registre os backends de personalização legado e novo. Comece com 1% do tráfego para o novo backend no ring-r1. As sondas de saúde (health probes) do Front Door e as atualizações instantâneas de peso permitem ajustes seguros e rápidos, alinhados aos padrões de tráfego.

5. Use gates (portões) nas promoções com verificações objetivas

• Adicione verificações do Azure Monitor para latência p95, taxa de erro e KPIs de conversão originados do Application Insights. Adicione uma verificação de API REST ao serviço de experimentação interno da Adobe para confirmar as métricas de segurança (guardrail metrics). Configure uma verificação de consulta de work item para garantir que os bugs “Must Fix” (Correção Obrigatória) sejam fechados antes do avanço do anel (ring). Os gates são avaliados periodicamente e têm um tempo limite (timeout) para evitar que alterações fiquem paradas.

6. Exija aprovações em transições críticas

• As aprovações de pré-implantação (pre-deployment) para ring-r2 e prod exigem a aprovação (sign-off) do marketing e do SRE, com um timeout de 4 horas para evitar releases pendentes. As aprovações de pós-implantação (post-deployment) confirmam que o UAT e a validação da análise (analytics) estão concluídos antes de fechar a release.

7. Controle a exposição com feature flags do Azure App Configuration

• Implemente o dark launching para que o novo motor esteja presente, mas inicialmente desativado. Use filtros de direcionamento (targeting filters) para habilitá-lo para a equipe interna (ring-r0) e coortes de clientes selecionados (ring-r1). Aplique o rollout por porcentagem para expandir a exposição. Um kill switch desativa o motor globalmente em segundos, sem necessidade de redeploy, caso anomalias apareçam.

8. Proteja os dados com migrações do tipo expand-contract (expandir-contrair)

• Primeiro, implante alterações aditivas de SQL, preencha os dados de forma assíncrona (backfill) e faça escrita dupla (dual-write) onde necessário. Somente após a estabilidade ser comprovada, eles removem o esquema obsoleto (deprecated). Os gates monitoram DTU, deadlocks e consultas de longa duração para evitar uma promoção insegura.

9. Automatize os caminhos de rollback

• Gatilhos de falha (failure hooks) nos jobs de implantação acionam o rollback: os pesos do Front Door retornam a 0% para o novo backend; o App Service realiza uma troca reversa de slot (reverse slot swap); o AKS executa kubectl rollout undo. O rollback manual com um clique permanece disponível para os operadores em cenários complexos.

10. Automatize a documentação da release

• O pipeline gera notas de lançamento em Markdown a partir dos work items e commits associados, destacando as features ativadas, as alterações no banco de dados e os gates aprovados. As notas são publicadas na Wiki do Azure DevOps e anexadas à release, satisfazendo os requisitos de auditoria e a visibilidade para os stakeholders.

Essa abordagem usa cada ferramenta em seu ponto forte: ADE para ambientes seguros e reproduzíveis; estratégias YAML e aprovações para um fluxo governado; Front Door e App Configuration para entrega progressiva em camadas; Azure Monitor e gates para controle de qualidade objetivo; e rollbacks e notas de lançamento automatizados para resiliência e rastreabilidade.

← Conteinerização e Kubernetes · Todos os domínios · Segurança →

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

Navegar Microsoft →