Microsoft AZ-400: Pipelines de CI/CD com Azure Pipelines — 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 Azure Pipelines oferece CI/CD de ponta a ponta como código, com pipelines YAML de múltiplos estágios que unificam compilação, teste e release, preservando os controles corporativos. O domínio da criação de YAML, gatilhos, agentes, variáveis, templates, jobs de implantação, artefatos, cache e conexões de serviço é essencial para construir sistemas de entrega escaláveis, seguros e repetíveis.

Criação com YAML e Templates

Um pipeline YAML é composto por estágios (stages), jobs e etapas (steps). Os estágios modelam as fronteiras do ciclo de vida, como Build, Teste e Release; os jobs são executados em agentes e podem rodar em paralelo; as etapas são tarefas ou scripts executados dentro de um job. As dependências são explícitas via dependsOn, permitindo orquestração refinada e execução condicional. O YAML de múltiplos estágios consolida CI e CD, suporta padrões de fan-in/fan-out e vincula as aprovações a ambientes, em vez de a uma construção de release separada.

Templates permitem composição e reutilização em diferentes granularidades:

Templates de etapa (step): encapsulam uma sequência de tarefas (por exemplo, configuração de ferramentas, restauração, compilação, teste) para reutilização entre repositórios.
Templates de job: agrupam etapas com uma especificação de agente e estratégia específicas (por exemplo, um job de matriz de teste).
Templates de estágio (stage): empacotam estágios inteiros, incluindo aprovações, condições e direcionamento de ambiente, para fluxos de promoção consistentes.
Templates extends: impõem a herança de pipeline. Um extends de nível superior referencia um template central que prescreve os estágios/jobs/etapas e a governança necessários. Isso é poderoso para políticas de toda a organização, garantindo que cada equipe herde varreduras de segurança, verificações de conformidade e convenções de nomenclatura.

A avaliação do template ocorre em tempo de compilação (compile-time), antes da execução em tempo de execução (runtime). Use ${{ }} para expressões de template para ramificar a estrutura do pipeline em tempo de compilação (por exemplo, incluir certos jobs apenas para o branch main). A sintaxe de macro $(var) e as expressões de tempo de execução $[ ] são resolvidas em tempo de execução, o que afeta quando os segredos (secrets) e grupos de variáveis estão disponíveis. Armazene templates compartilhados em um repositório central e importe-os via resources repositories; fixe (pin) em um branch ou tag para compilações determinísticas.

Gatilhos, Agentes, Variáveis e Expressões

Gatilhos (triggers) governam os pontos de entrada da automação:

Gatilhos de CI (CI triggers) iniciam as execuções do pipeline quando o código é enviado (push) para branches rastreados. Filtros de caminho de inclusão e exclusão reduzem a rotatividade (churn). O Batch permite agrupar múltiplos pushes.
Gatilhos de PR (PR triggers) validam pull requests. Configure branches de destino e filtros de caminho, e habilite o cancelamento automático de execuções substituídas.
Gatilhos agendados (Scheduled triggers) são executados com base em expressões cron para suportar compilações noturnas ou validações periódicas com controle de fuso horário.
Gatilhos de pipeline (Pipeline triggers) disparam quando um pipeline upstream publica uma nova execução ou artefato. Declare recursos de pipeline e anexe trigger: true com filtros de branch para encadear pipelines entre repositórios ou projetos.

Agentes e pools de agentes determinam onde os jobs são executados:

Agentes hospedados pela Microsoft (Microsoft-hosted agents) provisionam VMs efêmeras em imagens ubuntu-latest, windows-latest ou macOS com conjuntos de ferramentas pré-instalados. Eles são ideais para elasticidade e manutenção mínima. Planeje a concorrência comprando jobs paralelos e considere os limites de aquecimento do cache.
Agentes auto-hospedados (Self-hosted agents) rodam em sua própria infraestrutura para toolchains personalizados, acesso à rede privada e desempenho previsível. Faça o hardening do host, restrinja o tráfego de saída (egress) conforme necessário e rotacione o PAT do agente usado para registrar o agente. Use scale sets ou agentes em contêineres para elasticidade.
Pools de agentes (Agent pools) agrupam logicamente os agentes e são usados para delegar permissões. Conceda direitos de “Uso” em nível de projeto aos pools e isole cargas de trabalho sensíveis em pools dedicados. Os jobs especificam o pool e, opcionalmente, demands para selecionar agentes com as capacidades necessárias.

