Questão de Engenharia de Software — Geral — FGV 2026
Engenharia de Software›Geral
Código
fg157227
Banca
FGV
Órgão
TJ RJ
Ano
2026
Cargo
AJ ( )
Durante a implantação de uma infraestrutura em nuvem via Terraform, uma equipe de DevOps percebe que credenciais sensíveis estão expostas em arquivos .tf versionados no GitHub. Após essa identificação, a equipe precisará ocultar as credenciais sensíveis para evitar a sua exposição. Para que a equipe de DevOps consiga cumprir esse item, a ação a ser tomada, dentro das melhores práticas, deverá ser a de:
Aintegrar o pipeline com uma ferramenta gerenciadora de segredos;
Bcriptografar os arquivos .tf com ferramentas como GPG e compartilhar as chaves por e-mail;
Carmazenar credenciais em arquivos .env e versioná-los junto com o código para facilitar o acesso;
Dutilizar comentários no código para indicar onde estão os dados sensíveis, facilitando a revisão manual;
Eutilizar variáveis locais no Terraform para armazenar credenciais, pois elas não são exportadas para o plano de execução.
Revelar gabarito e comentário▾
GabaritoA — integrar o pipeline com uma ferramenta gerenciadora de segredos;
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”.
Gerenciamento de Segredos em Infraestrutura como Código
Gabarito: letra A. A melhor prática para ocultar credenciais expostas em arquivos Terraform versionados é integrar o pipeline com uma ferramenta gerenciadora de segredos (como Vault, AWS Secrets Manager, Azure Key Vault), que centraliza o armazenamento e o acesso a dados sensíveis, evitando que fiquem no código-fonte. As demais alternativas violam princípios de segurança ou são ineficazes.
O problema descrito é clássico em Infraestrutura como Código (IaC): credenciais hardcoded em arquivos .tf versionados. A solução correta não é criptografar os arquivos nem usar variáveis locais, mas sim externalizar os segredos para um cofre gerenciado, acessado dinamicamente pelo Terraform durante a execução. Isso segue o princípio de segurança por design e o conceito de shift left do DevSecOps, que integra segurança desde o início do ciclo de desenvolvimento.
Uma ferramenta gerenciadora de segredos oferece:
Centralização: credenciais em um único local seguro, com controle de acesso e auditoria.
Rotação automática: chaves podem ser trocadas periodicamente sem alterar o código.
Integração com pipelines: o Terraform consulta o cofre em tempo de execução, sem expor o segredo no arquivo.
Na prática, em vez de escrever password = "minhasenha123" no .tf, o desenvolvedor referencia o segredo: password = data.aws_secretsmanager_secret_version.minha_senha.secret_string. O valor real nunca aparece no código nem no repositório.
A pegadinha da questão está em alternativas que parecem razoáveis, mas são inseguras ou ineficazes. Por exemplo, criptografar os arquivos .tf com GPG e compartilhar chaves por e-mail é inviável em equipe e não resolve o versionamento; variáveis locais do Terraform ainda ficam no código e podem ser exportadas no plano. A banca testa o conhecimento de boas práticas de segurança em IaC, um tema recorrente em concursos de DevOps.
Guarde o critério decisivo: segredos nunca devem residir no código-fonte ou em arquivos versionados — devem ser gerenciados por ferramentas especializadas. É exatamente essa fronteira que separa a alternativa correta das demais.
Segredos em IaC: Hardcoded no código (Arquivos .tf versionados, Arquivos .env versionados); Ferramenta gerenciadora de segredos (Vault, AWS Secrets Manager, Azure Key Vault, Centralização, Rotação automática, Integração com pipeline); Referência dinâmica (data.aws_secretsmanager_secret_version, Valor real nunca no código)
Alternativa A — ✅ Correta ⟵ GABARITO
Integrar o pipeline com uma ferramenta gerenciadora de segredos é a prática recomendada. Ferramentas como HashiCorp Vault, AWS Secrets Manager e Azure Key Vault armazenam credenciais de forma centralizada e segura, permitindo que o Terraform as recupere dinamicamente durante a execução, sem expô-las no código. Isso atende ao requisito de ocultar as credenciais e segue as melhores práticas de segurança em IaC.
Alternativa B — ❌ Incorreta
Criptografar os arquivos .tf com GPG e compartilhar as chaves por e-mail é inseguro e impraticável. O e-mail não é um canal seguro para distribuição de chaves, e a criptografia não impede que as credenciais sejam expostas se o arquivo for descriptografado por alguém com acesso. Além disso, a criptografia não é uma solução de gerenciamento de segredos — ela apenas protege o arquivo em repouso, mas não resolve o problema de versionamento e colaboração.
Alternativa C — ❌ Incorreta
Armazenar credenciais em arquivos .env e versioná-los junto com o código é exatamente o oposto da boa prática. Arquivos .env contêm segredos e não devem ser versionados; devem ser adicionados ao .gitignore e gerenciados separadamente. Versioná-los expõe as credenciais a qualquer pessoa com acesso ao repositório, agravando o problema.
Alternativa D — ❌ Incorreta
Utilizar comentários no código para indicar onde estão os dados sensíveis não oculta nada — apenas chama atenção para eles. Comentários não alteram o fato de que as credenciais estão expostas no arquivo versionado. A revisão manual não é uma medida de segurança eficaz, pois não impede o acesso não autorizado ao repositório.
Alternativa E — ❌ Incorreta
Variáveis locais no Terraform ainda são definidas no código-fonte e, portanto, ficam expostas no repositório. Além disso, a afirmação de que "não são exportadas para o plano de execução" é falsa: valores de variáveis podem aparecer no plano de execução (terraform plan) e no estado (terraform.tfstate), que também pode conter segredos. A prática correta é usar variáveis de ambiente ou, melhor, um gerenciador de segredos.
NÃO CAIA NESSA!
A banca explora a confusão entre "ocultar" e "proteger". Criptografar arquivos (B) parece seguro, mas não resolve o versionamento; variáveis locais (E) parecem inofensivas, mas ainda ficam no código. A pegadinha é achar que qualquer medida de "esconder" resolve — a única solução real é externalizar os segredos para uma ferramenta especializada.
PEGA ESSA DICA!
Na prova, desconfie de alternativas que envolvem "compartilhar chaves por e-mail", "versionar .env" ou "comentários no código" — todas violam princípios básicos de segurança. A resposta certa quase sempre envolve gerenciamento centralizado de segredos ou variáveis de ambiente (quando bem aplicadas).