Portfolio Projects for Cloud Engineer

Você tem três certificados de nuvem e nenhum projeto próprio. O recrutador olha seu perfil, não vê nada que você tenha construído e segue para o próximo candidato. É comum. Certificado mostra que você estudou. Projeto mostra que você resolve.

A diferença aparece no primeiro filtro. Quem revisa currículo para vaga de cloud quer ver decisões de arquitetura, automação e operação, não uma lista de badges. Três projetos bem feitos pesam mais do que cinco certificados repetidos.

O que quem revisa realmente procura#

Ninguém quer ver mais um clone de tutorial. O revisor quer entender três coisas: o problema que você resolveu, por que escolheu aquela solução, e o que deu errado no caminho. Detalhe honesto vale mais do que arquitetura bonita.

Ele também procura sinais de operação. Provisionar é fácil. Monitorar, logar, controlar custo e recuperar falha é o trabalho de verdade. Se o seu projeto não tem nada disso, parece exercício de fim de semana.

Por fim, procura legibilidade. Repositório organizado, README que explica decisões, diagrama simples, comandos que funcionam. Se o revisor não consegue rodar o seu projeto em dez minutos, ele não vai tentar.

Projeto 1: infraestrutura como código com pipeline#

Escolha uma aplicação simples, uma API ou um site estático, e suba tudo com Terraform ou Pulumi em uma nuvem real. Use AWS, GCP ou Azure, o que você tiver acesso. O que importa é subir e derrubar o ambiente por comando.

Inclua rede, máquina ou container, banco se fizer sentido, e variáveis de ambiente separadas por ambiente. Adicione um pipeline no GitHub Actions que roda fmt, validate e plan a cada pull request. Esse pipeline é o que separa projeto de portfólio de exercício manual.

Feche com controle de custo. Deixe anotado no README quanto o ambiente custa por mês rodando e como destruí-lo. Isso mostra que você pensa como quem paga a conta.

Projeto 2: plataforma de observabilidade#

Pegue a infraestrutura do projeto anterior e adicione métricas, logs e alertas. Prometheus e Grafana funcionam bem em qualquer provedor. Em cloud, também dá para usar CloudWatch, Cloud Monitoring ou Azure Monitor, e vale mostrar os dois caminhos.

O ponto é o alerta. Configure um alerta que dispara quando a latência passa de um limite ou quando a aplicação cai. Documente o que você faria ao receber esse alerta, mesmo que seja um ambiente de teste.

Esse projeto mostra maturidade. Quem contrata para cloud tem medo de sistema que ninguém consegue ver por dentro. Se você sabe instrumentar, você já está meio caminho andado na entrevista.

Projeto 3: recuperação de falhas e custo#

O terceiro projeto é o mais diferenciado. Simule uma falha, uma máquina que morre, um banco indisponível, e mostre como o sistema se recupera. Pode ser com auto scaling, com failover, ou com backup e restore testado.

Adicione análise de custo. Compare o preço da sua arquitetura com uma alternativa mais barata e explique a troca que fez. Esse tipo de raciocínio aparece em entrevista técnica com frequência.

Se der, inclua um pequeno exercício de disaster recovery. Tire um backup, destrua o ambiente, restaure e cronometre. Esse número, o tempo de recuperação, é ouro em conversa com entrevistador.

Como apresentar no GitHub#

O README é o seu currículo dentro do repositório. Comece com uma frase que diga o que o projeto faz e qual problema resolve. Depois, arquitetura, como rodar, decisões e trade-offs, e o que ficou de fora.

• Nome do repositório curto e descritivo, sem número de módulo de curso
• README com diagrama simples, pode ser desenho feito à mão digitalizado
• Comandos de setup que funcionam de verdade, testados numa máquina limpa
• Seção de decisões explicando por que escolheu A e não B
• Seção de custo estimado e como destruir o ambiente
• Licença e variáveis de exemplo no .env.example, sem segredo commitado
• Último commit coerente com o que está documentado, sem pasta solta de teste

Nada de senha, chave ou token no repositório. Um único segredo vazado derruba sua credibilidade na hora.

Como colocar no currículo#

Currículo de cloud precisa de números e escolhas. Não escreva que trabalhou com AWS. Escreva o que subiu, com o que automatizou e o que melhorou. Mesmo em projeto próprio, dá para quantificar.

