# Perguntas de Entrevista sobre Pipelines CI/CD: GitHub Actions, GitLab CI e Jenkins em 2026

> Guia completo de preparação para entrevistas técnicas sobre CI/CD em 2026. Exemplos práticos de configuração de pipelines com GitHub Actions, GitLab CI e Jenkins, tabela comparativa entre plataformas e boas práticas de segurança na cadeia de suprimentos.

- Published: 2026-05-18
- Updated: 2026-05-18
- Author: SharpSkill
- Tags: ci/cd, github actions, gitlab ci, jenkins, devops, interview questions, pipeline
- Reading time: 12 min

---

Pipelines de integração e entrega contínua deixaram de ser diferencial competitivo e se tornaram pré-requisito obrigatório em processos seletivos para engenharia de software, DevOps e SRE. Em 2026, recrutadores avaliam não apenas o domínio teórico dos conceitos de CI/CD, mas a capacidade de configurar, depurar e otimizar pipelines nas ferramentas mais utilizadas pelo mercado. Três plataformas concentram a grande maioria das perguntas em entrevistas técnicas: GitHub Actions, GitLab CI e Jenkins.

Este guia reúne as perguntas mais recorrentes em processos seletivos, acompanhadas de exemplos de configuração prontos para análise e uma visão comparativa entre as três ferramentas. O objetivo é oferecer uma base sólida de preparação que vai além da memorização de sintaxe, abordando os padrões arquiteturais e as decisões de projeto que entrevistadores esperam de candidatos qualificados.

> **Dica de preparação para entrevistas**
>
> Entrevistadores técnicos valorizam respostas que conectam teoria à prática. Em vez de recitar definições de documentação, é recomendável estruturar as respostas com exemplos concretos: "No pipeline do projeto X, utilizamos matrix builds para validar compatibilidade entre Node.js 20 e 22, o que reduziu regressões em 40%" demonstra experiência real e capacidade analítica. Ter familiaridade com pelo menos duas das três plataformas abordadas neste artigo é considerado o mínimo esperado para posições pleno e sênior.

## GitHub Actions: estrutura de workflows e perguntas de entrevista

O GitHub Actions organiza pipelines por meio de arquivos YAML armazenados no diretório `.github/workflows/` do repositório. A arquitetura é **baseada em jobs**, que por padrão executam em paralelo. Para estabelecer dependências entre jobs, utiliza-se a diretiva `needs`. Esse modelo favorece a velocidade de execução e permite granularidade no controle de fluxo.

Uma das perguntas mais frequentes em entrevistas é: "Projete um pipeline CI completo com etapas de lint, testes em múltiplas versões e deploy condicional." A configuração a seguir ilustra a resposta esperada:

```yaml
# .github/workflows/ci.yml
name: CI Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint              # waits for lint to pass
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [20, 22]       # runs tests on both versions
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
          cache: npm
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production  # requires approval
    steps:
      - uses: actions/checkout@v4
      - run: ./deploy.sh
```

Os elementos-chave que entrevistadores esperam na explicação desse pipeline são:

- **`needs: lint`** cria uma dependência explícita entre os jobs de teste e lint. Sem essa diretiva, ambos executariam simultaneamente, desperdiçando recursos caso o lint falhasse
- **`strategy.matrix`** dispara a execução dos testes em Node.js 20 e 22 ao mesmo tempo, validando compatibilidade entre versões de runtime em uma única execução do workflow
- **`environment: production`** integra com os environments protegidos do GitHub, permitindo configurar aprovações manuais, restrições de branch e tempo de espera antes do deploy
- **`if: github.ref == 'refs/heads/main'`** garante que o deploy ocorra exclusivamente na branch principal, prevenindo implantações acidentais a partir de branches de desenvolvimento
- Cada job executa em um **runner independente**, o que significa que o workspace não é compartilhado entre jobs — cada um precisa do próprio `checkout`

Outra pergunta recorrente envolve **caching de dependências**: "Como reduzir o tempo de instalação de pacotes entre execuções?" A resposta deve mencionar que a opção `cache: npm` do `actions/setup-node` detecta automaticamente o `package-lock.json` e restaura o cache de dependências, eliminando reinstalações desnecessárias.

## GitLab CI: configuração de pipelines e perguntas frequentes

O GitLab CI adota um modelo **baseado em stages**: os stages são sequenciais por padrão, mas jobs dentro de um mesmo stage executam em paralelo. Toda a configuração reside em um único arquivo `.gitlab-ci.yml` na raiz do repositório. Essa abordagem centralizada facilita a manutenção e o versionamento do pipeline.

