# ArgoCD e GitOps em 2026: Deploy Contínuo no Kubernetes e Perguntas de Entrevista > Guia completo sobre ArgoCD e GitOps para deploy contínuo em Kubernetes em 2026. Aborda Application CRDs, sync waves, gerenciamento multi-cluster com ApplicationSets, comparação ArgoCD vs Flux e perguntas frequentes de entrevista para DevOps. - Published: 2026-06-05 - Updated: 2026-06-05 - Author: SharpSkill - Tags: argocd, gitops, kubernetes, continuous-deployment, devops, interview - Reading time: 10 min --- O ArgoCD consolidou sua posição como ferramenta dominante de GitOps para deploy contínuo em Kubernetes. Com o lançamento da [versão 3.4](https://github.com/argoproj/argo-cd/releases) em maio de 2026 e mais de 64% das empresas reportando GitOps como mecanismo primário de entrega de software, o domínio dessa tecnologia tornou-se requisito praticamente obrigatório em processos seletivos para engenharia DevOps e plataforma. Este guia aborda os conceitos fundamentais do ArgoCD, padrões práticos de configuração e as perguntas que aparecem com maior frequência em entrevistas técnicas. > **O que é GitOps?** > > GitOps é uma metodologia de deploy em que o Git funciona como fonte única de verdade tanto para o código da aplicação quanto para a configuração de infraestrutura. Um agente GitOps executando dentro do cluster reconcilia continuamente o estado real do cluster com o estado desejado declarado em um repositório Git, corrigindo automaticamente qualquer divergência. ## Como o ArgoCD Implementa o Modelo GitOps O ArgoCD opera como um conjunto de microsserviços dentro de um cluster Kubernetes: um servidor de API, um servidor de repositórios, um controlador de aplicações e um cache Redis. O controlador monitora repositórios Git e compara o estado desejado (manifests no Git) com o estado ativo no cluster. Quando uma diferença é detectada, o ArgoCD alerta ou sincroniza automaticamente, conforme a política configurada. Esse modelo pull-based oferece uma vantagem de segurança significativa em relação ao modelo push tradicional, onde uma ferramenta de CI envia deploys diretamente para o cluster. No modelo pull, o próprio cluster busca as alterações no Git, eliminando a necessidade de expor endpoints de entrada ou distribuir credenciais do cluster para sistemas externos. As credenciais nunca ultrapassam o perímetro do cluster. O primeiro passo consiste em instalar o ArgoCD e definir um recurso Application: ```yaml # argocd-application.yaml apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: my-web-app namespace: argocd spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: overlays/production destination: server: https://kubernetes.default.svc namespace: production syncPolicy: automated: prune: true # Remove resources deleted from Git selfHeal: true # Revert manual changes in the cluster syncOptions: - CreateNamespace=true ``` O bloco `source` aponta para o repositório Git que contém os manifests Kubernetes. O bloco `destination` especifica o cluster e o namespace de destino para o deploy. A configuração `automated.selfHeal: true` garante que qualquer alteração manual feita via kubectl seja sobrescrita pelo estado declarado no Git em questão de segundos. Já a opção `prune: true` assegura que recursos removidos do repositório também sejam excluídos do cluster, mantendo paridade total entre Git e ambiente de execução. ## Sync Waves e Hooks para Deploys Ordenados Deploys em ambientes reais raramente consistem em um único manifest. Migrações de banco de dados precisam ser executadas antes da inicialização dos pods da aplicação. ConfigMaps e Secrets devem existir antes que os Deployments os referenciem. O ArgoCD resolve essa necessidade de ordenação por meio de sync waves e resource hooks. Sync waves atribuem uma ordem numérica aos recursos. Números menores são implantados primeiro, e o ArgoCD aguarda que cada wave atinja o estado saudável antes de prosseguir para a próxima: ```yaml # migration-job.yaml apiVersion: batch/v1 kind: Job metadata: name: db-migrate annotations: argocd.argoproj.io/sync-wave: "-1" # Runs before wave 0 argocd.argoproj.io/hook: PreSync # Executes before main sync argocd.argoproj.io/hook-delete-policy: HookSucceeded spec: template: spec: containers: - name: migrate image: acme/my-web-app:latest command: ["python", "manage.py", "migrate"] restartPolicy: Never ``` O hook `PreSync` executa o job de migração antes que o ArgoCD aplique os manifests principais da aplicação. A política `HookSucceeded` remove automaticamente o Job após a conclusão bem-sucedida, evitando o acúmulo de recursos obsoletos. A versão 3.3 do ArgoCD introduziu hooks `PreDelete`, resolvendo o problema recorrente de recursos órfãos durante a remoção de aplicações. ## Gerenciamento Multi-Cluster com ApplicationSets Gerenciar dezenas de clusters a partir de uma única instância do ArgoCD exige mais do que duplicar manifests de Application manualmente. Os [ApplicationSets](https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/) geram recursos Application de forma dinâmica a partir de templates e geradores: ```yaml # applicationset-clusters.yaml apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: my-web-app-all-clusters namespace: argocd spec: generators: - clusters: selector: matchLabels: env: production template: metadata: name: 'my-web-app-{{name}}' spec: project: default source: repoURL: https://github.com/acme/my-web-app-config targetRevision: main path: 'overlays/{{metadata.labels.region}}' destination: server: '{{server}}' namespace: production syncPolicy: automated: prune: true selfHeal: true ``` O gerador de clusters itera sobre todos os clusters registrados que possuem o label `env: production` e cria uma Application para cada um deles. Os placeholders `{{name}}`, `{{server}}` e `{{metadata.labels.region}}` são resolvidos a partir dos dados de registro do cluster. Ao adicionar um novo cluster de produção ao ArgoCD, o deploy da aplicação nesse cluster é disparado automaticamente, sem nenhuma intervenção manual. ## ArgoCD vs Flux: Escolhendo a Ferramenta GitOps Adequada A comparação entre ArgoCD e Flux é um dos temas mais recorrentes em [entrevistas para posições DevOps](/technologies/devops/interview-questions/kubernetes-basics). Ambos são projetos Graduated da CNCF que implementam o padrão GitOps, porém diferem significativamente em arquitetura e compromissos técnicos: | Recurso | ArgoCD 3.4 | Flux 2.8 | |---------|-----------|----------| | Arquitetura | Servidor centralizado com UI | Controladores distribuídos por cluster | | Interface web | Dashboard integrado e polido | Sem UI nativa (opções de terceiros) | | Suporte Helm | Renderização de templates no servidor | Integração nativa com Helm SDK | | Multi-cluster | Hub-and-spoke a partir de instância única | Instalação independente por cluster | | RBAC | Nível de aplicação com SSO | Apenas RBAC nativo do Kubernetes | | Automação de imagens | Componente Image Updater separado | Refletor/automação de imagens integrado | | Entrega progressiva | Integração com Argo Rollouts | Integração com Flagger | | Pegada de recursos | Maior (API server, repo server, Redis) | Menor (apenas controladores necessários) | O ArgoCD atende melhor equipes que valorizam visibilidade centralizada, um dashboard web robusto e controle de acesso granular por aplicação com integração SSO. O Flux se adequa a equipes que operam ambientes de borda ou com restrição de recursos, ou que dependem fortemente de funcionalidades nativas do ciclo de vida Helm. Algumas organizações [utilizam ambas as ferramentas](https://codefresh.io/learn/argo-cd/argo-cd-vs-flux-6-key-differences-and-how-to-choose/): ArgoCD para deploys de aplicação onde o dashboard agrega valor operacional, e Flux para componentes de infraestrutura onde a operação distribuída e a fidelidade ao Helm são determinantes. ## Estrutura de Repositórios para GitOps em Produção Um erro frequente na adoção de GitOps é armazenar os manifests Kubernetes junto com o código-fonte da aplicação no mesmo repositório. Separar o repositório de configuração do repositório de aplicação proporciona histórico Git mais limpo, ciclos de revisão independentes e triggers de CI mais simples: ``` # Recommended repository structure my-web-app-config/ base/ deployment.yaml service.yaml kustomization.yaml overlays/ staging/ kustomization.yaml # Patches for staging replica-count.yaml production/ kustomization.yaml # Patches for production replica-count.yaml hpa.yaml ``` O diretório `base` contém os manifests compartilhados entre todos os ambientes. Cada overlay aplica patches específicos do ambiente por meio do [Kustomize](https://kustomize.io/). O pipeline de CI compila e publica a imagem de container, depois atualiza a tag da imagem no repositório de configuração. O ArgoCD detecta o commit e sincroniza a nova versão para o cluster. > **Reconciliação disparada por webhook** > > A configuração de webhook receivers a partir do GitHub, GitLab ou Bitbucket permite disparar a reconciliação do ArgoCD imediatamente após cada push. Isso elimina o intervalo padrão de polling de 3 minutos e proporciona detecção de deploys em menos de 10 segundos. O intervalo de polling deve ser mantido entre 5 e 10 minutos como mecanismo de fallback. ## Funcionalidades do ArgoCD 3.4 Relevantes para Entrevistas O ArgoCD 3.4, lançado em maio de 2026, foca em operações Day 2 com funcionalidades que aparecem frequentemente em entrevistas para posições sênior de DevOps: **Pausar a reconciliação de cluster** permite que operadores congelem a sincronização do ArgoCD durante incidentes em produção. Essa funcionalidade impede que o ArgoCD reverta hotfixes de emergência aplicados diretamente no cluster enquanto a equipe resolve o problema: ```yaml # Pause reconciliation on a specific cluster apiVersion: v1 kind: Secret metadata: name: prod-cluster namespace: argocd labels: argocd.argoproj.io/secret-type: cluster annotations: argocd.argoproj.io/pause-reconciliation: "true" stringData: server: https://prod-cluster.example.com config: | { "tlsClientConfig": { "insecure": false } } ``` **Globs para valores Helm** substituem arrays verbosos de `valueFiles` por padrões de glob, reduzindo conflitos de merge em equipes que mantêm múltiplos arquivos de valores por ambiente: ```yaml # Before ArgoCD 3.4 source: helm: valueFiles: - values.yaml - values-production.yaml - values-production-eu.yaml - values-production-eu-secrets.yaml # With ArgoCD 3.4 value globs source: helm: valueFiles: - values.yaml - values-production*.yaml ``` ## Perguntas Frequentes de Entrevista sobre ArgoCD As perguntas a seguir aparecem regularmente em entrevistas para engenharia DevOps e de plataforma. Elas avaliam a compreensão dos princípios de GitOps, e não apenas a sintaxe do ArgoCD. Para uma preparação mais ampla sobre Kubernetes, o [módulo avançado de Kubernetes](/technologies/devops/interview-questions/kubernetes-advanced) cobre agendamento, contextos de segurança e controladores customizados. > **Profundidade esperada em entrevistas** > > Entrevistas de nível sênior esperam que candidatos expliquem trade-offs e modos de falha, não apenas listem funcionalidades. A preparação deve incluir exemplos concretos de experiência em produção: um incidente em que o selfHeal causou problemas, uma migração que exigiu sync waves ou um rollout multi-cluster que necessitou de entrega progressiva. **"Explique a diferença entre sync automático e sync manual no ArgoCD."** O sync automático aplica alterações ao cluster assim que o ArgoCD detecta uma diferença entre o Git e o estado ativo. O sync manual exige um disparo explícito pela UI, CLI ou API. O sync automático com `selfHeal: true` corrige drift continuamente, sendo o padrão para ambientes de produção onde a consistência de configuração é crítica. O sync manual é mais adequado para ambientes de staging, onde a equipe deseja revisar as alterações antes de aplicá-las. **"O que acontece quando o ArgoCD detecta drift entre o Git e o cluster?"** O ArgoCD compara o estado desejado (manifests do Git renderizados via Helm, Kustomize ou YAML puro) com o estado ativo no cluster. Se o sync automático estiver habilitado com selfHeal, o ArgoCD reverte o cluster imediatamente para o estado declarado no Git. Se o selfHeal estiver desabilitado, o ArgoCD marca a aplicação como OutOfSync e aguarda intervenção manual. O diff dos recursos fica visível na interface, exibindo exatamente quais campos divergiram. **"Como lidar com migrações de banco de dados em um fluxo GitOps?"** Migrações de banco de dados são executadas como Jobs com hook PreSync e um número de sync wave negativo. O Job de migração é executado antes que o ArgoCD faça o deploy da nova versão da aplicação. Se a migração falhar, o sync é abortado e a versão anterior da aplicação permanece em execução. A política `HookSucceeded` remove os Jobs de migração concluídos com sucesso. Para cenários de rollback, os scripts de migração devem ser projetados como operações idempotentes. A revisão do [módulo de segurança de pipelines CI/CD](/technologies/devops/interview-questions/cicd-pipeline-security) complementa a preparação com perguntas relacionadas à proteção de pipelines de deploy. **"Compare ArgoCD e Flux para um ambiente multi-cluster em produção."** O ArgoCD gerencia múltiplos clusters a partir de um único plano de controle, proporcionando visibilidade centralizada pelo dashboard e RBAC unificado entre todos os clusters. O Flux opera de forma independente em cada cluster, reduzindo o raio de impacto, uma vez que uma falha no plano de controle afeta apenas um cluster. Em ambientes com mais de 100 clusters, o modelo centralizado do ArgoCD exige um cluster de gerenciamento robusto, enquanto a abordagem distribuída do Flux elimina esse ponto único de falha. A escolha depende de a equipe priorizar simplicidade operacional (ArgoCD) ou isolamento de falhas (Flux). **"O que é um ApplicationSet e quando utilizá-lo?"** Um ApplicationSet é um controlador que gera recursos Application do ArgoCD a partir de templates. Ele utiliza geradores (cluster, diretório Git, lista, matrix, merge) para produzir múltiplas Applications a partir de uma única definição. Os casos de uso mais comuns incluem: deploy da mesma aplicação em todos os clusters de produção, geração de aplicações por tenant em plataformas SaaS multi-tenant e criação de Applications para cada diretório em um monorepo. O [módulo de fundamentos de Kubernetes](/technologies/devops/interview-questions/kubernetes-basics) oferece a base necessária para compreender os conceitos subjacentes. ## Conclusão - O ArgoCD 3.4 (maio de 2026) introduz a pausa de reconciliação e globs para valores Helm, atendendo necessidades operacionais Day 2 em clusters Kubernetes de produção - O modelo GitOps pull-based elimina a necessidade de expor credenciais do cluster para ferramentas de CI, mantendo os secrets dentro do perímetro do cluster - Sync waves e hooks resolvem a ordenação de deploys: migrações antes dos pods da aplicação, ConfigMaps antes dos Deployments, limpeza após a exclusão - ApplicationSets automatizam o deploy multi-cluster ao gerar recursos Application a partir de labels de cluster, diretórios Git ou listas customizadas - Repositórios de configuração devem ser separados dos repositórios de aplicação para manter histórico Git limpo, ciclos de revisão independentes e triggers de CI mais simples - O ArgoCD se adequa ao gerenciamento multi-cluster centralizado com dashboard e RBAC; o Flux se adequa a ambientes distribuídos, com restrição de recursos ou dependência pesada de Helm - A preparação para entrevistas sobre GitOps deve cobrir detecção de drift, estratégias de sync, modos de falha e cenários concretos de produção, em vez de definições memorizadas --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/pt/blog/devops/argocd-gitops-kubernetes-continuous-deployment-interview-questions