AWS Certified Security – Specialty (SCS-C02) — the complete study guide

SCS-C02 is a specialty exam and it behaves like one. The questions are long, the scenarios are realistic, and most answers are technically possible — the exam is asking which one is correct for this constraint: least privilege, lowest cost, least operational overhead, or fastest to detect.

You need working knowledge, not recall. This guide is structured around the six domains, with the service comparisons the exam returns to again and again.

The exam at a glance#

170 minutes for 65 questions is around 2.6 minutes each — comfortable, provided you do not stall. Long scenarios are normal. Read the last sentence of the question first; it tells you the constraint being optimised for, and you can then read the scenario knowing what matters.

Domain weightings#

There is no soft domain. But IAM permeates every other domain — a data protection question is usually really a key policy question, and an infrastructure question is usually really a role question. If your IAM is weak, the whole exam is weak.

Domain 1 — Threat Detection and Incident Response (14%)#

• GuardDuty — the managed threat detection service. Knows about cryptocurrency mining, credential exfiltration, reconnaissance, and unusual API calls. Understand finding types, suppression rules, and how it consumes VPC Flow Logs, DNS logs and CloudTrail without you enabling them separately.
• Detective — investigates and visualises findings; it does not detect.
• Security Hub — aggregates findings across accounts and services, and runs security standards checks (CIS, AWS Foundational Security Best Practices, PCI DSS).
• Incident response: isolating an instance (change the security group to one with no rules, keep it running for memory forensics, snapshot the EBS volume), revoking credentials, and quarantining via NACL.
• Automated response: EventBridge rules on GuardDuty findings, triggering Lambda or Systems Manager Automation runbooks.
• Compromised credentials playbook: rotate, revoke sessions with an aws:TokenIssueTime deny policy, review CloudTrail, then remediate.

Domain 2 — Security Logging and Monitoring (18%)#

The domain of "which log would show that?".

Things the exam tests hard:

• CloudTrail management events vs data events. Data events (S3 object-level, Lambda invocations) are not logged by default and cost extra. If a question asks why an S3 GetObject is missing from CloudTrail, this is why.
• Organisation trails for multi-account logging into a central, locked-down log archive account.
• Log integrity: CloudTrail log file validation, S3 Object Lock, MFA delete, and a separate account with restricted access.
• Config rules (managed and custom) plus remediation actions.
• CloudWatch metric filters and alarms for detecting patterns such as root account usage or unauthorised API calls.
• Athena for querying CloudTrail and flow logs at scale.

Domain 3 — Infrastructure Security (20%)#

The largest domain.

• VPC design: public and private subnets, route tables, internet and NAT gateways, security groups (stateful, allow only) vs NACLs (stateless, allow and deny, evaluated in rule order). This comparison appears on essentially every attempt.
• VPC endpoints: interface endpoints (PrivateLink, ENI, security groups apply) vs gateway endpoints (S3 and DynamoDB only, route table entry, free). Endpoint policies to restrict which buckets are reachable.
• Edge protection: AWS WAF (rules, rate limiting, managed rule groups), Shield Standard and Advanced, CloudFront (OAC for S3 origins, signed URLs and cookies, geo restriction).
• Network Firewall for stateful, Suricata-compatible inspection at the VPC level; Route 53 Resolver DNS Firewall for DNS-layer blocking.
• Traffic Mirroring for out-of-band packet inspection.
• Systems Manager Session Manager — the exam's preferred answer to "how do we give shell access without opening port 22 or running a bastion?" It gives auditable, IAM-controlled, keyless access with no inbound rules at all.
• Instance hardening: Inspector for vulnerability assessment, Patch Manager, golden AMIs, IMDSv2 (and why v1 enables SSRF-based credential theft).

Security Group            Network ACL
---------------------------------------------------------
Instance level            Subnet level
Stateful                  Stateless (return traffic needs its own rule)
Allow rules only          Allow and deny rules
All rules evaluated       Rules evaluated in number order, first match wins

Domain 4 — Identity and Access Management (16%)#

• Policy evaluation logic — the single most valuable thing to master:

1. Explicit DENY anywhere        → deny. Always. No exceptions.
2. SCP (in AWS Organizations)    → must allow, or deny.
3. Resource control policy       → must allow, or deny.
4. Permissions boundary          → must allow, or deny.
5. Session policy                → must allow, or deny.
6. Identity or resource policy   → an explicit ALLOW is required.
7. Otherwise                     → implicit deny.

