Pular para o conteúdo principal

Questão de Engenharia de Software — Github e Gitlab — FCC 2026

Engenharia de SoftwareGithub e Gitlab
Código
fc142099
Banca
FCC
Órgão
MPE SE
Ano
2026
Cargo
Ana ( )

Uma equipe de TI quer que merges na branch main disparem automaticamente deploy em um cluster Kubernetes via GitHub Actions, mas com segredos seguros (como KUBE_CONFIG) acessíveis somente no job de deploy.

 

Nesse cenário, a prática correta é

  1. Ausar runs-on: self-hosted que já garante que segredos nunca vazem.
  2. Bexecutar deploy com workflow_dispatch manual, com segredos configurados por meio de vault: secrets.
  3. Cdefinir secrets.KUBE_CONFIG em todos os jobs, inclusive de testes, pois o GitHub oculta valores nos logs.
  4. Dconfigurar o job de deploy com environment: production e usar segredos apenas nesse ambiente.
  5. Eguardar segredos em variáveis de ambiente no código-fonte para facilitar a execução.
Revelar gabarito e comentário

GabaritoD — configurar o job de deploy com environment: production e usar segredos apenas nesse ambiente.

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

GitHub Actions: Segredos e Ambientes de Deploy

Gabarito: letra D. A prática correta é configurar o job de deploy com environment: production e usar os segredos apenas nesse ambiente, pois o GitHub Actions permite associar segredos a ambientes específicos, garantindo que eles só fiquem disponíveis nos jobs que referenciam aquele ambiente — exatamente o que o enunciado pede (segredos como KUBE_CONFIG acessíveis somente no job de deploy).

O GitHub Actions é o serviço de CI/CD integrado ao GitHub que automatiza builds, testes e deploys a partir do repositório. Para proteger informações sensíveis, como o conteúdo de um arquivo kubeconfig usado para autenticar no Kubernetes, a plataforma oferece o recurso de segredos (secrets). Esses segredos são variáveis criptografadas que podem ser definidas em três níveis: repositório, ambiente ou organização. A grande sacada é o nível de ambiente (environment): você pode criar ambientes como production, staging, development, e associar a cada um um conjunto próprio de segredos e regras de proteção (como exigir aprovação manual para deploys).

No workflow, um job declara environment: production e, a partir daí, ele enxerga os segredos daquele ambiente. Jobs que não referenciam esse ambiente não têm acesso a esses segredos. Isso resolve o problema do enunciado: o job de deploy usa environment: production e acessa secrets.KUBE_CONFIG; os jobs de teste, que não declaram esse ambiente, simplesmente não conseguem ler o segredo — mesmo que o workflow inteiro rode no mesmo repositório. É uma forma nativa e segura de isolar credenciais por etapa do pipeline.

A alternativa D é a única que combina os dois requisitos: disparo automático no merge para main (o workflow pode ter on: push: branches: [main]) e segredos restritos ao job de deploy via ambiente. As demais alternativas ou ignoram o isolamento por ambiente, ou propõem práticas inseguras, como veremos a seguir.

NÃO CAIA NESSA!

A banca explora a confusão entre segredos de repositório (visíveis a todos os jobs do workflow) e segredos de ambiente (restritos a jobs que declaram aquele ambiente). Muitos candidatos acham que basta ocultar os valores nos logs (alternativa C) ou que self-hosted resolve tudo (alternativa A) — mas a forma correta de limitar o acesso é justamente o environment.

Prática

Correto?

Justificativa

runs-on: self-hosted

❌

Não protege segredos; apenas define o runner de execução.

workflow_dispatch manual + vault: secrets

❌

Gatilho manual não atende à automação; sintaxe inválida no GitHub Actions.

secrets.KUBE_CONFIG em todos os jobs

❌

Expõe o segredo a jobs desnecessários; ocultar logs não impede exfiltração.

environment: production no job de deploy

✅

Restringe o segredo ao ambiente declarado; permite disparo automático no merge.

Segredos em variáveis no código-fonte

❌

Violação grave; credenciais ficam versionadas e acessíveis a qualquer pessoa.

Segredos no GitHub Actions
  • 1Níveis de definição
    • Repositório (visível a todos os jobs)
    • Ambiente (restrito ao job que declara)
    • Organização
  • 2Ambiente (environment)
    • Segredos próprios
    • Regras de proteção (aprovação manual)
  • 3Prática correta
    • Job de deploy com environment: production
    • Acesso a secrets.KUBE_CONFIG só nesse job
LEVEL · soulevel.com.br

Alternativa A — ❌ Incorreta

Usar runs-on: self-hosted não tem relação com a proteção de segredos. self-hosted apenas define que o job será executado em um runner próprio da organização, em vez de um runner hospedado pelo GitHub. Segredos continuam sendo gerenciados da mesma forma e podem vazar se forem usados em jobs indevidos ou se o runner não for seguro. A alternativa confunde infraestrutura de execução com controle de acesso a segredos.

Alternativa B — ❌ Incorreta

workflow_dispatch é um gatilho manual (o workflow só roda quando alguém clica em "Run workflow"), o que contraria o requisito de disparo automático no merge. Além disso, vault: secrets não é uma sintaxe válida do GitHub Actions — segredos são referenciados como secrets.NOME. A alternativa mistura conceitos de outras ferramentas (como GitLab CI/CD) com a sintaxe do GitHub.

Alternativa C — ❌ Incorreta

Definir secrets.KUBE_CONFIG em todos os jobs, inclusive nos de teste, é exatamente o que o enunciado quer evitar. Embora o GitHub oculte os valores nos logs, isso não impede que um job malicioso ou comprometido exfiltre o segredo (por exemplo, enviando-o para um servidor externo). A prática correta é limitar o escopo do segredo, não apenas ocultar sua exibição.

Alternativa D — ✅ Correta ⟵ GABARITO

Configurar o job de deploy com environment: production e usar segredos apenas nesse ambiente é a prática recomendada. O GitHub Actions permite criar ambientes com segredos próprios; um job só acessa esses segredos se declarar o ambiente correspondente. Assim, KUBE_CONFIG fica disponível somente no job de deploy, atendendo ao requisito de segurança. Além disso, o workflow pode ser configurado para disparar automaticamente no merge para main (via on: push), cumprindo o requisito de automação.

Alternativa E — ❌ Incorreta

Guardar segredos em variáveis de ambiente no código-fonte é uma violação grave de segurança. Qualquer pessoa com acesso ao repositório (ou ao histórico de commits) poderia ler as credenciais. Segredos devem ser armazenados exclusivamente no gerenciador de segredos da plataforma (GitHub Secrets), nunca versionados no código.

Gabarito: letra D — a única que combina deploy automático com isolamento de segredos por ambiente.

Link permanente: /questoes/fc142099