As entrevistas de engenharia de nuvem deixaram de ser questionários de trivia faz um bom tempo. Em 2026, quase ninguém pede que você recite a diferença entre um bucket S3 e um volume EBS. Eles te entregam uma VPC quebrada, um plano do Terraform que quer destruir um banco de dados de produção, ou um cenário de pager às 3 da manhã, e observam como você pensa. "Eu pesquisaria no Google" só conta se você souber dizer o que buscaria e por quê.
Este guia cobre as perguntas que candidatos a engenheiro de nuvem enfrentam de verdade hoje, em AWS, Azure e GCP, com uma nota curta sobre como abordar cada uma.
O que as entrevistas de engenheiro de nuvem realmente testam em 2026
O título esconde muita variação. Um "engenheiro de nuvem" numa startup de 30 pessoas é um time de plataforma de uma pessoa só, ligando os fios de Terraform, CI/CD e plantão. O mesmo título num banco significa redes a fundo, guardrails de compliance e trabalho de landing zone. Leia a descrição da vaga como se fosse parte da prova, porque o processo pende para aquilo em que aquele time está se afogando.
Os sinais por trás disso não mudam. Os entrevistadores checam quatro coisas: seu modelo mental da nuvem (regiões, zonas de disponibilidade, o que cai quando uma AZ apaga); fluência em infraestrutura como código (Terraform na maioria das vezes, com CloudFormation e Bicep em empresas específicas); julgamento operacional, já que custo, segurança e confiabilidade viraram rodadas centrais, e não extras; e comunicação sob incerteza, porque problemas de nuvem são ambíguos e candidatos fortes narram suas suposições em voz alta.
O processo de entrevista: as rodadas de verdade
A maioria dos processos de nuvem em 2026 tem de quatro a seis etapas, e o formato é previsível depois que você passa por alguns.
- Triagem com recrutador (20 a 30 min). Logística, faixa salarial e em quais nuvens você realmente entregou coisas. Seja preciso: "três anos principalmente em AWS, um pouco de GCP" vale mais que um vago "experiência com nuvem".
- Triagem técnica por telefone (45 a 60 min). Uma conversa ao vivo com um gerente de contratação ou engenheiro sênior: fundamentos em ritmo rápido mais um cenário ou dois.
- Prática guiada ou desafio para casa. Cada vez mais é a rodada central. Escrever um módulo Terraform, depurar um deploy quebrado de propósito, ou subir um serviço pequeno com um texto curto de arquitetura.
- Rodada de system design (60 min). Projetar um sistema resiliente e consciente de custo. Bem menos pesada em algoritmos que uma vaga puramente de software, e bem mais sobre trade-offs e domínios de falha.
- Rodada comportamental / de incidente (45 min). Me fale sobre uma queda, uma migração, uma discordância sobre uma decisão de segurança. Costuma ser um mergulho fundo em um incidente real que você resolveu.
As perguntas
Fundamentos essenciais
Me explique, de ponta a ponta, o que acontece quando um usuário acessa uma aplicação atrás de um Application Load Balancer. Como abordar: resolução de DNS, terminação TLS, o target group do load balancer e seus health checks, os security groups e as subnets no caminho, depois a computação e sua ligação com um armazenamento de dados. Diga onde cada peça pode falhar.
Explique a diferença entre uma região e uma zona de disponibilidade, e depois projete algo que sobreviva à perda de uma AZ. Como abordar: defina os dois com clareza e mostre a consequência. Multi-AZ para serviços com estado (RDS Multi-AZ, quórum entre três AZs), computação sem estado espalhada atrás de um load balancer. Deixe claro que multi-região é outra conversa, mais cara, sobre RTO e RPO, e não um padrão.
O que é o modelo de responsabilidade compartilhada, e onde os engenheiros erram nele? Como abordar: o provedor protege a nuvem, você protege o que coloca dentro dela. A falha comum é achar que serviço gerenciado significa segurança gerenciada. Um bucket S3 público ou um IAM largo demais é problema seu, não do provedor.
Infraestrutura como código
Seu terraform plan quer destruir e recriar uma instância RDS de produção. O que você faz?
Como abordar: não aplique. Leia o plano para achar qual atributo força a substituição (um campo imutável, uma versão de engine, uma mudança de AZ). Recorra a blocos create_before_destroy, lifecycle e a state mv ou import como ferramentas de recuperação. Um destroy num plano de produção é motivo para parar tudo.
Como você gerencia o state do Terraform para quinze engenheiros em três ambientes?
Como abordar: backend remoto (S3 mais lock no DynamoDB, ou Terraform Cloud), separação de state por ambiente e controle do raio de impacto, para que uma mudança em staging nunca toque o state de produção. Pontos extras por credenciais de CI com privilégio mínimo e por detectar drift com um plan agendado que falha se houver diferença.
Redes, segurança e IAM
Projete uma VPC com subnets públicas e privadas em duas AZs, e me explique o roteamento. Como abordar: desenhe. Um bloco CIDR para a VPC, subnets públicas roteando para um internet gateway, subnets privadas saindo por um NAT gateway, tabelas de rota por camada. Espere a pergunta seguinte: como as instâncias privadas chegam nas APIs da nuvem sem passar pela internet pública (VPC endpoints)?
Uma instância EC2 numa subnet privada não consegue alcançar a internet. Como você depura isso? Como abordar: é uma pergunta de troubleshooting estruturado, não de trivia. Trabalhe de dentro para fora, em camadas: egress do security group, network ACLs, a tabela de rotas da subnet, a saúde do NAT gateway e a rota dele até o IGW, e então DNS. Narre como um checklist e cite a ferramenta que confirma cada passo (reachability analyzer, flow logs).
Uma aplicação precisa de acesso de leitura a um bucket S3. Como você concede isso?
Como abordar: uma role IAM na computação (instance profile, IRSA no EKS ou workload identity) com uma política bem restrita àquele bucket e àquele prefixo. As respostas armadilha, chaves de acesso de longa duração dentro da aplicação ou s3:* em Resource: *, caem no primeiro contato. Diga "privilégio mínimo" em voz alta.
Como você guarda e rotaciona segredos de uma aplicação cloud-native? Como abordar: um cofre de segredos gerenciado (Secrets Manager, Parameter Store ou Vault), lido em tempo de execução pela identidade da carga de trabalho, nunca commitado no git nem embutido numa imagem. A regra é que a aplicação nunca guarda uma credencial estática de longa duração.
Operações, confiabilidade e custo
A latência em produção acabou de triplicar e você não faz ideia do porquê. Me conte seus primeiros dez minutos. Como abordar: esse é o sinal de resposta a incidentes. Primeiro reconheça e comunique, leia os sinais dourados (latência, tráfego, erros, saturação), verifique deploys recentes, e prefira mitigar (rollback, escalar horizontalmente) a caçar a causa raiz enquanto o cliente sofre. Calmo ganha de frenético.
A conta mensal subiu 40 por cento sem mudança de tráfego. Como você acha a causa? Como abordar: tags de alocação de custo, cost explorer separado por serviço e por conta, e os suspeitos de sempre (volumes órfãos, load balancers ociosos, transferência entre AZs ou de saída, um autoscaling group descontrolado, ambientes de dev esquecidos). Trate custo como uma métrica de engenharia, com donos.
Qual é a sua abordagem para backups e recuperação de desastres, e como você sabe que funcionam? Como abordar: defina RTO e RPO primeiro, depois mapeie para uma estratégia (snapshots, replicação entre regiões, infraestrutura reconstruível a partir do código). A frase que pega: um backup que você nunca restaurou é uma esperança, não um backup.
Comportamental e profundidade em incidentes
Me fale do pior incidente em produção do qual você participou. Qual era o seu papel, e o que mudou depois? Como abordar: escolha um real e estruture como situação, suas ações específicas, a resolução, e a correção sistêmica e o postmortem sem culpados que vieram depois. Eles avaliam senso de dono e aprendizado, não se você já quebrou alguma coisa.
Descreva uma vez em que você discordou de uma decisão de segurança ou de arquitetura. Como abordar: mostre que você discorda com dados e depois embarca na decisão. A versão madura inclui uma vez em que você foi voto vencido e deu tudo certo, em vez de uma história em que você construiu uma gambiarra escondida.
Erros comuns que afundam candidatos a engenheiro de nuvem
- Citar serviços sem falar de trade-offs. "Eu usaria Kubernetes" não é uma resposta. Por que não ECS, ou Lambda, ou um autoscaling group simples? A vaga pede julgamento, não vocabulário.
- Ignorar custo. Projetar active-active em cinco regiões para uma ferramenta interna com doze usuários mostra que você nunca foi dono de uma fatura.
- Blefar. Fingir domínio de um serviço que você nunca usou desmorona na segunda pergunta de acompanhamento. "Nunca rodei Aurora em produção, mas é assim que eu pensaria sobre isso" gera muito mais confiança.
- Chutar a correção. Numa pergunta de VPC quebrada, um chute certeiro parece sorte. Troubleshooting em camadas, narrado, parece competência.
- Tratar segurança como algo secundário. Deixar IAM e segredos para o fim de uma rodada de design é sinal de alerta em 2026.
Como se preparar (e onde um copiloto ao vivo ajuda)
Construa, não só leia. Suba uma conta no free tier, escreva um módulo Terraform que cria uma VPC com subnets públicas e privadas, quebre o roteamento de propósito e conserte. Só esse exercício cobre um terço das perguntas acima.
Treine as perguntas de cenário em voz alta, porque entrevistas de nuvem premiam a narração. Ensaiar a resposta dos "primeiros dez minutos de um incidente" até ela fluir vale mais que decorar limites de serviço que você pode consultar. Mapeie também o seu histórico para as perguntas comportamentais: uma história de queda, uma de migração, uma de discordância, estruturadas e prontas.
Para as rodadas ao vivo, quando as perguntas chegam mais rápido do que você consegue formular uma resposta completa, um copiloto em tempo real tira o peso. O GhostPilot roda no painel lateral do Chrome e escuta a entrevista, mostrando um roteiro estruturado no instante em que a pergunta cai: as camadas a checar numa pergunta de depuração, os trade-offs a citar numa pergunta de design, um empurrão para o ângulo de custo ou de segurança que você poderia esquecer sob pressão. Ele te dá o esqueleto, não um script para ler em voz alta, então a experiência vivida continua saindo da sua boca, com as suas palavras. Mais em ghostpilotai.com.
FAQ
No que devo focar numa entrevista de engenheiro de nuvem júnior? Fundamentos antes de amplitude. Conheça de cor as primitivas de computação, armazenamento e rede de uma nuvem, entenda IAM e o modelo de responsabilidade compartilhada, e escreva uma configuração básica em Terraform. Processos para júnior perdoam lacunas em escala se os seus fundamentos forem sólidos.
De quantas certificações de nuvem eu preciso em 2026? Uma certificação de nível associate (como a AWS Solutions Architect Associate) ajuda a passar da triagem de currículo, principalmente se você não tem muita experiência. Além disso, certificações têm retorno decrescente bem rápido. Um portfólio pequeno de Terraform e um projeto real que você sabe explicar valem mais que uma parede de selos.
Entrevistas de engenheiro de nuvem ainda têm código no estilo LeetCode? Menos que as vagas de software, mas não zero. Espere scripts leves (Python ou Bash para parsear logs ou chamar uma API) em vez de algoritmos pesados. Vagas mais voltadas a plataforma e SRE podem incluir um problema de estruturas de dados, mas IaC e cenários de design dominam.
Qual a diferença entre uma entrevista de engenheiro de nuvem e uma de DevOps ou SRE? Muita sobreposição. Engenheiro de nuvem puxa mais para provisionamento, IaC e serviços do provedor. SRE puxa para a matemática da confiabilidade, SLOs e rigor de plantão. DevOps puxa para CI/CD e experiência do desenvolvedor. Um mesmo processo costuma servir para os três, e o que afunda bons candidatos em todos eles é falar em nomes de serviço em vez de trade-offs.
Experimente o GhostPilot AI
Entrevistas de nuvem andam rápido e as perguntas de cenário raramente têm uma resposta limpa, que é exatamente onde um roteiro em tempo real ajuda você a se manter estruturado sob pressão. O GhostPilot roda no painel lateral do Chrome, então quando você compartilha uma única aba ele não entra no que é capturado, e o app de desktop opcional para Windows é invisível à captura de tela no Windows 10 (build 2004 ou posterior) e no Windows 11. Comece de graça com sessões ao vivo de 10 minutos e respostas de IA ilimitadas, pegue um Session Pass por $29 (três entrevistas completas de duas horas, pagamento único, sem assinatura), ou vá de Pro por $59/mês ou $192/ano ($16/mês na cobrança anual).