• Identity-based vs resource-based policies, and the cross-account case: for cross-account access you need an allow on both sides.
• Roles and sts:AssumeRole, trust policies, external ID (for third-party access — know why it exists: the confused deputy problem), session tags.
• Permissions boundaries vs SCPs vs session policies — what each limits and at what scope.
• IAM Identity Center for workforce SSO; Cognito user pools (authentication) vs identity pools (temporary AWS credentials).
• IAM Access Analyzer for finding resources shared externally and for generating least-privilege policies from CloudTrail history.
• Condition keys: aws:SourceIp, aws:PrincipalOrgID, aws:SourceArn, aws:SecureTransport, aws:MultiFactorAuthPresent, aws:PrincipalTag.

Domain 5 — Data Protection (18%)#

• KMS in depth: customer managed keys vs AWS managed keys vs AWS owned keys; key policies are the primary access control and IAM alone cannot grant access to a key whose policy does not permit it; grants; key rotation (automatic annual for CMKs, and what rotation does and does not re-encrypt); multi-Region keys; the kms:ViaService condition key.
• Envelope encryption — data key encrypts the data, CMK encrypts the data key. Know why: performance and the ability to rotate without re-encrypting everything.
• CloudHSM — when you need FIPS 140-2 Level 3, single-tenant hardware, or full control of key material. AWS cannot recover your CloudHSM keys.
• S3 encryption: SSE-S3, SSE-KMS (and S3 Bucket Keys to cut KMS costs), SSE-C, client-side. Bucket policies enforcing aws:SecureTransport and s3:x-amz-server-side-encryption.
• S3 Block Public Access, Object Lock (governance vs compliance mode), versioning, MFA delete, replication.
• Secrets Manager (rotation built in, costs more) vs SSM Parameter Store SecureString (cheaper, no native rotation). The exam picks between these constantly — rotation requirement means Secrets Manager.
• ACM for certificates; Macie for discovering sensitive data in S3.
• Encryption in transit: TLS enforcement, VPN, Direct Connect with MACsec.

Domain 6 — Management and Security Governance (14%)#

• AWS Organizations: organisational units, service control policies (they set the maximum available permissions and never grant anything), tag policies, backup policies, and the delegated administrator pattern.
• Control Tower and landing zones, guardrails (preventive vs detective).
• Multi-account strategy — separate accounts for logging, security tooling, production and development. Knowing why this is the recommendation is testable.
• Config conformance packs, Security Hub standards, Audit Manager.
• Firewall Manager for centrally managing WAF, Shield and security group policies across accounts.
• Trusted Advisor, cost and usage anomaly detection.
• Data residency and compliance, AWS Artifact for compliance reports, and the shared responsibility model applied precisely — for example, with RDS AWS patches the database engine but you configure encryption, network exposure and access.

A ten-week study plan#

Weeks 1–2 — IAM. Nothing else until policy evaluation is automatic. Write policies by hand. Break your own access and work out why from the evaluation order.

Weeks 3–4 — Logging and detection. Turn on CloudTrail data events, VPC Flow Logs and GuardDuty in a sandbox account. Generate a finding deliberately and follow it through Security Hub and EventBridge.

Weeks 5–6 — Infrastructure. Build a VPC by hand: public/private subnets, NAT, endpoints, security groups, NACLs. Then put Session Manager access on a private instance with no inbound rules at all.

Week 7 — Data protection. Create a CMK, write a key policy that denies everything except one role, then encrypt an S3 bucket and enforce it with a bucket policy.

Week 8 — Governance. Set up an Organization, apply an SCP, watch it override an account-level allow. This one experiment teaches the domain.

Weeks 9–10 — Practice exams and gaps. AWS's official practice question set, plus a reputable third-party bank. Read the AWS documentation page for every service you get wrong.

The comparisons the exam keeps asking#

• Security group vs NACL
• Interface endpoint vs gateway endpoint
• Secrets Manager vs Parameter Store
• KMS vs CloudHSM
• SSE-S3 vs SSE-KMS vs SSE-C
• GuardDuty vs Detective vs Security Hub vs Inspector vs Macie
• SCP vs permissions boundary vs session policy
• CloudTrail management events vs data events

Make a one-page table of these and read it the morning of the exam.

Resources#

• The official AWS Exam Guide for SCS-C02 — it is the syllabus.
• AWS Security whitepapers: the Security Pillar of the Well-Architected Framework, the Security Incident Response Guide, and the KMS Cryptographic Details document.
• A sandbox account with a hard billing alarm. Hands-on is not optional at specialty level.
• AWS Skill Builder's official practice question set.

The honest summary#

SCS-C02 is the hardest exam in this list, and it is hardest for people who have only read about AWS. Build things, break them, and read the error messages — that is where the exam's questions actually come from.