Antes: "Criei uma infraestrutura na AWS com Terraform".

Depois: "Provisionei ambiente de 6 serviços em AWS com Terraform e pipeline de CI, com plan automático em PR e custo mensal de cerca de R$ 60, destruível por comando".

A segunda versão diz o escopo, a ferramenta, o controle e o custo. É isso que o recrutador consegue avaliar. Se quiser conferir se seu currículo passa nos filtros automáticos, use o verificador de currículo para ATS gratuito antes de enviar.

Erros que fazem o projeto parecer tutorial#

O erro mais comum é seguir o tutorial e parar ali. Se o seu projeto é igual ao de mil pessoas, ele não diferencia ninguém. Personalize, mude a aplicação, troque uma peça da arquitetura e explique por quê.

• Copiar o README do tutorial sem escrever nada seu
• Não dizer o que deu errado durante a construção
• Deixar o projeto sem pipeline, sem teste e sem log
• Usar nomes genéricos como "projeto-final" ou "desafio-cloud-3"
• Colocar tudo em uma conta com acesso root e não tratar permissão
• Não documentar como derrubar o ambiente, o que gera custo surpresa

Outro erro é inflar. Escrever que o projeto é "escalável" sem nenhum teste de carga é pedir para ser questionado na entrevista. Seja modesto e preciso.

Como falar sobre isso na entrevista#

Prepare uma narrativa curta de dois minutos por projeto. Problema, escolha, dificuldade, resultado. Termine sempre com o que você faria diferente hoje, isso mostra evolução.

Exemplo de resposta para "me conte sobre um projeto seu":

"Subi uma API em AWS com Terraform porque queria aprender infraestrutura como código de verdade. No começo eu deixava tudo numa conta manual e perdi tempo reproduzindo ambiente. Automatizei com pipeline de plan em cada PR e ganhei previsibilidade. O que me travou foi state do Terraform em time, resolvi com remote state e lock. Hoje eu adicionaria testes de política antes do apply, porque já vi deploy que passou e não deveria."

Repare que a resposta tem erro, solução e reflexão. É isso que o entrevistador quer ouvir.

Tenha números na ponta da língua. Tempo de deploy, custo mensal, tempo de recuperação, quantidade de serviços. Se não tiver número, meça antes da entrevista.

Onde encontrar referência de vaga#

Antes de fechar os projetos, abra vagas reais de Cloud Engineer e veja o que pedem. Se as vagas da sua região pedem Kubernetes, faça o projeto 2 com k8s. As vagas listadas no site ajudam a calibrar o portfólio para o mercado que você está mirando.

Também vale ler relatos e guias de carreira no blog para entender como outras pessoas estruturaram esse caminho. O que funciona em um país nem sempre funciona em outro.

Ferramentas grátis#

• jobrise.io/pt/free-ats-checker/
• jobrise.io/pt/free-jd-decoder/
• jobrise.io/pt/jobs/
• jobrise.io/pt/blog/

Perguntas frequentes#

Preciso ter conta paga na nuvem para fazer os projetos?

Não necessariamente. AWS, GCP e Azure têm camadas gratuitas e créditos para novos usuários, mas as regras mudam com frequência. Confira sempre a página oficial do provedor antes de começar e configure alerta de gasto para não levar susto.

Quanto tempo leva para fazer os três projetos?

Depende da sua base. Com prática em Linux e git, cada projeto leva de um a três fins de semana. Se estiver começando do zero, faça um projeto por vez e não tente terminar tudo em uma semana.

Posso usar o mesmo projeto de curso que fiz?

Pode como base, mas mude bastante. Troque a aplicação, mude pelo menos uma peça da arquitetura, escreva o README com suas palavras e adicione algo que o curso não cobriu. Se ficar igual ao original, não vale como diferencial.

Preciso mostrar os projetos no LinkedIn também?

Ajuda. Coloque o link do repositório e uma frase sobre o problema resolvido. Não precisa postar sobre toda atualização, o que importa é que o recrutador consiga chegar no código em um clique.

E se eu não conseguir terminar um projeto?

Publique mesmo assim, mas diga no README o que está pronto e o que falta. Projeto parado e honesto vale mais do que projeto abandonado sem explicação. Só evite prometer entrega que não vai acontecer.