Skip to content
Tecnologia & EngenhariaJunior

Exemplo de currículo Junior Cloud Security Engineer

Exemplo de currículo profissional Junior Cloud Security Engineer. Modelo otimizado para ATS.

Faixa salarial Junior (US)

$130,000 - $180,000

Por que este currículo funciona

Verbos fortes abrem cada bullet

Triei, Escrevi, Construí, Investiguei, Acompanhei. Cada bullet abre com uma ação que prova que você impulsionou o trabalho de cloud security, e não esperou tickets do Wiz chegarem na sua fila.

Números transformam trabalho de cloud security em evidência

4.200+ Wiz issues, MTTR de 17 dias para 6 dias, 240+ misconfigurações, 38 alertas true-positive, 71 por cento menos falsos-positivos. Sem métricas, a triagem de CSPM se lê como um log de tarefas.

Contexto transforma output de scan em outcomes de posture

Não 'rodei scans' mas 'em 94 repos de IaC e 9 contas AWS'. Não 'escrevi policies' mas 'como pre-merge gate em 64 repositórios Terraform'. Contexto prova que você entendeu a landing zone que estava defendendo.

Sinais de colaboração mesmo no nível inicial

Adotado por 5 platform teams, roteado para 8 service owners, runbooks para SREs on-call, acompanhei o senior cloud security engineer, suportei o EKS platform team. O trabalho cloud security júnior é embutido com platform-eng, seu CV deve mostrar as pessoas com quem você trabalhou.

Ferramentas mostradas em conquistas, não listadas numa stack

'Construí drift-detection noturno em AWS Config e Security Hub' supera 'AWS Config, Security Hub'. Ferramentas vivem dentro do que você entregou, provando que você as usou em produção e não passou os olhos por um tutorial.

Habilidades essenciais

  • Wiz
  • AWS Config
  • AWS Security Hub
  • GuardDuty
  • Checkov
  • tfsec
  • Terraform
  • AWS IAM
  • Macie
  • AWS Access Analyzer
  • OPA
  • Falco
  • Pod Security Admission
  • CIS AWS Foundations
  • Cloud Security Alliance CCM
  • Python
  • Go
  • Bash
  • HackerOne

Melhore seu currículo

CV de Cloud Security Engineer: Como ser contratado dentro de Platform Engineering, e não ao lado de um time de Compliance

Cloud Security é um dos papéis mais mal-encaixados da indústria de segurança. Não é AppSec genérico. Não é uma rotação de SOC analyst. Não é segurança de IT helpdesk. Cloud security engineers são donos da security posture da própria plataforma cloud: IAM, rede, IaC, runtime e supply chain. Recrutadores na Stripe, Snowflake, Datadog, Cloudflare, Coinbase, HashiCorp, MongoDB, Atlassian e Snyk escaneiam seu CV procurando um sinal: você entrega guardrails de landing-zone e é dono do posture multi-cloud, ou encaminha tickets do Wiz e chama isso de programa?

A verdade brutal é que a maioria dos CVs de cloud-security é filtrada pelas mesmas razões. Eles escrevem 'reviewei cloud security' em vez de 'escrevi uma baseline SCP de landing-zone bloqueando 14 ações de alto risco em 312 contas'. Listam CISSP no topo da página um e mencionam Wiz uma vez. Reivindicam 'expertise em AWS' sem nomear uma única decisão de landing-zone. O hiring loop quer ver decisões de posture específicas, não pilhas de certificações.

Este guia destrincha o que funciona em cada nível de cloud-security: júnior triando findings CSPM e escrevendo regras Checkov/OPA; pleno com ownership de uma cloud (AWS, GCP ou Azure) com fluência em landing-zone; sênior com governança multi-cloud com IaC + runtime + supply-chain; lead arquiteto de cloud-platform-security com orçamento, decisões de vendor e relatórios de posture em nível de board. Cada exemplo é construído a partir de tools reais (Wiz, Lacework, Orca, Prisma Cloud, CrowdStrike Falcon Cloud, Sysdig, Aqua, Checkov, tfsec, KICS, Falco, OPA, Kyverno, Sigstore, cosign, AWS IAM Identity Center, Verified Permissions, GCP Security Command Center, Azure Defender for Cloud) e métricas reais (MTTR de misconfig, taxa de drift detection, adoção de IAM permission-boundary, porcentagem de contas sob SCP-deny, taxa de issue burndown do Wiz, contagem de assets públicos, cobertura SLSA build-attestation, redução do blast-radius score) que os hiring managers efetivamente fazem pattern-match.