Variáveis e parâmetros impulsionam a configurabilidade:

Variáveis de pipeline são pares de chave/valor disponíveis para as tarefas como variáveis de ambiente e através da macro $(name). Variáveis secretas (Secret variables) são mascaradas nos logs e nunca expostas em expressões de template em tempo de compilação. Marque-as como secretas na Biblioteca (Library) ou no pipeline.
Grupos de variáveis (Variable groups) centralizam valores e segredos compartilhados na Biblioteca (Library). Vincule ao Azure Key Vault para obter segredos em tempo de execução, garantindo que os valores não sejam armazenados no pipeline. Controle as permissões do pipeline para restringir quais pipelines podem consumir um grupo.
Parâmetros de tempo de execução (Runtime parameters) definem entradas fortemente tipadas no momento do enfileiramento (string, number, boolean, object) e são avaliados em tempo de compilação via ${{ parameters.* }} para moldar o pipeline (por exemplo, habilitar/desabilitar estágios). Prefira parâmetros quando precisar alterar a estrutura do pipeline; prefira variáveis quando precisar de valores em tempo de execução dentro das etapas.
Expressões: use ${{ }} para lógica de template em tempo de compilação, $(var) para substituição de macro e $[condition()] para condicionais de tempo de execução em propriedades. Defina variáveis a partir de tarefas via comandos de log e propague saídas entre jobs usando variáveis isOutput.

Implantações, Ambientes, Estratégias e Portões

Trabalhos de implantação (deployment jobs) fornecem semântica de CD de primeira classe. Um trabalho de implantação tem como alvo um ambiente e é executado sob uma estratégia que controla as distribuições (rollouts) e os ganchos de ciclo de vida (lifecycle hooks):

Ambientes representam alvos de implantação (ex: dev, test, prod) e podem conter recursos como clusters Kubernetes, máquinas virtuais ou recursos genéricos “none” para implantações agnósticas de plataforma. Ambientes unificam telemetria, aprovações e verificações.
Aprovações e verificações são anexadas a ambientes e conexões de serviço. Aprovações exigem que aprovadores designados deem seu consentimento antes que a implantação prossiga. Verificações atuam como portões (gates) que avaliam condições como horário comercial, itens de trabalho necessários, sinais do Azure Monitor, invocação de APIs REST ou Azure Functions e proteção de branch. Elas impedem a promoção se as linhas de base de desempenho ou as condições de conformidade não forem satisfeitas.
Estratégias moldam como as atualizações são distribuídas:
- runOnce aplica as alterações em uma única onda, com ganchos preDeploy e postDeploy.
- rolling implanta em lotes entre instâncias, com limiares maxParallel e de falha para uma progressão segura.
- canary desloca o tráfego gradualmente por meio de incrementos, com fases routeTraffic e postRouteTraffic para validar antes da distribuição completa.
- blue-green (também chamado de red/black) é implementado com a implantação em um ambiente ou slot paralelo e a troca de tráfego no balanceador de carga ou na troca de slot (slot swap) do App Service. Embora blue-green não seja uma estratégia nomeada em YAML, ela é realizada por meio de ambientes, roteamento e tarefas de troca, e fornece reversão (rollback) rápida ao reverter o tráfego.

Codifique a lógica de implantação como um trabalho de implantação por estágio de ambiente. Utilize as verificações de ambiente para criar portões robustos, em vez de usar sondagem (polling) com scripts ad-hoc. Quando segredos forem necessários, recupere-os do Azure Key Vault por meio de uma conexão de serviço, em vez de incorporá-los em variáveis.

Artefatos, Cache e Conexões de Serviço

Artefatos e cache melhoram o reuso e o desempenho:

Artefatos de pipeline são a forma nativa de publicar e consumir as saídas do build. Use PublishPipelineArtifact para publicar artefatos nomeados e DownloadPipelineArtifact para buscá-los da execução atual ou de uma específica. Eles são otimizados para confiabilidade e compartilhamento entre estágios em YAML. Ao consumir de outro pipeline, declare um recurso de pipeline e use o nome do recurso de seus artefatos para uma recuperação precisa.
Pacotes universais fornecem distribuição binária versionada e imutável via Azure Artifacts para ativos não específicos de linguagem (ex: ferramentas de CLI, arquivos de dados). Publique e baixe com as tarefas de Pacotes Universais (Universal Packages), organize por meio de visualizações de feed (ex: pré-lançamento vs. lançamento) e gerencie a retenção nos feeds.
O cache de pipeline acelera a restauração de dependências. A tarefa Cache usa uma chave (key) e um caminho (path). As chaves devem fazer o hash dos arquivos de lock (package-lock.json, Pipfile.lock, packages.lock.json, go.sum) mais as versões do SO e das ferramentas para uma invalidação precisa. Chaves de restauração (restore keys) fornecem correspondências de fallback para acertos parciais de cache (partial cache hits). Evite incorporar segredos nos caminhos de cache, respeite os limites de tamanho do cache e desabilite o cache para ferramentas efêmeras quando os arquivos de lock forem instáveis. Observe a variável cacheHitVar para ramificar o comportamento da tarefa.

Conexões de serviço definem a identidade que o Azure Pipelines usa para alcançar sistemas externos:

Os tipos incluem Azure Resource Manager (para assinaturas e grupos de recursos do Azure), GitHub (leitura/escrita de repositório, relatório de status) e Docker/Container Registry (Docker Hub, ACR). Existem outros para AWS, GCP, endpoints de serviço genéricos e registros de pacotes.
A federação OIDC (federação de identidade de carga de trabalho) remove segredos de longa duração ao estabelecer uma confiança entre o Azure DevOps e os provedores de identidade na nuvem. Para ARM, configure uma aplicação do Entra ID com uma credencial federada vinculada ao emissor (issuer) do Azure DevOps e às declarações (claims) do repositório/pipeline. Em tempo de execução, o Azure DevOps troca um token de curta duração por um token de acesso à nuvem, eliminando os segredos do principal de serviço (service principal) e reduzindo o risco de vazamento de credenciais.
Escopo e governança são críticos. Defina o escopo das conexões ARM para o menor privilégio (idealmente no nível do grupo de recursos com RBAC personalizado). Desabilite a opção “Conceder permissão de acesso a todos os pipelines” e, em vez disso, autorize os pipelines explicitamente. Anexe aprovações e verificações às conexões de serviço para exigir revisão humana ou validação de política antes do uso.

Clássico vs. YAML e Migração

Pipelines clássicos usam o designer visual com conceitos separados de Build e Release. Eles oferecem autoria baseada em tarefas, gerenciamento de variáveis, ambientes de release e gates. Pipelines YAML fornecem pipeline como código, unificação multi-estágio, templates e versionamento robusto com o repositório. A paridade de recursos foi amplamente alcançada: aprovações e verificações de ambiente substituem os gates de release; jobs de implantação modelam ambientes; artefatos de pipeline substituem os artefatos de build; e templates e extends implementam governança centralizada em escala. As diferenças restantes geralmente giram em torno de intervenções manuais baseadas em UI e alguns recursos de nicho do designer de release, que são cobertos em YAML por meio de tarefas de Validação Manual e verificações de ambiente.

Um caminho de migração pragmático é:

Inventariar as definições clássicas de build e release, tarefas, variáveis, ambientes, aprovações e gates.
Converter o build para YAML usando o assistente ou exportando para YAML, depois refatorar em templates para reuso e manutenibilidade.
Modelar cada ambiente de release como um estágio YAML com um job de implantação direcionado a um ambiente. Traduzir os gates de release para aprovações e verificações de ambiente (por exemplo, verificações de consulta do Azure Monitor, verificações de consulta de item de trabalho).
Externalizar variáveis compartilhadas em grupos de variáveis e vincular o Key Vault para segredos. Substituir segredos de service principal por conexões de serviço baseadas em OIDC.
Substituir gatilhos de artefato de release por gatilhos de recurso de pipeline. Publicar artefatos de pipeline em CI e consumi-los nos estágios de CD.
Validar a paridade executando ambos os pipelines temporariamente, depois fazer a transição e desativar as definições clássicas com planos de rollback apropriados.