A pergunta comparativa mais comum em entrevistas é: "Qual a principal diferença entre o modelo de execução do GitLab CI e do GitHub Actions?" A resposta deve destacar que o GitHub Actions paraleliza jobs por padrão (exigindo `needs` para sequenciamento), enquanto o GitLab CI sequencia stages automaticamente (permitindo paralelismo apenas dentro de cada stage, ou utilizando `needs` para criar um DAG).

```yaml
# .gitlab-ci.yml
stages:
  - validate
  - test
  - deploy

variables:
  NODE_VERSION: "22"

lint:
  stage: validate
  image: node:${NODE_VERSION}
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm run lint

unit-tests:
  stage: test
  image: node:${NODE_VERSION}
  parallel:
    matrix:
      - NODE_VERSION: ["20", "22"]
  script:
    - npm ci
    - npm test
  artifacts:
    reports:
      junit: coverage/junit.xml
    expire_in: 7 days

deploy-production:
  stage: deploy
  image: alpine:latest
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual                   # manual gate
  environment:
    name: production
    url: https://app.example.com
  script:
    - ./deploy.sh
```

Os aspectos mais cobrados em entrevistas sobre GitLab CI incluem:

- **Artifacts versus cache**: artifacts são resultados de builds (relatórios JUnit, binários compilados) que persistem entre stages e podem ser baixados pela interface do GitLab. Cache armazena dependências para acelerar execuções futuras. Confundir os dois conceitos é um erro frequente em entrevistas
- **`rules` versus `only/except`**: a diretiva `rules` é o padrão moderno, oferecendo condições compostas com `if`, `changes` e `exists`. A sintaxe `only/except` está depreciada desde o GitLab 13 e seu uso em respostas de entrevista sinaliza conhecimento desatualizado
- **`when: manual`** funciona como um gate de aprovação, impedindo deploys automáticos para produção. Equivale ao conceito de environments com reviewers obrigatórios no GitHub Actions
- **`parallel:matrix`** é a versão GitLab do `strategy.matrix`, gerando jobs paralelos para cada combinação definida na matriz
- **Variáveis predefinidas** como `CI_COMMIT_REF_SLUG`, `CI_PIPELINE_ID` e `CI_JOB_TOKEN` eliminam a necessidade de configuração manual em diversos cenários de automação

## Jenkins: pipeline declarativo e o que esperar na entrevista

O Jenkins continua presente em diversas organizações de grande porte devido à sua flexibilidade e ao vasto ecossistema de plugins. A principal particularidade do Jenkins em relação às outras duas plataformas é o modelo **exclusivamente self-hosted**, o que introduz perguntas adicionais sobre gerenciamento de infraestrutura, agentes e escalabilidade.

O formato declarativo do Jenkinsfile é o mais cobrado em entrevistas pela clareza estrutural e previsibilidade:

```groovy
// Jenkinsfile
pipeline {
    agent any

    tools {
        nodejs 'node-22'       // configured in Jenkins Global Tool
    }

    environment {
        CI = 'true'
        DEPLOY_ENV = credentials('deploy-env-secret')
    }

    stages {
        stage('Install') {
            steps {
                sh 'npm ci'
            }
        }

        stage('Lint & Test') {
            parallel {             // parallel execution
                stage('Lint') {
                    steps {
                        sh 'npm run lint'
                    }
                }
                stage('Test') {
                    steps {
                        sh 'npm test'
                    }
                    post {
                        always {
                            junit 'coverage/junit.xml'
                        }
                    }
                }
            }
        }

        stage('Deploy') {
            when {
                branch 'main'
            }
            input {
                message 'Deploy to production?'
            }
            steps {
                sh './deploy.sh'
            }
        }
    }

    post {
        failure {
            mail to: 'team@example.com',
                 subject: "Build failed: ${env.JOB_NAME}",
                 body: "Check ${env.BUILD_URL}"
        }
    }
}
```

As perguntas de entrevista sobre Jenkins geralmente abordam:

- **Pipeline declarativo versus scripted**: o declarativo usa blocos estruturados (`pipeline {}`, `stages {}`, `steps {}`) com sintaxe fixa e previsível. O scripted oferece acesso completo ao Groovy, permitindo lógica condicional complexa, loops e funções customizadas. Na prática, o declarativo é recomendado para a maioria dos cenários, reservando blocos `script {}` para situações específicas
- **`credentials('deploy-env-secret')`** injeta secrets armazenados no Jenkins Credentials Plugin como variáveis de ambiente, mascarando os valores nos logs automaticamente. Jenkins suporta vários tipos de credential: texto secreto, usuário/senha, arquivo e certificado SSH
- **`parallel {}`** dentro de um stage permite a execução simultânea de lint e testes, reduzindo significativamente o tempo total do pipeline
- **`input`** cria uma pausa interativa que exige aprovação manual antes do deploy, funcionando como equivalente do `environment` protegido no GitHub Actions e do `when: manual` no GitLab CI
- **`post { failure {} }`** define ações pós-execução em caso de falha, como notificações por e-mail com detalhes do build para diagnóstico rápido
- **Arquitetura master/agent**: permite distribuir builds em múltiplas máquinas. Agentes podem ser físicos, VMs ou containers efêmeros via plugin Kubernetes, escalando sob demanda