Best Practices para CV de Junior Cloud Security Engineer

  1. Posicione-se como engenheiro que pega cloud security, não pessoa de segurança aprendendo AWS. Hiring managers na Snyk, Datadog e HashiCorp despriorizam especificamente candidatos que abrem com conhecimento teórico de segurança. Lidere com IaC. 'Escrevi 86 policies de Checkov e tfsec cobrindo padrões S3 public-read, IAM wildcard-action e security-group 0.0.0.0/0, deployadas como pre-merge gate em 64 repositórios Terraform' bate 'familiar com AWS Well-Architected Framework' toda vez.

  2. Números em torno da triagem CSPM são a sua única prova de gosto. Todo CV júnior reivindica 'triei findings CSPM'. Os que recebem callback incluem: '4.200+ Wiz issues em 94 repos de IaC e 9 contas AWS, reduzindo o MTTR de misconfig de 17 dias para 6 dias via JIRA routing por severidade'. O delta de MTTR diz ao hiring manager que você entendeu que cloud security é um problema de sinal-ruído e routing.

  3. Mostre uma regra open-source de Checkov e um report de HackerOne. Um repositório público de Checkov com 14 policies funcionando para AWS IAM permission boundaries ou 3 reports de HackerOne de severidade média contra programas cloud-platform é mais convincente do que qualquer streak no TryHackMe. Ambos fazem pattern-match no hiring loop de cloud-security e dão aos entrevistadores algo concreto para perguntar.

  4. Nomeie a superfície de landing-zone onde cada ferramenta rodou. 'AWS Config' é uma ferramenta. 'Construí um pipeline noturno de drift-detection contra AWS Config e Security Hub, expondo 240+ misconfigurações por semana com auto-PRs roteados para 8 service owners' é uma integração. O framing de landing-zone diz ao recrutador que você sabe onde os guardrails moram.

  5. Evite a armadilha da lista CISSP no nível júnior. CISSP não significa nada sem 5 anos de experiência. AWS Certified Security Specialty como baseline está ok. CKS, GCP Professional Cloud Security Engineer, ou um ruleset público de Checkov no GitHub mandam um sinal de cloud-security muito mais forte do que pilhas de certs de segurança enterprise.

Erros comuns de CV para Junior Cloud Security Engineer

  1. Listar 'reviewei cloud security' sem framing de sistema

Por que machuca: Todo júnior diz isso. Empresas maduras em cloud-security leem como 'cliquei pelo console AWS uma vez'. Sem nomear a ferramenta CSPM, a contagem de contas, a contagem de repos IaC ou o MTTR, o bullet é invisível.

Como consertar: Substitua por framing de sistema: 'Triei 4.200+ Wiz issues em 94 repos de IaC e 9 contas AWS, reduzindo o MTTR de misconfig de 17 dias para 6 dias via JIRA routing por severidade'.

  1. Dizer 'CISSP listado' sem profundidade

Por que machuca: Colocar CISSP no topo de um CV júnior de cloud-security sinaliza que você é um colecionador de certs de segurança, não um engenheiro. Hiring loops de cloud-security despriorizam esse perfil porque faz pattern-match com candidatos GRC e IT-security em vez de adjacentes a platform-eng.

Como consertar: Lidere com artefatos de código: um ruleset público de Checkov com 180+ stars, 3 reports de severidade média no HackerOne contra programas cloud-platform, um bundle OPA open-source. AWS Certified Security Specialty ou CKS no rodapé está ok.

  1. 'Expertise AWS' genérica sem uma única decisão de landing-zone

Por que machuca: Dizer 'expert em AWS' num CV júnior é um tell. Recrutadores de cloud-security sabem que exposição real a AWS aparece como interações específicas com serviços: SCP-deny, IAM Identity Center, triagem de GuardDuty, AWS Config aggregator, reviews de policies de buckets S3.

Como consertar: Substitua 'expertise AWS' por bullets que nomeiem 3-4 serviços específicos e um outcome mensurável em cada um. 'Investiguei findings de GuardDuty e Macie em landing zones de staging e produção, confirmando 38 alertas true-positive e escrevendo 22 runbooks de follow-up para SREs on-call' é o tipo de fraseado que te tira do balde cloud genérico.

Tips rápidos de CV para Junior Cloud Security Engineer

  1. Entregue um ruleset público de Checkov antes de aplicar. Um repo no GitHub com 10-20 policies de Checkov ou OPA funcionando para AWS IAM permission boundaries, S3 public-read ou gaps de SCP é o sinal mais rápido de que você lê IaC. É o que hiring managers na Snyk e Datadog buscam especificamente durante o sourcing.

  2. Trate programas cloud-platform do HackerOne como seu portfólio. 3-4 reports de severidade média contra programas públicos de bug-bounty cloud-platform da AWS, GCP ou Azure são prova concreta de que você consegue ler o lado do atacante. Liste-os com valores de payout onde atribuídos.

  3. Aprenda uma cloud profundamente antes de reivindicar multi-cloud. AWS em profundidade (IAM, SCP, Config, GuardDuty, Security Hub, Identity Center) bate AWS + GCP + Azure tocados uma vez. Especificidade é onde recrutadores de cloud-security fazem pattern-match.

Pro tip: CVs genéricos são filtrados. Use Tailored Resume & Cover Letter para alinhar seu CV à stack exata de cloud-security que uma empresa-alvo usa (Wiz vs Lacework, Checkov vs tfsec, AWS Identity Center vs cross-account roles).

Perguntas frequentes

