Entrevistas de DevOps testam se você consegue entregar software de forma confiável: como o código sai do notebook e chega à produção, como você sabe que está saudável e o que fazer quando não está. Abaixo estão 20 perguntas com respostas, do básico às perguntas de cenário que decidem a maioria das entrevistas. Onde um comando é mostrado, é um comando padrão que você pode conferir na documentação da própria ferramenta.
Fundamentos
1. O que é DevOps?
Uma forma de trabalhar que aproxima desenvolvimento e operações para que o software seja construído, testado, lançado e operado pelo mesmo processo compartilhado. Os objetivos são lançamentos mais rápidos e seguros e uma recuperação mais ágil quando algo quebra. É uma cultura e um conjunto de práticas, com ferramentas como apoio, e não apenas um cargo.
2. Qual é a diferença entre integração contínua, entrega contínua e implantação contínua?
| Prática | O que significa |
|---|---|
| Integração contínua | Os desenvolvedores mesclam pequenas mudanças com frequência, e cada merge dispara uma build e uma execução de testes automatizadas |
| Entrega contínua | Toda mudança que passa pelo pipeline está pronta para ser lançada, e uma pessoa decide quando |
| Implantação contínua | Toda mudança que passa pelo pipeline é lançada em produção automaticamente |
3. Quais são as principais métricas de entrega de software?
Quatro são amplamente usadas, do programa de pesquisa DORA: frequência de implantação, tempo de espera para mudanças, taxa de falha em mudanças e tempo para restaurar o serviço. As duas primeiras medem velocidade, e as duas últimas medem estabilidade. Uma boa resposta explica que você acompanha as quatro para não melhorar a velocidade sacrificando a estabilidade.
4. Como é um bom pipeline de CI?
- Faça o checkout do código e restaure as dependências em cache.
- Faça a build.
- Rode primeiro os testes rápidos (testes unitários), depois os mais lentos.
- Rode verificações estáticas, como linting e uma varredura de vulnerabilidades em dependências.
- Gere um artefato (uma imagem de contêiner ou pacote) uma única vez e marque-o com o commit.
- Publique-o e implante o mesmo artefato em todos os ambientes.
A ideia central é gerar uma vez e promover o mesmo artefato, para que o que você testou seja o que você entrega.
Controle de versão e lançamentos
5. Como você faz branches e lançamentos?
Duas abordagens comuns. O desenvolvimento baseado em trunk mescla pequenas mudanças na branch principal com frequência, com feature flags para esconder o trabalho inacabado. Fluxos baseados em branches, como o GitFlow, usam branches de longa duração para lançamentos. O desenvolvimento baseado em trunk geralmente combina melhor com a entrega contínua, porque os merges são pequenos e frequentes.
6. O que são implantações blue-green e canário?
| Estratégia | Como funciona | Rollback |
|---|---|---|
| Blue-green | Dois ambientes idênticos. Implante no ambiente ocioso, teste-o e depois redirecione o tráfego | Redirecione o tráfego de volta |
| Canário | Envie uma pequena parcela do tráfego para a nova versão, acompanhe as métricas e aumente gradualmente | Envie a parcela de volta para zero |
| Rolling | Substitua as instâncias algumas de cada vez | Avance ou reverta a rolagem |
Blue-green custa capacidade extra. Canário precisa de boas métricas, porque você decide com base nos dados.
7. O que é uma feature flag e por que usá-la?
Um interruptor na configuração que liga ou desliga uma funcionalidade sem uma implantação. Ela separa a implantação do código do lançamento de uma funcionalidade, permite testar com um grupo pequeno e oferece um desligamento rápido se algo der errado. O custo é que as flags antigas se acumulam, então remova-as quando uma funcionalidade estiver estável.
8. Como fazer rollback com segurança?
Mantenha o artefato anterior disponível, torne as implantações repetíveis e faça mudanças no banco de dados compatíveis com versões anteriores, para que a versão antiga ainda funcione com o novo schema. Um plano de rollback que ignora o banco de dados não é um plano. Para mudanças arriscadas, prefira avançar com uma correção quando um rollback causaria perda de dados.
Infraestrutura e contêineres
9. O que é infraestrutura como código?
Definir servidores, redes e permissões em arquivos versionados em vez de clicar em um console. Isso torna os ambientes repetíveis, revisáveis e fáceis de reconstruir. Ferramentas comuns incluem Terraform, Pulumi e os próprios templates dos provedores de nuvem. Veja nossas perguntas de entrevista sobre Terraform.
10. Qual é a diferença entre um contêiner e uma máquina virtual?
Uma máquina virtual inclui um sistema operacional convidado completo sobre hardware virtualizado. Um contêiner compartilha o kernel do host e empacota apenas a aplicação e suas dependências, então inicia mais rápido e usa menos memória. Contêineres oferecem menos isolamento do que uma máquina virtual.
11. O que compõe um bom Dockerfile?
Use uma imagem base pequena e específica, ordene as camadas de modo que as que mudam menos venham primeiro (para aproveitar o cache de build), copie os arquivos de dependências e instale antes de copiar o código-fonte, execute como usuário não-root e não embuta segredos na imagem. Builds multi-stage mantêm as ferramentas de build fora da imagem final.
12. Por que Kubernetes?
Ele agenda contêineres entre máquinas, reinicia os que falharam, escala-os e cuida de atualizações graduais e descoberta de serviços. Também adiciona muita complexidade, então uma boa resposta diz quando você não o usaria, como em uma aplicação pequena que cabe em alguns servidores ou em uma plataforma gerenciada. Veja nossas perguntas de entrevista sobre Kubernetes.
13. Como você gerencia segredos?
Nunca os coloque no controle de versão ou em imagens. Use um gerenciador de segredos ou o cofre de segredos da plataforma, dê a cada serviço o mínimo de acesso necessário, rotacione segredos e evite imprimi-los nos logs. Diga o que você faria se um vazasse: revogá-lo, rotacioná-lo e verificar os logs em busca de uso.
Confiabilidade e operações
14. O que são monitoramento, logging e tracing?
| Sinal | O que ele te diz |
|---|---|
| Métricas | Como o sistema está se comportando ao longo do tempo, como taxa de erro e latência |
| Logs | O que aconteceu em um evento específico |
| Traces | Como uma requisição passou por vários serviços |
Crie alertas com base em sintomas que os usuários sentem, como erros e respostas lentas, mais do que em causas, como CPU alta em uma máquina.
15. O que são SLIs, SLOs e SLAs?
Um service level indicator é uma medição, como a proporção de requisições que têm sucesso. Um service level objective é a meta para ela, como 99,9 por cento em 30 dias. Um service level agreement é uma promessa aos clientes, muitas vezes com consequências se for descumprida. A diferença entre 100 por cento e o SLO é um error budget: a margem que você tem para risco e mudança.
16. Um serviço em produção está lento. O que você faz?
- Verifique se é real e quem está sendo afetado, usando dashboards e taxas de erro.
- Verifique o que mudou recentemente: um deploy, uma mudança de configuração, um pico de tráfego.
- Reduza o escopo: um endpoint, região ou dependência específica.
- Olhe os recursos (CPU, memória, conexões) e os serviços a jusante.
- Se uma mudança recente for a causa provável, faça o rollback primeiro e investigue depois.
- Comunique o status enquanto trabalha.
Os entrevistadores estão atentos a uma abordagem calma e ordenada e a mitigar antes de encontrar a causa raiz.
17. O que é um postmortem sem culpa?
Uma revisão escrita após um incidente que foca em como o sistema e o processo permitiram a falha, não em quem cometeu um erro. Ela cobre a linha do tempo, o impacto, as causas e ações de acompanhamento concretas com responsáveis. O objetivo é aprender e tornar a mesma falha mais difícil de repetir.
18. Qual é a diferença entre escalonamento horizontal e vertical?
O escalonamento vertical dá mais recursos a uma máquina. O escalonamento horizontal adiciona mais máquinas. O vertical é simples, mas tem um limite e um ponto único de falha. O horizontal escala mais e sobrevive à perda de uma máquina, mas exige serviços sem estado ou estado compartilhado.
Prática
19. Como você protege um pipeline?
Limite quem pode alterar o pipeline e quem pode fazer deploy em produção. Escaneie dependências e imagens em busca de vulnerabilidades conhecidas, assine e verifique artefatos, mantenha credenciais de curta duração e com escopo restrito, e revise mudanças em arquivos de pipeline como se fossem código. Um agente de build com permissões amplas é um alvo favorito.
20. Conte sobre um deploy que deu errado.
Esta é uma pergunta comportamental dentro de uma entrevista técnica. Use uma história curta: o que mudou, como você percebeu, o que fez primeiro (geralmente mitigar, muitas vezes com rollback), o que descobriu e o que mudou depois para que não se repita. Uma linguagem sem culpa e um acompanhamento concreto são o que os entrevistadores procuram.
Como se preparar
- Monte um pipeline pequeno de ponta a ponta: um repositório, um build, uma execução de testes, um container e um deploy para algo que você consiga acessar.
- Esteja pronto para explicar um incidente ou uma release que falhou na sua própria experiência.
- Pratique a resposta para "o serviço está lento" em voz alta até ela virar uma lista calma e organizada.
- Domine bem uma ferramenta de cada área, como CI, containers, infraestrutura como código e monitoramento, em vez de acumular uma lista enorme de nomes.
Para praticar temas relacionados, veja nossos guias de perguntas de entrevista sobre AWS, perguntas de entrevista sobre Terraform, perguntas de entrevista sobre Kubernetes e perguntas de entrevista sobre redes de computadores.
Pratique em voz alta e com suas próprias palavras. Uma transcrição depois mostra onde você se perdeu ou fugiu do ponto. Siga as regras da empresa sobre o uso de ferramentas de IA em qualquer entrevista ou avaliação ao vivo.
Pratique suas respostas com YesToTheOffer
Ensaiar em voz alta, obter respostas construídas a partir do seu próprio currículo e revisar sua transcrição depois. 30 minutos grátis, sem assinatura.
