Questão de Governança de TI — Auditoria de TI — FGV 2025
Governança de TI›Auditoria de TI
Código
fg106585
Banca
FGV
Órgão
CGE-SP
Ano
2025
Nível
Superior
Cargo
Auditor Estadual de Controle - Tecnologia da Informação - tarde
Um arquiteto de infraestrutura está revisando a adoção de Infrastructure as Code (IaC) com Terraform em um projeto de modernização. A equipe já criou módulos reutilizáveis e utiliza workspaces para isolar ambientes (dev/hom/prod).
Ao inspecionar o repositório, foram encontrados os seguintes arquivos: main.tf, variables.tf, terraform.tfstate, terraform.tfvars e .terraform.lock.hcl
Considerando as melhores práticas de segurança e gerenciamento de estado em Terraform, assinale a afirmativa correta.
AO arquivo .terraform.lock.hcl deve ser incluído no .gitignore para evitar conflitos entre ambientes, e o state file deve ser armazenado em backend remoto com state locking habilitado utilizando DynamoDB ou equivalente.
BO arquivo terraform.tfstate deve ser versionado no Git para garantir rastreabilidade de mudanças, enquanto terraform.tfvars contendo credenciais deve ser armazenado em secrets manager e referenciado via variáveis de ambiente.
COs arquivos terraform.tfstate devem ser excluídos do controle de versão e armazenados em backend remoto com criptografia, enquanto .terraform.lock.hcl deve ser versionado para garantir consistência de versões de providers entre execuções.
DO arquivo variables.tf contendo valores sensíveis deve ser criptografado com GPG antes do commit, e múltiplos state files podem compartilhar o mesmo backend S3 bucket sem isolamento de paths desde que utilizem workspace diferente.
EO state file local deve ser mantido apenas em ambientes de desenvolvimento, e a produção deve utilizar backend remoto sem versionamento, priorizando performance de leitura através de cache local do Terraform.
Revelar gabarito e comentário▾
GabaritoC — Os arquivos terraform.tfstate devem ser excluídos do controle de versão e armazenados em backend remoto com criptografia, enquanto .terraform.lock.hcl deve ser versionado para garantir consistência de versões de providers entre execuções.
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”.
Melhores práticas de segurança e gerenciamento de estado no Terraform
Gabarito: letra C. A alternativa C é a única que acerta ao afirmar que o arquivo de estado (terraform.tfstate) deve ser excluído do controle de versão e armazenado em backend remoto com criptografia, enquanto o arquivo .terraform.lock.hcl deve ser versionado para garantir consistência das versões dos providers entre execuções.
A questão testa o conhecimento sobre quais arquivos do Terraform devem ou não ser versionados no Git e como gerenciar o estado de forma segura. As práticas recomendadas pela HashiCorp e pela comunidade são:
NUNCA versionar arquivos terraform.tfstate (estado local) – eles contêm informações sensíveis (endereços IP, senhas, etc.) e devem ser armazenados em um backend remoto (S3, Azure Storage, etc.) com criptografia e state locking.
SEMPRE versionar o arquivo .terraform.lock.hcl – ele garante que todos os membros da equipe usem exatamente as mesmas versões dos providers, evitando inconsistências.
Variáveis sensíveis (credenciais) não devem estar em arquivos versionados; devem ser injetadas via variáveis de ambiente ou secrets manager.
Arquivo / Prática
Deve ser versionado no Git?
Deve ser armazenado onde?
Observação
terraform.tfstate
Não
Backend remoto (ex.: S3) com criptografia e state locking
Contém dados sensíveis; nunca versionar
.terraform.lock.hcl
Sim
Repositório Git
Garante consistência de versões dos providers
variables.tf
Sim
Repositório Git
Contém apenas declarações; valores sensíveis não devem estar aqui
terraform.tfvars
Sim (sem valores sensíveis)
Repositório Git (valores não sensíveis) / Secrets Manager (valores sensíveis)
Valores sensíveis devem ser injetados por variáveis de ambiente ou secrets
Credenciais / valores sensíveis
Não
Secrets Manager / variáveis de ambiente
Nunca em arquivos versionados
Arquivos Terraform: Versionar no Git (main.tf, variables.tf, .terraform.lock.hcl); Excluir do Git (terraform.tfstate, .terraform/, terraform.tfvars (credenciais)); Armazenar em backend remoto (Criptografia, State locking)
Alternativa A — ❌ Incorreta
Afirma que .terraform.lock.hcl deve ser incluído no .gitignore. Errado. Esse arquivo deve ser versionado para travar as versões dos providers. A segunda parte (estado remoto com locking) está correta, mas o erro na primeira torna a alternativa incorreta.
Alternativa B — ❌ Incorreta
Afirma que terraform.tfstate deve ser versionado no Git. Errado. O estado nunca deve ser versionado. A segunda parte (credenciais em secrets manager) é correta, mas não salva a alternativa.
Alternativa C — ✅ Correta ⟵ GABARITO
Afirma que os arquivos de estado devem ser excluídos do Git e armazenados em backend remoto criptografado, e que .terraform.lock.hcl deve ser versionado. Correto. É exatamente o que recomendam as boas práticas.
Alternativa D — ❌ Incorreta
Afirma que variables.tf contendo valores sensíveis deve ser criptografado. Errado.variables.tf deve conter apenas declarações de variáveis, não valores. Valores sensíveis vão em terraform.tfvars ou variáveis de ambiente, e mesmo assim não devem ser versionados. Sobre múltiplos state files compartilharem o mesmo bucket sem isolamento de paths: errado, pois cada workspace deve ter seu próprio path no backend.
Alternativa E — ❌ Incorreta
Afirma que o estado local deve ser mantido apenas em desenvolvimento. Errado. Mesmo em desenvolvimento, é boa prática usar backend remoto para evitar perda de estado. A produção deve usar backend remoto com versionamento (histórico de estados), não sem. Priorizar performance com cache local não é recomendado para produção.
PEGA ESSA DICA!
Na prova, lembre-se sempre: estado JAMAIS no Git (vai para backend remoto), lock das versões de provider SEMPRE no Git (.terraform.lock.hcl), e variáveis sensíveis fora do repositório.