O exame AZ-400 testa como projetar a cadeia completa de automação desde o computador do desenvolvedor até a produção. Os tópicos centrais são as diferenças entre Azure Pipelines e GitHub Actions, estrutura YAML, filtragem de gatilhos, mecanismos de reutilização e seleção de runners. Ambas as plataformas pertencem à Microsoft, mas têm filosofias distintas — por isso o exame pergunta repetidamente qual se encaixa em cada situação. A resposta está sempre dentro das condições do cenário.
CI e CD — Sensores na linha de montagem
Imagine uma fábrica de automóveis onde as peças avançam sem nenhuma verificação de qualidade. Os defeitos só aparecem na inspeção final, quando corrigi-los é mais caro. Dez desenvolvedores trabalham simultaneamente e, na segunda-feira, ao integrar as mudanças, tudo são conflitos. CI (Integração Contínua) resolve isso executando automaticamente uma compilação e testes sempre que o código é integrado, detectando problemas no momento mais cedo possível.
CD tem dois significados. Continuous Delivery entrega automaticamente artefatos validados até o staging, mantendo uma aprovação manual antes da produção. Continuous Deployment remove essa aprovação e faz deploy direto para produção. A distinção do exame: se há alguma aprovação manual antes da produção, é Delivery; se nada se interpõe entre o pipeline e a produção, é Deployment.
Azure Pipelines vs GitHub Actions — Qual escolher
Imagine duas lojas lado a lado. Uma é um shopping com seção especializada em DevOps (Azure Pipelines). A outra é uma loja conceito no coração da comunidade de desenvolvedores, com enorme variedade de componentes prontos (GitHub Actions). Qual escolher depende quase inteiramente do que você já possui.
Azure Pipelines faz parte do Azure DevOps, integrando Azure Repos, Azure Boards e Azure Artifacts. Conecta-se a Bitbucket, GitHub, GitHub Enterprise e Azure Repos como fontes, sem depender de um único provedor Git. Grupos de implantação, variable groups, service connections e pipelines de múltiplos estágios são recursos integrados.
GitHub Actions é uma plataforma de automação totalmente integrada a repositórios GitHub. Os fluxos são arquivos YAML em . Mais de 15.000 Actions estão no Marketplace. Qualquer evento do GitHub (push, pull_request, schedule, workflow_dispatch) pode ser gatilho.
| Situação | Recomendação | |----------|--------------| | Código no GitHub, ambiente open-source | GitHub Actions | | Azure DevOps já adotado, independência do provedor Git | Azure Pipelines | | Fonte on-premises | Azure Pipelines | | Validação baseada em PR como padrão principal | GitHub Actions |
!Azure Pipelines vs GitHub Actions
Estrutura YAML e gatilhos
Pense numa cozinha de restaurante. Quando um pedido chega, a estação de entradas trabalha primeiro, depois a de pratos principais, depois a de sobremesas. Dentro de cada estação, vários cozinheiros trabalham em paralelo. Os pipelines de CI/CD seguem o mesmo modelo hierárquico.
O YAML do Azure Pipelines é . Um Stage é uma fase lógica (Build, Test, Deploy). Um Job roda em um único agente. Um Step é um Script ou Task. GitHub Actions usa sem Stage; a palavra-chave expressa dependências entre Jobs.
Gatilhos: no Azure Pipelines, (push em branch), (Pull Request) e (cron) são chaves separadas. No GitHub Actions, os eventos ficam sob . Filtros de caminho () são essenciais em monorepos para que o pipeline dispare apenas quando arquivos de um diretório específico mudam. Nos padrões glob, cruza. corresponde a , mas não — o exame volta a essa distinção repetidamente.
Sem , os Jobs rodam em paralelo por padrão. executa mesmo quando a etapa anterior falhou; pula apenas em cancelamento. Uma etapa que publica resultados de testes deve usar para que os resultados sejam visíveis mesmo quando os testes falham.
Reutilização — Templates, reusable workflows e environments
Em vez de redigir o cabeçalho da empresa em cada documento, você abre o modelo compartilhado e preenche só o conteúdo único. Reutilização de pipelines funciona da mesma forma.
Templates do Azure Pipelines são arquivos YAML separados que definem Stages, Jobs, Steps ou Variables, referenciados com . Em repositório dedicado, use e fixe a versão com ou SHA de commit. Referenciar a branch principal deixa mudanças não validadas se propagar para todos os pipelines de produção.
Reusable workflows do GitHub Actions são invocados via , aceitando e , com até quatro níveis de aninhamento. Uma composite action empacota múltiplos Steps em uma única Action reutilizável.
Um environment representa um destino de implantação. Um Job vinculado a um environment registra o histórico e aplica portões: aprovações, verificação de template obrigatório, permissões de pipeline e horário comercial, configurados independentemente por environment. Para restringir quais pipelines podem implantar em produção, use as permissões de pipeline do environment, não a aba de segurança da conexão de serviço. Um variable group vinculado ao Azure Key Vault carrega segredos dinamicamente em tempo de execução, sem texto simples no YAML.
Seleção de runner — Microsoft-hosted vs Self-hosted
Alugar um carro (Microsoft-hosted runner) significa que a locadora cuida da manutenção. Mas acessar um estacionamento privado que só aceita veículos com cartão especial exige ter seu próprio carro (self-hosted runner). A escolha certa depende de para onde você precisa ir.
Runners hospedados pela Microsoft provisionam uma nova VM para cada build e a descartam na conclusão. A Microsoft gerencia patches, ferramentas e disponibilidade. Imagens de Windows Server, Ubuntu e macOS estão disponíveis com ferramentas de build pré-instaladas. Esses runners não acessam recursos de rede interna não expostos à internet.
Self-hosted runners se instalam em máquinas da organização, acessando recursos atrás do firewall. O agente usa um modelo pull de saída via HTTPS 443, sem regras de entrada necessárias. Scale set agents ajustam automaticamente o número de agentes com base na fila, mantendo o acesso de rede dos self-hosted. Container jobs rodam cada Job dentro de uma imagem Docker sobre um self-hosted runner, isolando dependências por serviço.
Se as filas estão sobrecarregadas e acesso interno não é necessário, comprar parallel jobs adicionais tem menor sobrecarga operacional do que implantar self-hosted runners.
Resumo do Exame
"Código no GitHub, ambiente open-source" -- GitHub Actions "Azure DevOps já adotado, independência do provedor Git" -- Azure Pipelines vs -- corresponde a apenas um "Publicar resultados mesmo quando os testes falham" -- "Executar sem depender de estágios anteriores" -- "Apenas pipelines específicos podem implantar em produção" -- permissões de pipeline do environment (não a segurança da conexão de serviço) "Não armazenar segredos no YAML" -- variable group vinculado ao Azure Key Vault "Mudanças em templates não devem chegar à produção automaticamente" -- fixar com tag ou SHA de commit "Acesso a recursos de rede interna" -- self-hosted runner "Mínima sobrecarga operacional com escalonamento automático" -- Microsoft-hosted runner ou scale set agent "Gatilho para invocar um workflow reutilizável" -- evento CI = compilação e teste automáticos em cada commit / CD Delivery = entrega automática ao staging mais aprovação manual / CD Deployment = automático até a produção sem aprovação