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

Perguntas de entrevista sobre pipelines CI/CD estão entre os tópicos mais frequentes em processos seletivos DevOps em 2026. Com GitHub Actions processando mais de 71 milhões de jobs por dia e lançando a execução paralela de steps em junho de 2026, GitLab CI alcançando a versão 19 com seu Secrets Manager nativo, e Jenkins mantendo uma taxa de adoção de 28%, os entrevistadores esperam que os candidatos demonstrem fluência prática nas três plataformas.

Estrutura de Workflows e Triggers no GitHub Actions

O GitHub Actions organiza a automação em torno de workflows, jobs e steps. Um workflow é um arquivo YAML armazenado em .github/workflows/ que define quando e como a automação é executada. Cada workflow contém um ou mais jobs, e cada job é executado em um runner separado.

Uma pergunta comum em entrevistas solicita que os candidatos expliquem a relação entre triggers on, dependências de jobs e a palavra-chave needs.

# .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

Este workflow demonstra três conceitos-chave: a palavra-chave needs cria um grafo de dependências entre jobs, a estratégia matrix permite testar em paralelo em múltiplas versões do Node.js, e a palavra-chave environment condiciona deploys a aprovação manual.

Steps Paralelos no GitHub Actions

O GitHub Actions lançou a execução paralela de steps em 25 de junho de 2026, atendendo a uma das funcionalidades mais solicitadas. Anteriormente, todos os steps dentro de um job eram executados sequencialmente. A nova funcionalidade introduz quatro palavras-chave que permitem execução concorrente dentro de um único job.

# .github/workflows/parallel-steps.yml
name: Build with Parallel Steps

on:
  push:
    branches: [main]

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

      # Run lint and typecheck in parallel
      - name: lint
        run: npm run lint
        background: true

      - name: typecheck
        run: npm run typecheck
        background: true

      - wait-all:              # wait for both to complete

      # Or use the parallel shorthand
      - parallel:
          - name: build-frontend
            run: npm run build:frontend
          - name: build-backend
            run: npm run build:backend

      - run: npm run deploy

A palavra-chave background: true inicia um step de forma assíncrona e continua imediatamente para o próximo step. A palavra-chave wait-all pausa a execução até que todos os steps em segundo plano sejam concluídos. A palavra-chave parallel fornece uma sintaxe abreviada que executa múltiplos steps simultaneamente e aguarda a conclusão de todos antes de continuar.

Existem duas palavras-chave adicionais: wait direciona steps nomeados específicos em segundo plano, e cancel encerra elegantemente um step em segundo plano quando não é mais necessário (útil para interromper serviços de longa execução).

Configuração de Pipeline GitLab CI com Stages

O GitLab CI usa um arquivo .gitlab-ci.yml na raiz do repositório. Diferentemente do GitHub Actions, onde jobs são executados independentemente por padrão, o GitLab CI organiza jobs em stages que são executados sequencialmente, enquanto jobs dentro do mesmo stage são executados em paralelo.

Os entrevistadores frequentemente pedem aos candidatos para converter um workflow do GitHub Actions em um pipeline GitLab CI, ou vice-versa.

# .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

Diferenças-chave em relação ao GitHub Actions: stages impõem ordem de execução globalmente, a palavra-chave parallel:matrix gerencia builds matriciais, e artifacts:reports:junit integra resultados de testes diretamente nas views de merge request.

O GitLab 19.0 (maio de 2026) introduziu o Secrets Manager em open beta, fornecendo armazenamento nativo de secrets sem serviços externos como HashiCorp Vault. O GitLab 19.2 (julho de 2026) tornou as políticas de execução de pipelines agendados geralmente disponíveis, permitindo que equipes imponham scans de compliance ou verificações de dependências em uma cadência fixa em múltiplos projetos a partir de uma única definição de política.

Sintaxe de Pipeline Declarativo Jenkins

O Jenkins usa um Jenkinsfile armazenado na raiz do repositório. A sintaxe de pipeline declarativo, recomendada como padrão em 2026, fornece tratamento estruturado de erros e um layout claro baseado em stages.

Uma pergunta frequente em entrevistas: explicar a diferença entre pipelines declarativos e com script, e quando usar cada um.

// 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}"
        }
    }
}

Pipelines declarativos impõem estrutura através de blocos obrigatórios pipeline, agent e stages. A diretiva parallel dentro de um stage executa lint e testes simultaneamente. A diretiva input pausa a execução para aprovação manual, similar aos environments do GitHub Actions e gates manuais do GitLab. O Jenkins requer Java 21 desde janeiro de 2026, então os ambientes de pipeline devem considerar essa dependência de runtime.

Gestão de Secrets nas Plataformas CI/CD

Toda entrevista de CI/CD inclui perguntas sobre gestão de secrets. Cada plataforma lida com credenciais de forma diferente, e entender as implicações de segurança é fundamental.

GitHub Actions armazena secrets no nível do repositório, environment ou organização. Secrets são mascarados automaticamente nos logs, mas o modelo de escopo atual tem limitações. O roadmap de segurança 2026 introduz secrets com escopo que vinculam credenciais a contextos de execução explícitos, abordando o risco de acesso excessivamente amplo.

GitLab CI fornece variáveis CI/CD com regras de proteção. Variáveis protegidas são injetadas apenas em pipelines executados em branches ou tags protegidos. O GitLab 19.0 introduziu o Secrets Manager, permitindo que equipes armazenem e referenciem secrets nativamente sem vaults externos. Secrets têm escopo para projetos ou grupos e são acessíveis apenas para jobs que os solicitam explicitamente.