Um cloud security engineer é dono da security posture da própria plataforma cloud: IAM (SCP, IAM Identity Center, Verified Permissions, permission boundaries), rede (VPC, security groups, BeyondCorp), IaC (Checkov, tfsec, OPA, Kyverno), runtime (Falco, eBPF, GuardDuty, Sysdig) e supply chain (Sigstore, cosign, SLSA, Binary Authorization). Eles escrevem regras de detecção, constroem guardrails de landing-zone, rodam drift detection e fazem gating de merges IaC. Cloud security é trabalho de engenharia embarcado com platform-eng, não AppSec genérico, não SOC analyst, não segurança IT helpdesk.

AppSec engineers são donos do código de aplicação e dos pipelines SAST/SCA, embarcados com product engineering. SOC analysts vigiam alertas vindos da telemetria de produção. DevOps é dono de CI/CD e uptime operacional. Cloud security é dono da plataforma: quem pode chamar qual API, quais IAM roles podem assumir o quê, quais imagens de container rodam, como imagens são assinadas, quais runtime escapes são detectados. A stack diária é Wiz, Checkov, OPA, Kyverno, Falco, Sigstore, AWS IAM Identity Center, GCP Security Command Center e Azure Defender for Cloud. Há sobreposição com AppSec em supply-chain provenance e com DevOps em IaC, mas o centro de gravidade do papel é a plataforma cloud.

AWS Certified Security Specialty sinaliza fluência profunda em AWS landing-zone. Google Professional Cloud Security Engineer sinaliza profundidade em GCP/SCC. Microsoft SC-100 (Cybersecurity Architect) sinaliza maturidade em Azure Defender for Cloud e Sentinel. CKS (Certified Kubernetes Security Specialist) é cada vez mais esperado em pleno-para-sênior. CCSP (ISC2) e CISSP ajudam em sênior+ para visibilidade de management. CompTIA Security+ é aceitável como baseline. CISSP, CISM, CRISC empilhados em nível júnior na verdade reduzem as taxas de callback de cloud-security porque fazem pattern-match com candidatos GRC.

MTTR de misconfig (17 dias -> 6 dias é concreto), taxa de drift detection, porcentagem de contas sob baseline SCP-deny, porcentagem de adoção de IAM permission-boundary, contagem de assets públicos ao longo do tempo (23 -> 0 buckets), taxa de issue burndown do Wiz, cobertura CSPM de contas, cobertura SLSA build-attestation em tier-0, redução do blast-radius score, e payout-per-critical de bug-bounty para escopo cloud-platform. CVs sem pelo menos três dessas métricas são filtrados antes do screen do recrutador.

Sim, ambos. Um ruleset público de Checkov para AWS IAM permission boundaries ou gaps de SCP com adoção mensurável (stars, contributors, uso downstream) é o sinal de mais alta alavancagem em nível júnior e pleno. Reports HackerOne ou Bugcrowd contra programas cloud-platform com valores de payout e CVE IDs provam leitura do lado atacante. Ambos são explicitamente buscados durante sourcing na Stripe, Snyk, Datadog, HashiCorp, MongoDB, Atlassian e Coinbase.

Lidere com projetos aplicados enquadrados como experiência profissional. Um ruleset público de Checkov com 14 policies funcionando e 180+ stars, 3 reports HackerOne de severidade média contra programas cloud-platform por $2.100 em payouts, e um pipeline documentado de home-lab AWS Config + Wiz + GuardDuty são críveis. Enquadre a seção como 'Cloud Security Projects (2023-Atual)' e descreva cada um como se fosse um engagement contratual. O hiring manager quer ver artefatos de IaC e números de sinal-ruído, não gaps cronológicos.

Certificações recomendadas

Preparação para entrevistas

Entrevistas de Cloud Security Engineer testam fluência em landing-zone, profundidade em IaC e policy, e maturidade de pensamento de programa. Espere um exercício live de design IAM/SCP (escrever uma deny-policy que bloqueie 5 ações de alto risco específicas em uma org), uma sessão de whiteboard sobre threat modeling de um deployment fictício multi-account AWS, e um deep dive em uma cloud que você reivindica dominar (AWS, GCP ou Azure). Rounds sênior+ adicionam perguntas de estratégia CNAPP, walk-throughs de decisões de vendor, e design de supply-chain provenance (Sigstore, cosign, SLSA Level 3, Binary Authorization). Rounds lead adicionam economia de bug-bounty, consolidação de vendor CNAPP, e simulação de readout ao comitê de auditoria.

Perguntas frequentes

Perguntas comuns:

  • Caminhe por uma IAM policy mal configurada: o que essa trust-policy realmente permite?
  • Explique como Wiz, AWS Config e Security Hub diferem em cobertura e onde cada um se encaixa
  • Descreva como você triaria um finding de GuardDuty vs um finding de Macie
  • Qual a diferença entre uma SCP, uma IAM policy e um permission boundary?
  • Como você decidiria entre arrumar um finding CSPM e aceitar o risco?

Tips: Traga uma regra pública de Checkov e um report de HackerOne. Esteja pronto para escrever uma regra de Checkov ou OPA ao vivo. Evite o signaling de lista CISSP. Mostre que você entende que cloud security é trabalho de sinal-ruído e routing.

Atualizado: