Guia Completo de Preparação para a Certificação AWS Security Specialty (SCS-C03)
_Category: Exam Guide_
O AWS Security Specialty (SCS-C03) é frequentemente descrito por engenheiros de segurança em atividade como "o exame mais próximo do que vivemos no dia a dia". Ele não pede que você memorize nomes de serviços; ele quer saber o que você faria diante de um cenário real de comprometimento — qual serviço escolheria, em que ordem agiria. Este guia apresenta uma visão panorâmica do SCS-C03 e serve de mapa para as 10 partes temáticas que vêm a seguir.
---
O que o SCS-C03 avalia: o cotidiano do engenheiro de segurança
O SCS-C03 não pergunta "você conhece este serviço?", mas sim "nesta situação, o que você escolheria?". A maioria das questões traz cenários de 4 a 8 linhas. Uma empresa financeira global com ambiente multi-conta tenta acessar o S3 via IAM role e recebe erro de permissão. Uma organização precisa invalidar uma chave de criptografia em menos de 24 horas após um incidente. São situações assim que aparecem na prova.
As competências avaliadas podem ser resumidas em três frentes:
Prevenção: bloquear o acesso na origem com políticas IAM, SCPs, políticas de bucket e políticas de chave KMS Detecção: identificar comportamentos anômalos com GuardDuty, Security Hub, CloudTrail e Config Resposta: reagir automaticamente às ameaças com EventBridge, Lambda e SSM Automation
Pontuação mínima para aprovação: 750 de 1000 pontos. São 65 questões em 170 minutos. Com cenários extensos e quatro alternativas que parecem igualmente plausíveis, o tempo é sempre apertado.
---
Os 6 domínios oficiais em uma única tabela
O blueprint oficial do exame organiza o conteúdo em 6 domínios. Abaixo, os pesos e os serviços centrais de cada um:
| Domínio | Peso | Serviços Principais | |---------|------|---------------------| | Infrastructure Security | 20% | VPC, Security Group, NACL, Network Firewall, WAF, Shield | | Security Logging and Monitoring | 18% | CloudTrail, Config, CloudWatch, Security Hub | | Data Protection | 18% | KMS, Secrets Manager, S3, Macie, CloudHSM | | Identity and Access Management | 16% | IAM, Organizations, SCP, STS, Cognito | | Threat Detection and Incident Response | 14% | GuardDuty, Detective, Inspector, EventBridge, Lambda | | Management and Security Governance | 14% | Organizations, SCP, Config, Control Tower |
Infrastructure Security lidera com 20%, sinalizando que segurança de VPC e isolamento de rede são o coração da prova. Logging/Monitoring e Data Protection empatam em segundo lugar, com 18% cada. Na amostra real de questões disponível (348 no total), VPC aparece em 84 questões (24%), IAM em 65 (19%) e segurança de S3 em 52 (15%) — distribuição bastante coerente com os pesos oficiais.
---
O panorama dos serviços de segurança AWS: os 4 pilares
Decorar uma lista de serviços é ineficiente. Entendê-los dentro de um framework de 4 pilares reduz a confusão na hora de escolher a resposta certa.
O pilar de prevenção bloqueia o acesso antes que ele aconteça. Aqui entram políticas IAM (baseadas em identidade), políticas de bucket S3 (baseadas em recurso), políticas de chave KMS, SCPs (limite máximo em nível organizacional), Network Firewall, WAF e Shield.
O pilar de detecção descobre comportamentos suspeitos. CloudTrail registra chamadas de API; Config rastreia mudanças de configuração; GuardDuty detecta ameaças com machine learning; Inspector faz varreduras contra CVEs e benchmarks CIS. O Security Hub centraliza todos esses resultados em um único painel.
O pilar de resposta age automaticamente sobre as ameaças detectadas. O fluxo mais comum é: GuardDuty ou Config dispara um evento no EventBridge, que aciona um Lambda para executar a correção. O SSM Automation define runbooks para operações complexas como isolar uma instância EC2 ou aplicar patches.
O pilar de governança mantém políticas de segurança consistentes em todos os ambientes multi-conta. Organizations, SCP, Control Tower e o agregador do Config cuidam da conformidade em nível de conta.
!Os 4 pilares da segurança na AWS
Os critérios de escolha que mais confundem no exame
Veja os pontos de confusão mais recorrentes no SCS-C03 e como diferenciá-los de uma vez por todas.
GuardDuty vs. Security Hub vs. Detective: GuardDuty é quem detecta a ameaça pela primeira vez. O Security Hub é o painel que agrega resultados de GuardDuty e de outros serviços. O Detective recebe esses findings como entrada e usa análise de grafos para rastrear a causa raiz. Em uma frase: GuardDuty encontra, Security Hub organiza, Detective investiga.
KMS vs. Secrets Manager: KMS gerencia as chaves de criptografia em si. O Secrets Manager armazena com segurança credenciais como senhas de banco de dados e chaves de API, e as rotaciona automaticamente. Se o cenário fala em "criptografar dados no S3", é KMS. Se fala em "injetar a senha do RDS na aplicação de forma segura", é Secrets Manager.
CloudTrail vs. Config: CloudTrail é o log de auditoria — "quem chamou qual API e quando". Config rastreia o estado da configuração dos recursos e como ela mudou ao longo do tempo. Para detectar eventos em tempo real, use CloudTrail com EventBridge. Para rastrear mudanças de configuração, use Config.
Network Firewall vs. WAF vs. Security Group: Security Group é um firewall stateful em nível de instância (EC2, RDS). WAF atua na camada HTTP, bloqueando SQL injection, XSS e tráfego por país. Network Firewall opera na borda da VPC, realizando inspeção profunda de pacotes (deep packet inspection).
---
Roteiro de estudo: 11 partes
Este guia é o ponto de partida. O estudo completo do SCS-C03 está estruturado em 11 partes:
Parte 1 (este guia) — Visão geral: 6 domínios, os 4 pilares de serviços e estratégia de estudo
Parte 2 — Modelo de permissões IAM: políticas baseadas em identidade e em recurso, Permission Boundary, acesso cross-account com AssumeRole
Parte 3 — Organizations, SCP e governança multi-conta: lógica de permissões do SCP (a interseção entre IAM e SCP é a permissão efetiva), Control Tower, agregador do Config
Parte 4 — KMS e criptografia envelope: tipos de CMK, funcionamento da criptografia envelope, uso de chaves cross-account, CloudHSM custom key store
Parte 5 — Proteção de dados no S3: políticas de bucket, comparação SSE-S3 / SSE-KMS / SSE-C, Macie, Object Lock
Parte 6 — Segurança de VPC e isolamento de rede: Security Group vs. NACL, Network Firewall, PrivateLink, Transit Gateway
Parte 7 — Segurança de borda com WAF, Shield e CloudFront: grupos de regras WAF, Shield Advanced, Geo Restriction, regras baseadas em taxa
Parte 8 — CloudTrail, Config e logging centralizado: eventos de gerenciamento vs. eventos de dados, correção automática com Config, organization trail
Parte 9 — GuardDuty, Security Hub e Detective: fontes de detecção de ameaças, ASFF, análise de grafo de comportamento
Parte 10 — Inspector, vulnerabilidades e gerenciamento de patches: varredura contínua no ECR, SSM Patch Manager, CVE vs. benchmarks CIS
Parte 11 — Resposta a incidentes e isolamento automatizado: EventBridge + Lambda para remediação, runbooks SSM Automation, snapshots forenses
---
Quatro cenários práticos recorrentes
Conhecer as soluções para os cenários mais frequentes evita surpresas na prova — mesmo em questões com redação diferente.
Agregação central de logs multi-conta: use um organization trail para coletar logs do CloudTrail de todas as contas em um bucket S3 na conta de segurança. Para evitar adulteração dos logs, configure S3 Object Lock e MFA Delete. Com a integração organizacional do Security Hub, todos os findings chegam automaticamente à conta de gerenciamento.
Correção automática de ACL pública no S3: monitore a API PutObjectAcl com eventos de dados do CloudTrail. O EventBridge dispara um Lambda que remove a ACL imediatamente. A regra s3-bucket-public-read-prohibited do Config complementa com verificações periódicas de conformidade.
Resposta a DDoS: o Shield Standard cobre ataques nas camadas 3 e 4 por padrão. Regras baseadas em taxa no WAF limitam o número de requisições por segundo de um mesmo IP. O Shield Advanced oferece suporte 24 horas da equipe especializada em DDoS da AWS (SRT).
Criptografia cross-account: para que um Lambda na conta de workload acesse dados criptografados com uma CMK KMS da conta de segurança, é preciso adicionar o ARN da role na política de chave KMS e também conceder kms:Decrypt na política IAM da conta de workload. Se qualquer uma das duas permissões faltar, o acesso é negado.
---
Estratégia de estudo e armadilhas comuns
Compreender é mais importante do que memorizar. Três práticas combinadas fazem a diferença: caderno de erros, laboratório prático e distribuição de tempo por domínio.
No caderno de erros, o essencial é registrar em uma linha por que cada alternativa errada está errada. Frases como "GuardDuty só detecta, não executa correção automática" ficam na memória e evitam que questões parecidas derrubem você novamente.
No laboratório prático, comece montando o pipeline CloudTrail + EventBridge + Lambda de remediação automática. Criar um finding de teste no GuardDuty, aplicar uma regra do Config e integrar o Security Hub na prática vale muito mais do que ler sobre esses recursos.