Jenkins usa o plugin Credentials com múltiplos tipos de credenciais (usuário/senha, chave SSH, texto secreto, certificado). O helper credentials() em pipelines declarativos vincula secrets a variáveis de ambiente, e credenciais no nível de Folder limitam o acesso a projetos específicos.

A resposta crítica em entrevista: nunca codificar secrets em arquivos de pipeline, sempre usar a gestão nativa de secrets da plataforma, rotacionar credenciais regularmente, e preferir tokens de curta duração a chaves de API de longa duração.

Otimização de Pipeline e Estratégias de Caching

Pipelines lentos impactam diretamente a produtividade dos desenvolvedores. Entrevistadores testam se os candidatos conseguem diagnosticar e corrigir gargalos de performance em sistemas CI/CD.

Três técnicas de otimização universais se aplicam às três plataformas:

Caching de dependências evita re-download de pacotes a cada execução. GitHub Actions usa actions/cache ou suporte de cache integrado nas actions de setup. GitLab CI usa cache com uma estratégia de chave. Jenkins depende da persistência do workspace ou dos comandos stash/unstash.

Execução paralela divide o trabalho entre múltiplos runners. GitHub Actions agora suporta tanto jobs paralelos (estratégia matrix) quanto steps paralelos (palavras-chave background/parallel). GitLab CI usa parallel:matrix, e Jenkins usa a diretiva parallel. A granularidade correta de divisão depende do projeto: muitos jobs paralelos desperdiçam tempo de startup de runners, poucos deixam capacidade ociosa.

Execução condicional pula stages desnecessários. As três plataformas suportam isso: GitHub Actions com expressões if, GitLab CI com rules, e Jenkins com diretivas when. Um pipeline bem projetado pula stages de deploy em branches de feature e evita disparar suítes de teste completas para mudanças apenas de lint.

Segurança e Proteção da Supply Chain CI/CD

Ataques à supply chain direcionados a sistemas CI/CD aumentaram significativamente em 2025, com incidentes afetando tj-actions/changed-files e outras GitHub Actions populares. Perguntas de entrevista agora regularmente avaliam candidatos sobre estratégias de hardening.

Fixar versões de actions em SHAs de commit específicos em vez de tags para prevenir ataques de tag-hijacking:

# .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

O GitLab CI aborda preocupações de supply chain através de componentes CI/CD com atestação SLSA Level 1 (disponível desde o GitLab 18.1), fornecendo proveniência mais clara ao montar pipelines a partir de componentes reutilizáveis. Tags de container imutáveis (GitLab 18.2) previnem substituição de imagens após publicação.

Para Jenkins, o mecanismo de Shared Library deve usar um repositório dedicado com proteção de branch, requisitos de revisão de código e commits assinados. A Comissão Europeia lançou um programa de Bug Bounty do Jenkins através do YesWeHack, refletindo o papel crítico da plataforma nas supply chains corporativas.

Comparação Cross-Platform para Preparação de Entrevistas

Esta tabela comparativa cobre as diferenças mais frequentemente avaliadas em entrevistas. A pergunta de acompanhamento tipicamente pergunta: "Qual plataforma você escolheria para um novo projeto, e por quê?" A resposta depende das ferramentas existentes, tamanho da equipe, requisitos de compliance, e se a organização prefere infraestrutura gerenciada (GitHub/GitLab) ou controle total (Jenkins).

Sources

• Actions steps can now be run in parallel (GitHub Changelog, junho de 2026)
• GitLab 19.0 release notes (GitLab Docs, maio de 2026)
• GitLab 19.2 release notes (GitLab Docs, julho de 2026)
• Jenkins Changelog (Jenkins.io, agosto de 2026)
• GitHub Actions 2026 Security Roadmap (GitHub Blog)

Para praticar essas perguntas de forma prática, consultar os módulos de fundamentos CI/CD e GitHub Actions, ou explorar perguntas específicas de GitLab CI e Jenkins. Para preparação DevOps mais ampla, o guia de perguntas essenciais de entrevista DevOps cobre o escopo completo de tópicos além de CI/CD.

Pontos-Chave para Entrevistas de CI/CD Pipeline

• Steps paralelos do GitHub Actions (background, wait-all, parallel) foram lançados em junho de 2026, permitindo execução concorrente dentro de um único job enquanto compartilham o runner, checkout e workspace
• GitLab 19.x introduziu o Secrets Manager nativo (open beta, maio de 2026) e tornou as políticas de execução de pipelines agendados geralmente disponíveis (julho de 2026), reduzindo dependência de ferramentas externas
• Jenkins 2.574+ desacoplou plugins core incluindo JUnit e Mailer do arquivo WAR, requerendo instalação explícita para instâncias sem acesso ao centro de atualizações
• Gestão de secrets é o tópico de segurança mais frequentemente testado nas três plataformas: demonstrar conhecimento de secrets com escopo, variáveis protegidas e estratégias de rotação de credenciais
• Otimização de pipeline através de caching, paralelização e execução condicional se aplica universalmente e sinaliza experiência prática em produção para os entrevistadores
• Preparar pelo menos uma configuração de pipeline funcional por plataforma, focando em padrões do mundo real em vez de exemplos simples