Que perguntas sobre Terraform devo esperar em uma entrevista?

A maioria das entrevistas sobre Terraform começa pelo fluxo de trabalho e avança rapidamente para o que acontece por trás dele. Esteja preparado para explicar o ciclo de vida sem consultar anotações: terraform init baixa os providers e configura o backend; terraform plan compara a configuração desejada com o arquivo de estado e os recursos reais e, em seguida, exibe as ações que executaria; terraform apply executa esse plano; terraform destroy remove o que é gerenciado pela configuração. A primeira pergunta complementar quase sempre é por que plan e apply são etapas separadas, e a resposta é revisão e segurança: um plano pode ser inspecionado, aprovado e salvo antes que qualquer alteração ocorra.

• Providers. Plugins que se comunicam com uma API, como AWS, Azure, Google Cloud ou Kubernetes. Pergunta complementar: por que fixar as versões dos providers?
• Recursos e fontes de dados. Recursos são elementos que o Terraform cria e gerencia; fontes de dados leem elementos existentes que ele não gerencia.
• Variáveis, valores locais e saídas. Entradas, valores calculados e valores exportados. Pergunta complementar: como impedir que um segredo apareça na saída de um plano?
• O grafo de dependências. O Terraform ordena as operações com base nas referências entre recursos; depends_on existe para dependências que o grafo não consegue identificar.

Responda explicando o que cada comando lê e grava. Candidatos que dizem que plan é somente leitura e que apply altera tanto a infraestrutura quanto o estado já demonstram que entendem o modelo.

Você sabe que o estado é importante e suspeita que o entrevistador encontrará o limite do seu conhecimento. É uma suspeita justa; por isso, esta seção aborda as perguntas que chegam a esse limite e o que uma resposta completa deve conter.

• Onde fica o estado e por que não localmente? Um backend remoto, como um bucket de armazenamento de objetos, Terraform Cloud ou um banco de dados, oferece uma fonte compartilhada da verdade. A pergunta seguinte é sobre bloqueio: duas pessoas aplicando alterações ao mesmo tempo corrompem o estado, por isso backends compatíveis com bloqueios recusam a segunda execução.
• O que há no arquivo de estado? Atributos dos recursos, incluindo valores que você talvez considere sensíveis. Diga que o estado deve ser tratado como material secreto, criptografado em repouso e protegido por controle de acesso.
• Módulos. Um módulo é um conjunto reutilizável de recursos com suas próprias entradas e saídas. Os entrevistadores perguntam como você versiona módulos, como evita um módulo que tenta fazer tudo e como um módulo raiz combina módulos filhos.
• Workspaces versus configurações separadas. Workspaces permitem que uma configuração tenha vários arquivos de estado. A resposta-armadilha é tratá-los como toda a estratégia de ambientes; a produção normalmente merece configuração, backend e credenciais próprios, em vez de depender da troca de workspace.
• Refatoração sem destruição. Renomear um recurso faz o Terraform querer destruí-lo e recriá-lo. Saiba que existem blocos moved e terraform state mv, além da finalidade de cada um.

Uma boa disciplina para todas essas respostas é indicar a falha que a prática evita. O bloqueio evita corrupção por concorrência; o estado remoto evita divergências entre laptops; versões fixadas evitam uma atualização inesperada durante uma aplicação rotineira.

Entrevistas para cargos seniores substituem definições por situações. Um exemplo representativo: um engenheiro de plataforma entrevistado para uma função de infraestrutura em uma fintech é informado de que alguém alterou manualmente um grupo de segurança no console da nuvem, o próximo plano mostra uma diferença inesperada e a equipe está receosa de aplicá-lo. A resposta sólida identifica a situação como drift, explica que o plano já o revelou ao atualizar o estado real, decide se a alteração manual deve ser mantida ou revertida e atualiza a configuração para corresponder à realidade ou aplica o plano para restaurar o estado declarado. O entrevistador quer ouvir a decisão, não um comando.

Outros cenários recorrentes: uma aplicação que falhou no meio e como fica o estado depois; recursos criados antes da adoção do Terraform e como terraform import os coloca sob gerenciamento; uma equipe com vários engenheiros e como estruturar repositórios, backends e CI para que os planos sejam executados em pull requests e as aplicações ocorram uma única vez; segredos em variáveis e de onde eles deveriam vir; uma atualização de provider que altera o comportamento dos recursos. Em todos os casos, indique a restrição, escolha o mecanismo e explique seu custo.

É mais fácil responder bem a essas perguntas quando você já praticou as respostas em voz alta. O modo de entrevista simulada apresenta perguntas de cenário com perguntas complementares, e os outros bancos por função e ferramenta estão reunidos em perguntas de entrevista por função e tema.

Nas partes de conversação, sim, com limites que vale a pena declarar claramente. O aplicativo nativo para macOS e Windows da SubcueAI captura o áudio do sistema e do seu microfone e exibe sugestões curtas em uma sobreposição local. Assim, quando o entrevistador pergunta contra o que o bloqueio de estado protege, o mecanismo aparece diante de você enquanto você o explica. O painel lateral da extensão para navegador faz o mesmo em chamadas realizadas em abas no Chrome ou Edge, capturando apenas o áudio da aba da reunião. Nenhum bot entra na chamada e nada é inserido na página da reunião; as etapas de configuração estão na página do tutorial.

Onde ele não ajuda: uma avaliação monitorada, uma tela gravada, um laptop administrado pela empresa ou um exercício ao vivo no qual você escreve HCL sob observação. Aaron Cao, fundador da SubcueAI, descreve o objetivo do design como um lembrete do que você já sabe, não como um substituto desse conhecimento; por isso, o assistente trabalha com seu currículo e sua própria maneira de se expressar. Os limites honestos estão mapeados no grupo sobre detectabilidade.