## Gerenciamento de secrets entre plataformas

A gestão segura de credenciais é um tema obrigatório em entrevistas para posições de DevOps e segurança. Cada plataforma implementa seu próprio modelo de armazenamento e injeção de secrets.

No **GitHub Actions**, secrets são configurados em três níveis: repositório, organização e environment. Secrets de environment oferecem o maior nível de proteção, pois só ficam disponíveis para jobs vinculados ao environment correspondente. O acesso ocorre via `${{ secrets.NOME_DO_SECRET }}` e os valores nunca aparecem nos logs.

No **GitLab CI**, variáveis CI/CD podem ser marcadas como "protegidas" (disponíveis apenas em branches protegidas) e "mascaradas" (ocultadas nos logs). A hierarquia de variáveis — instância, grupo, projeto e pipeline — permite governança granular em organizações com múltiplos times.

No **Jenkins**, o Credentials Plugin armazena secrets de forma criptografada. A função `credentials()` na seção `environment` do Jenkinsfile injeta os valores como variáveis de ambiente. Para cenários corporativos, Jenkins integra com cofres externos como HashiCorp Vault e AWS Secrets Manager.

Uma pergunta avançada comum é: "Como evitar secrets de longa duração em pipelines?" A resposta deve mencionar **OIDC (OpenID Connect)**: tanto GitHub Actions quanto GitLab CI suportam federação de identidade, permitindo que o pipeline obtenha tokens temporários de provedores cloud (AWS, GCP, Azure) sem armazenar chaves de acesso permanentes.

## Otimização de pipelines e estratégias de caching

Perguntas sobre otimização avaliam a experiência prática do candidato com pipelines em escala. A pergunta típica é: "O pipeline do time leva 25 minutos para executar. Como reduziria esse tempo?"

As estratégias mais eficazes incluem:

- **Caching agressivo de dependências**: no GitHub Actions, utilizar `cache: npm` no `setup-node` ou `actions/cache` para diretórios como `node_modules`, `.m2` ou `.gradle`. No GitLab CI, chaves dinâmicas baseadas no lockfile (`$CI_COMMIT_REF_SLUG` ou hash do `package-lock.json`) garantem invalidação adequada
- **Paralelização de stages independentes**: executar lint e testes unitários simultaneamente quando não há dependência entre eles. No Jenkins, o bloco `parallel {}` resolve esse cenário; no GitLab CI, jobs dentro do mesmo stage já executam em paralelo
- **Execução condicional**: no GitLab CI, `rules: changes` dispara jobs apenas quando arquivos relevantes foram modificados. No GitHub Actions, path filters no trigger `on.push.paths` alcançam resultado similar
- **Separação de testes**: executar testes unitários (rápidos) antes de testes de integração (lentos), obtendo feedback antecipado em caso de falha
- **Builds incrementais**: quando a ferramenta de build suporta, compilar apenas os módulos modificados em vez de reconstruir todo o projeto

## Segurança e proteção da cadeia de suprimentos

Segurança de pipelines CI/CD ganhou destaque nos últimos anos após incidentes de supply chain attacks que comprometeram dependências amplamente utilizadas. Em entrevistas para posições sênior e DevSecOps, esse tema é praticamente obrigatório.

A pergunta mais frequente é: "Como proteger um pipeline contra ataques de supply chain?" A primeira medida é o **pinning de actions por SHA do commit** no GitHub Actions:

```yaml
# .github/workflows/secure.yml
steps:
  # Vulnerable: tag can be moved to malicious commit
  - uses: actions/checkout@v4

  # Secure: pinned to exact commit SHA
  - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
```

Tags como `v4` são referências mutáveis: o mantenedor do repositório (ou uma conta comprometida) pode movê-las para apontar para um commit contendo código malicioso. O SHA do commit é imutável, garantindo que o código executado seja exatamente a versão auditada. Ferramentas como Dependabot e Renovate Bot automatizam a atualização dos SHAs, mantendo segurança e atualização simultâneas.

Outras práticas de segurança avaliadas em entrevistas:

