The AWS Certified Security – Specialty is one of those exams where knowing the service list gets you nowhere. It assumes you already run workloads on AWS and now wants to see whether you can reason about trust boundaries, blast radius, and log provenance under pressure. The blueprint is six weighted domains, and each one probes a different failure mode.
Quick facts before we dig in: 65 scored questions, 170 minutes, roughly $300 USD, and it sits in the "Specialty" tier — no formal prerequisite, but going in without two-plus years of hands-on AWS security is a fast way to donate $300 to Amazon. You can see the full breakdown and a domain-mapped study path on the AWS Security Specialty exam page, and if you just want to gauge where you stand, run the free AWS Security Specialty practice test before you commit to a study plan.
Here is what each domain is really checking.
Domain 1 — Threat Detection & Incident Response (~14%)
This is the smallest domain by weight but the one people underestimate. It is not "which service detects threats" — it is "an alert just fired, now what do you actually do?"
Expect scenarios around GuardDuty finding types (crypto-mining, credential exfiltration, UnauthorizedAccess:IAMUser/...), Security Hub as the aggregation plane, and Detective for graph-based investigation. The harder questions are the response half: automating containment with EventBridge → Lambda, isolating a compromised EC2 instance by swapping its security group to a deny-all, revoking active IAM sessions, and quarantining a leaked access key.
You need to know the mechanics cold. For a compromised instance you snapshot the EBS volume before touching anything, detach it from auto-scaling, and preserve memory if you can. For a leaked long-term key you don't just delete it — you attach an explicit Deny policy so existing sessions die immediately, then rotate.
Domain 2 — Security Logging & Monitoring (~18%)
This is where CloudTrail lives, and CloudTrail questions are everywhere. Know the difference between management events, data events (S3 object-level, Lambda invoke), and Insights. Know that a single organization trail beats per-account trails, and that log file validation with digest files is what proves your trail wasn't tampered with.
The domain also leans hard on log integrity and centralization: shipping CloudTrail to a locked-down S3 bucket in a separate logging account, using an SCP so nobody — including account admins — can stop the trail. VPC Flow Logs, DNS query logging via Route 53 Resolver, and CloudWatch Logs subscription filters routing to a SIEM all show up.
A classic trap: a question asks how to detect a specific API call and offers both a CloudWatch metric filter + alarm and a GuardDuty finding. Read for whether they want custom detection (metric filter) or managed threat intel (GuardDuty).
Domain 3 — Infrastructure Security (~20%)
The heaviest domain, and the most architectural. This is VPC-centric network security plus edge protection.
Core territory: security groups (stateful) vs NACLs (stateless, and the reason your return traffic gets blocked when you forget ephemeral ports), VPC endpoints (gateway for S3/DynamoDB, interface/PrivateLink for everything else) to keep traffic off the public internet, and endpoint policies to restrict which buckets a VPC can reach.
At the edge: WAF rule groups and rate-based rules, Shield Advanced for DDoS, and CloudFront + WAF layering. You'll also see AWS Network Firewall for stateful, deep-packet filtering across a VPC, and how it differs from a plain NACL. TLS termination decisions — where you offload, when you re-encrypt to the origin — come up in ALB/NLB scenarios.
S3 access from private subnet, no NAT gateway?
-> Gateway VPC endpoint + endpoint policy scoped to the bucket ARN
If a scenario says "traffic must never traverse the public internet," your answer almost always involves a VPC endpoint or PrivateLink.
Domain 4 — Identity & Access Management (~16%)
IAM policy evaluation logic is the beating heart of this domain, and it is where sloppy readers lose points. Memorize the evaluation order: explicit Deny always wins, then check for an Allow, default is implicit deny. Layer in SCPs (which set the maximum permissions boundary for accounts in an Org), permission boundaries, resource-based policies, and session policies — and know that an SCP denying an action overrides any IAM allow underneath it.
Expect gnarly cross-account access questions: resource-based policy on the target (S3 bucket policy, KMS key policy) plus an identity policy on the caller, or AssumeRole with an ExternalId for the confused-deputy problem. IAM Identity Center (successor to AWS SSO), federation with SAML/OIDC, and sts:AssumeRoleWithWebIdentity for workloads all appear.
The single most tested concept: given a policy JSON and a request, can you determine allow or deny? Practice reading Condition blocks — aws:SourceIp, aws:PrincipalOrgID, aws:SecureTransport — because a well-placed condition is often the "most secure" answer.
Domain 5 — Data Protection (~18%)
This is KMS, KMS, and more KMS — plus a bit of Secrets Manager and ACM.
You must understand envelope encryption end to end: the customer master key never leaves KMS, it wraps a data key, the data key encrypts your object. Know the split between AWS-managed keys, customer-managed keys (CMKs — where you control rotation and the key policy), and imported key material. Key policies vs IAM vs grants for delegating decrypt permission is a recurring puzzle.
Then the practical layer: S3 encryption modes (SSE-S3, SSE-KMS, SSE-C, and DSSE-KMS), enforcing encryption with a bucket policy that denies s3:PutObject when s3:x-amz-server-side-encryption is absent, and cross-region considerations since KMS keys are regional. Secrets Manager rotation with a Lambda, and the difference between it and SSM Parameter Store, closes out the domain. Certificate lifecycle via ACM and private CA is fair game too.
Domain 6 — Management & Security Governance (~14%)
The "at scale" domain — how you keep hundreds of accounts compliant instead of one.
AWS Organizations, Control Tower for landing zones and guardrails, and SCPs as preventive controls dominate. Config rules (managed and custom) plus conformance packs are your detective and remediation layer — a question might ask how to auto-remediate a public S3 bucket, and the answer is a Config rule triggering an SSM Automation document. Security Hub standards (CIS, AWS Foundational, PCI DSS) provide the scoring.
Cost-of-ownership and operational tradeoffs sneak in here: centralized vs delegated administrator accounts, using AWS Audit Manager for evidence collection, and Trusted Advisor security checks.
Putting it together
The exam rewards a mental model over memorized service names: who can do what (Domains 1, 4), what got recorded (2), how the network is fenced (3), how the data is wrapped (5), and how you enforce all of it across the org (6). If you can look at any scenario and instantly name which domain's controls apply, you're ready. If you're still guessing between a security group and a NACL, spend another week in the console first — this exam will find that gap.
Top comments (0)