Cenário de Problema Prático

A Starbucks está padronizando a entrega para uma plataforma de microsserviços e precisa migrar de releases clássicos para YAML, ao mesmo tempo em que impõe gates de performance, reduz o risco de credenciais e acelera os builds.

Criar YAML multi-estágio com templates extends

Abordagem: Criar um template extends central em nível de organização que injeta estágios comuns para análise estática, SCA e verificações de segurança, além de notificações padrão. Cada pipeline de serviço estende esse template e define seus estágios de build e deploy específicos.
Justificativa: O uso de extends impõe governança de forma uniforme e mantém os pipelines de serviço enxutos, garantindo as etapas de conformidade necessárias.

Implementar gatilhos de CI, PR, agendamento e pipeline

Abordagem: Configurar gatilhos de CI e PR com filtros de caminho para cada serviço; adicionar um agendamento noturno para testes de integração de longa duração; encadear um pipeline de empacotamento para acionar um pipeline de implantação por meio de recursos de pipeline.
Justificativa: Garante feedback rápido sobre alterações de código, verificações de saúde periódicas e a promoção determinística de artefatos conhecidos.

Usar estratégia de agentes mistos com pools de agentes

Abordagem: Jobs de build em agentes ubuntu-latest hospedados pela Microsoft para elasticidade; jobs de deploy em agentes auto-hospedados dentro da VNet da Starbucks com acesso a clusters internos. Isolar agentes por pools por ambiente e restringir o uso do pool.
Justificativa: Agentes hospedados minimizam a manutenção para CI; agentes auto-hospedados fornecem alcance de rede seguro para CD. O escopo de pool impõe o princípio do menor privilégio.

Gerenciar variáveis com grupos de variáveis e parâmetros de tempo de execução

Abordagem: Colocar valores compartilhados não secretos em grupos de variáveis, recuperar segredos do Azure Key Vault por meio de grupos de variáveis vinculados e expor um parâmetro booleano enablePerfGate para alternar os gates de performance em branches de não produção.
Justificativa: A configuração centralizada evita duplicação; o Key Vault protege os segredos; parâmetros direcionam escolhas de estrutura em tempo de compilação.

Definir jobs de implantação com ambientes, aprovações e verificações

Abordagem: Modelar dev, staging e prod como ambientes. Adicionar aprovações para staging e prod. Adicionar verificações: horário comercial para prod e uma verificação de consulta do Azure Monitor que bloqueia a promoção se a latência de staging exceder a linha de base.
Justificativa: Aprovações e verificações em nível de ambiente implementam a promoção controlada e impõem SLOs antes da implantação em produção.

Aplicar estratégias canary e depois blue-green

Abordagem: Usar uma estratégia canary em staging para validar os incrementos. Em produção, implantar em um slot/ambiente paralelo e trocar o tráfego (blue-green/red-black) com capacidade de rollback instantâneo.
Justificativa: A estratégia Canary reduz o risco durante a validação; a blue-green minimiza o tempo de implantação e fornece o rollback mais rápido.

Otimizar com artefatos de pipeline e cache

Abordagem: Publicar as saídas do build como artefatos de pipeline; consumi-los nos estágios de implantação. Fazer cache da restauração de dependências usando chaves com hash do lockfile com restoreKeys para fallback.
Justificativa: Artefatos garantem uma promoção imutável e rastreável; o cache reduz significativamente os tempos de build sem sacrificar a correção.

Proteger conexões de serviço com OIDC e permissões com escopo definido

Abordagem: Criar conexões de serviço ARM usando federação de identidade de carga de trabalho com escopo definido para grupos de recursos. Exigir aprovações e verificações de conexão de serviço e desabilitar a opção “Conceder acesso a todos os pipelines”.
Justificativa: Remove segredos de longa duração e impõe o princípio do menor privilégio com aprovações auditáveis.

Este design de ponta a ponta alinha a governança de YAML como código com aprovações e verificações de nível empresarial, acelera a entrega por meio de cache e artefatos e fortalece a segurança via OIDC e conexões de serviço com escopo definido.

← Controle de Código-Fonte e Gerenciamento de Repositórios · Todos os domínios · Infraestrutura como Código e Gerenciamento de Configuração →

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