- **Princípio do menor privilégio**: restringir as permissões do `GITHUB_TOKEN` no nível do workflow usando a diretiva `permissions`. Em vez de conceder acesso amplo, declarar explicitamente apenas as permissões necessárias
- **Proteção contra injeção de comandos**: nunca utilizar expressões como `${{ github.event.pull_request.title }}` diretamente em comandos shell, pois um título de PR malicioso pode injetar comandos arbitrários
- **Isolamento de runners**: runners self-hosted devem executar em containers efêmeros, evitando que artefatos ou processos de uma execução contaminem a próxima
- **Scanning de dependências**: Dependabot (GitHub), Dependency Scanning (GitLab) e OWASP Dependency-Check (Jenkins) identificam vulnerabilidades conhecidas em bibliotecas do projeto
- **Rotação periódica de secrets**: credenciais de deploy, tokens de API e chaves de acesso devem ser rotacionados em intervalos regulares, preferencialmente de forma automatizada

## Tabela comparativa entre plataformas

Entrevistas que pedem comparações diretas entre ferramentas exigem uma visão consolidada das diferenças e pontos fortes de cada plataforma. A tabela a seguir serve como referência rápida:

| Característica | GitHub Actions | GitLab CI | Jenkins |
|---|---|---|---|
| Arquivo de configuração | `.github/workflows/*.yml` | `.gitlab-ci.yml` | `Jenkinsfile` |
| Modelo de execução | Baseado em jobs (paralelo por padrão) | Baseado em stages (stages sequenciais) | Baseado em stages (flexível) |
| Hospedagem de runners | GitHub-hosted + self-hosted | Compartilhados GitLab.com + self-hosted | Somente self-hosted |
| Armazenamento de secrets | Secrets de repositório/org/environment | Variáveis CI/CD (protegidas) | Plugin de credentials |
| Matrix builds | `strategy.matrix` | `parallel:matrix` | `matrix` (via plugin) |
| Aprovação manual | `environment` + reviewers obrigatórios | `when: manual` | Diretiva `input` |
| Marketplace | 20.000+ Actions no Marketplace | Catálogo de CI/CD Components | 1.800+ plugins |
| Recursos de IA | Copilot for Actions (preview) | Duo CI Expert Agent (beta) | Plugins da comunidade |
| Precificação | Gratuito para repos públicos, por minuto para privados | 400 minutos CI/CD gratuitos, depois por faixa | Gratuito (open source), autogerenciado |

Dominar essa tabela e saber articular quando cada plataforma é mais adequada — considerando porte da empresa, requisitos de compliance, orçamento e stack existente — demonstra maturidade técnica e visão arquitetural.

## Pratique com perguntas específicas por plataforma

A preparação mais eficaz combina estudo conceitual com prática direcionada. Os seguintes recursos permitem aprofundar o conhecimento em cada área abordada neste artigo: [fundamentos de CI/CD](/technologies/devops/interview-questions/ci-cd-fundamentals) para consolidar a base teórica, [GitHub Actions](/technologies/devops/interview-questions/github-actions) para dominar workflows e actions, [GitLab CI](/technologies/devops/interview-questions/gitlab-ci) para stages e artifacts, [Jenkins](/technologies/devops/interview-questions/jenkins) para pipelines declarativos e arquitetura master/agent, e [perguntas essenciais de entrevista DevOps](/blog/devops/essential-devops-interview-questions) para uma visão abrangente da área.

## Conclusão

A preparação para entrevistas sobre pipelines CI/CD em 2026 exige muito mais do que conhecer a sintaxe de arquivos YAML ou Groovy. Recrutadores avaliam a capacidade de projetar sistemas de entrega robustos, seguros e eficientes, considerando as particularidades de cada organização.

Os pontos fundamentais para uma preparação sólida incluem:

- **Dominar a sintaxe e o modelo de execução** de pelo menos duas das três plataformas principais, entendendo como jobs, stages e dependências se comportam em cada uma
- **Compreender o gerenciamento de secrets** em diferentes níveis (repositório, organização, environment) e conhecer alternativas como OIDC para eliminar credenciais de longa duração
- **Saber comparar plataformas de forma objetiva**, articulando vantagens e limitações conforme o contexto — porte da empresa, requisitos de compliance, orçamento e integração com o stack existente
- **Implementar práticas de segurança** como pinning por SHA, princípio do menor privilégio, proteção contra injeção de comandos e scanning automatizado de dependências
- **Otimizar pipelines com estratégias concretas**: caching de dependências, paralelização de stages, execução condicional e separação de testes por velocidade de feedback
- **Preparar exemplos práticos** de pipelines que projetou, problemas que diagnosticou e melhorias mensuráveis que implementou — métricas como redução de tempo de build ou diminuição de incidentes em produção fortalecem qualquer resposta
- **Estruturar respostas comportamentais** no formato STAR (Situação, Tarefa, Ação, Resultado) com dados concretos, conectando experiências anteriores aos desafios da posição pretendida

O candidato que demonstra compreensão profunda desses temas, analisa pipelines com olhar crítico e articula decisões técnicas com fundamentação sólida se posiciona de forma competitiva no mercado de engenharia de software e DevOps.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pt/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins