The AWS Certified Security - Specialty exam is best approached as an operations exam, not a reading exam. Its scenarios ask what a working security engineer would do: why was this request denied, which key design meets this requirement, which service detects this behaviour, what do you do first when an instance is compromised. This guide is built as a full self-study course for the current SCS-C03 version: it walks through all six official domains in depth, pulls out the concepts the scenarios are built on, and turns everything into a week-by-week plan. It contains study guidance and original explanations only - no real or simulated exam questions - and you should confirm current details against the official SCS-C03 exam guide before you book.
Chapter 1: Exam overview and how to use this guide
What the exam measures
AWS Certified Security - Specialty validates that you can secure AWS workloads in production: create and troubleshoot least-privilege access, protect data with the right key architecture, detect and investigate threats, respond to incidents, and govern security across many accounts. The current version, SCS-C03 (in use since December 2, 2025), weights its six domains as follows: Identity and Access Management at 20%, Infrastructure Security at 18%, Data Protection at 18%, Detection at 16%, Incident Response at 14%, and Security Foundations and Governance at 14%. Those weights are your study compass - IAM alone is a fifth of the scored content, and IAM thinking leaks into every other domain.
The exam runs 65 questions in 170 minutes, of which only 50 are scored; 15 are unscored pretest items you cannot identify. You need a scaled 750 out of 1000, under a compensatory model - your overall score decides, and no single domain has its own pass line. Alongside multiple-choice and multiple-response items, SCS-C03 introduced ordering items (arrange steps in sequence) and matching items (pair related elements), and a matching item scores only when every pairing is correct. Unanswered questions count as wrong, so you always answer.
Why experience matters more than reading
AWS recommends the equivalent of 3-5 years securing cloud solutions, and the question style shows why: most items describe a situation - a denied request, an audit requirement, a suspicious finding - and ask for the best response among plausible options. The distractors are usually real services used slightly wrong. That is judgement, and judgement comes from operating the services. Every chapter below therefore ends in the same advice: rebuild the scenario in a sandbox account until the behaviour is intuition, not memory.
How to use this course
Work the chapters in the exam guide’s domain order or jump to your weak areas - but do IAM (Chapter 5) early even though it appears mid-outline, because policy evaluation underpins everything else. Treat the bold terms as a checklist you can explain in one sentence each. Pair each chapter with hands-on practice, use the official exam guide as your master list, and note what the guide explicitly excludes - designing cryptographic algorithms, packet-level analysis, full cloud architecture design - so you do not over-study. One integrity note: AWS’s certification policies prohibit sharing or using live exam content, so build your skills from documentation, original practice material and labs, never from sites claiming to sell actual questions.
Chapter 2: Detection (16%)
The detection toolset and which question each tool answers
The domain’s core skill is mapping a monitoring need to the right service. Amazon GuardDuty is the threat detector: it continuously analyses CloudTrail events, VPC Flow Logs, DNS query logs and workload telemetry for signs of compromise - unusual API activity, known-bad infrastructure, credential misuse - and raises findings with severities. AWS Security Hub is the aggregator: it collects findings from GuardDuty, Inspector, Macie and partner tools across accounts, normalises them, and runs automated checks against security standards. Amazon Detective is the investigator: it builds a behaviour graph from your logs so you can trace what an entity did around the time of a finding. Amazon Inspector is the vulnerability scanner for EC2 instances, container images and Lambda functions. A typical scenario names a need - “we must be alerted when instances communicate with known malicious hosts” - and rewards the candidate who picks the detector, not the aggregator or the scanner.
Logging strategy: CloudTrail, Config and Flow Logs
Detection is only as good as its inputs, and the exam expects you to know what each log source contains. CloudTrail records API activity: management events (control-plane operations) are on by default, while data events - S3 object-level access, Lambda invocations - are opt-in, high-volume, and frequently the missing ingredient when a scenario says “we cannot see who read the object”. CloudTrail’s log file integrity validation produces signed digests that prove log files were not modified after delivery, the standard answer to “how do we make the audit trail tamper-evident”. AWS Config records resource configurations over time and evaluates them against rules, which makes it the drift-and-compliance history rather than an activity log. VPC Flow Logs capture connection metadata - who talked to whom, on which ports, accepted or rejected - but never packet contents. Centralising these logs from many accounts into a dedicated account, with tight access and lifecycle policies, is the architecture the exam repeatedly rewards.
From signal to action
Raw findings only matter if something happens next. CloudWatch metric filters and alarms turn log patterns into notifications; Amazon EventBridge routes GuardDuty and Security Hub findings to targets - a ticket queue, a chat channel, or an automated remediation workflow. SCS-C03 also added awareness of OCSF (Open Cybersecurity Schema Framework), the normalised findings format that lets third-party tools consume AWS security data cleanly. The recurring design pattern to internalise: detect in every account, aggregate centrally, route by severity, automate the responses you have rehearsed.
Chapter 3: Incident Response (14%)
Preparation: the work done before the incident
The exam treats incident response as something you architect in advance. Preparation means written playbooks and runbooks for the likely scenarios (compromised credentials, compromised instance, public data exposure), a dedicated forensics environment with pre-provisioned access, and rehearsals - game days - so the first execution of a playbook is never during a real incident. Scenarios that mention “the team was unsure who could access the affected account” are pointing at preparation gaps, not tooling gaps.
Containment that preserves evidence
When compute is compromised, the tested instinct is contain first, preserve, then eradicate. Conceptually: isolate the instance by swapping its security group for a restrictive one and detaching it from load balancers or auto scaling so it stops serving traffic but keeps running; snapshot its EBS volumes for analysis; preserve logs; and only rebuild once evidence is captured. Terminating the instance immediately feels decisive but destroys the forensic trail - a distinction the exam probes from several angles. Where memory matters, capture it before any reboot. All of this is defensive procedure; the exam never asks you to perform an attack, and neither does this guide.
Credential compromise and automated response
For exposed access keys or assumed-role sessions, the response pattern is: invalidate the credential (deactivate the key, revoke active sessions), restrict the principal, then audit with CloudTrail what the credential touched while exposed, and remediate what it changed. Because minutes matter, the domain also covers automation: EventBridge rules that react to specific GuardDuty findings by triggering isolation or notification workflows automatically. The judgement the exam wants: automate the contained, rehearsed responses; keep humans in the loop for destructive ones.
Chapter 4: Infrastructure Security (18%)
Network boundaries: security groups, NACLs and VPC design
The foundational distinction is security groups versus network ACLs. Security groups sit at the instance (ENI) level, hold allow rules only, and are stateful - return traffic is automatically permitted. Network ACLs sit at the subnet boundary, hold numbered allow and deny rules, and are stateless - both directions need explicit rules. Most connectivity puzzles in this domain resolve to knowing which layer is blocking. Around them sits VPC design: private subnets for anything that does not need inbound internet exposure, and VPC endpoints so workloads reach AWS services like S3 privately, with endpoint policies restricting what can be accessed through them - the standard answer to “traffic must not traverse the public internet”.
Edge and network-layer protection
For internet-facing workloads the exam layers three services. AWS WAF filters HTTP(S) requests at layer 7 with rules against injection patterns, bots and abuse, attached to CloudFront, ALBs or API Gateway. AWS Shield provides DDoS resilience - Standard automatically for everyone, Advanced as a subscription with deeper protections and response support. AWS Network Firewall is the managed VPC-level firewall for stateful inspection and domain filtering at scale, the answer when security groups and NACLs are too blunt (they cannot filter by domain name, for instance) and requirements demand centralised egress control. The skill is picking the layer that actually addresses the stated threat rather than stacking everything.
Securing compute access
Two patterns recur. First, administrative access: AWS Systems Manager Session Manager provides audited shell access with no open inbound ports, no bastion hosts and no long-lived SSH keys, which makes it the preferred answer over port-22 access almost whenever it appears. Second, instance credentials: IMDSv2, the session-token version of the instance metadata service, protects the credentials an instance holds from being extracted through request-forgery tricks, and enforcing it is a common hardening requirement. Add Amazon Inspector for continuous vulnerability scanning of instances, images and functions, and you have this domain’s compute story: minimal exposure, audited access, patched software.
Chapter 5: Identity and Access Management (20%)
The evaluation logic that decides everything
The exam’s largest domain rests on one mental model: how AWS decides a request. Start from implicit deny - nothing is allowed by default. An explicit deny in any applicable policy ends the evaluation immediately; nothing overrides it. Otherwise, the request needs an allow that survives every applicable layer: the SCPs of the account’s organization, the identity’s permissions boundary if one is set, and session policies, alongside the identity-based or resource-based policy that grants the action. Two consequences carry many questions. First, SCPs and permissions boundaries are ceilings, not grants - they bound what could be allowed but never authorise anything themselves. Second, cross-account access requires an allow on both sides: the caller’s identity policy and the target resource’s policy (or an assumed role in the target account). Practise verbalising a denial: “the identity policy allows it, but the SCP does not include the action, so the request is denied before the identity policy matters.”
Roles, temporary credentials and cross-account trust
IAM roles - identities with temporary credentials issued by AWS STS - are the mechanism behind almost every good access pattern: applications on EC2 use instance roles instead of stored keys; humans assume roles across accounts; services act through service roles. A role’s trust policy controls who may assume it, and for third-party cross-account access an external ID in that trust policy prevents the confused-deputy problem, where a vendor could be tricked into using its access on the wrong customer’s behalf. Condition keys sharpen all of it: aws:PrincipalOrgID to restrict a resource to callers from your own organization, source-IP and VPC conditions, and MFA requirements. The exam reads these policies with you - expect JSON in the question and small but decisive details in the conditions.
Workforce access at scale
For humans across many accounts, the modern pattern is AWS IAM Identity Center: one workforce directory (or a federated external IdP via SAML/OIDC), permission sets that materialise as roles in member accounts, and short-lived credentials throughout - the answer that beats creating IAM users in every account. Scenarios distinguish workforce access (Identity Center), workload access (roles), and legacy patterns (long-lived access keys) - and the long-lived key is almost always the thing to eliminate. Round the domain out with least privilege as a process: start narrow, review access, and tighten policies over time rather than treating permissions as write-once.
Chapter 6: Data Protection (18%)
KMS: the key architecture decisions
AWS KMS carries most of this domain. Know the key types and what choosing each means: AWS managed keys are zero-administration but offer no custom key policy and no control over rotation; customer managed keys (CMKs) put the key policy, rotation, grants and deletion under your control - the choice whenever compliance, cross-account access or fine-grained audit is in the requirements. Imported key material brings your own material into KMS, keeping origin and expiry responsibility with you, and multi-Region keys replicate a key across Regions so data encrypted in one can be decrypted in another - the disaster-recovery and cross-Region answer. Two control-plane facts anchor many questions: the key policy is the primary access control on a key, and IAM policies govern key use only where the key policy delegates to IAM; and grants provide temporary, programmatic permissions without policy edits. Underneath it all sits envelope encryption: data is encrypted with a data key, and KMS encrypts that data key - which is why KMS’s small direct-encryption limit never matters for bulk data.
Encryption in transit and private PKI
For public TLS, AWS Certificate Manager (ACM) issues and - its quiet superpower - automatically renews certificates for load balancers, CloudFront and API Gateway. For internal certificates, AWS Private CA runs a managed private certificate authority, the answer when services inside your network must authenticate each other with certificates you control. SCS-C03 expanded transit-encryption coverage into analytics and container platforms - node-to-node encryption for services such as EMR and EKS - so read “encrypt traffic between cluster nodes” as in-scope, not exotic.
Secrets, storage encryption and sensitive-data discovery
Three recurring choices. Secrets Manager versus Parameter Store: Secrets Manager adds native automatic rotation (including managed database credential rotation) at a per-secret price; Parameter Store’s SecureString is the budget option without native rotation - the scenario’s rotation requirement decides. SSE-S3 versus SSE-KMS: both encrypt objects server-side, but SSE-KMS uses a KMS key you can control and audit - CloudTrail records each use - which is why “prove who decrypted the data” always points to SSE-KMS with a CMK. And Amazon Macie discovers and classifies sensitive data such as PII in S3, feeding findings into Security Hub. C03 also added data protection policies that detect and mask sensitive fields inside CloudWatch Logs and SNS messages - the answer when the requirement is “developers may read the logs but not the card numbers in them”.
Chapter 7: Security Foundations and Governance (14%)
Shared responsibility, precisely
The shared responsibility model sounds introductory but is tested with precision: AWS secures the cloud - facilities, hardware, the hypervisor, managed-service internals - while you secure what you run in it. The exam’s angle is how the line shifts by service type: on EC2 you patch the operating system; on a managed database AWS patches the engine while you own access and data; with Lambda the runtime hosts are AWS’s problem and your surface shrinks to code, permissions and data. Scenarios ask who is responsible for a given layer, and the wrong answers put your obligations on AWS or vice versa.
Governing many accounts
Real AWS estates are multi-account, and this domain covers the machinery: AWS Organizations groups accounts into organizational units with consolidated billing and SCP guardrails; AWS Control Tower builds and governs a landing zone - a pre-architected multi-account environment with preventive and detective controls already wired. Around them sit the governance patterns from earlier chapters, now viewed organization-wide: delegated administrator accounts for security services, centralised logging, and GuardDuty and Security Hub aggregating across every member account. The design instinct the exam rewards: put guardrails at the organization level, keep workloads in separate accounts, and give the security team its own accounts for tooling and logs.
Compliance evidence and the expanding edge
AWS Artifact is the self-service source of AWS’s own compliance reports - SOC, ISO, PCI - the thing you hand auditors to cover the AWS side of shared responsibility, while your Config rules, CloudTrail archives and Security Hub standards cover yours. AWS Trusted Advisor contributes baseline checks - open security groups, IAM misconfigurations - as a governance backstop. SCS-C03 also pushed the domain’s edge outward: securing generative-AI applications, with awareness of the OWASP Top 10 for LLM applications, now sits in scope at the concept level - treat prompt injection and data leakage through model inputs and outputs as governance risks to recognise, not tooling to configure.
Chapter 8: Study plan, practice strategy, and exam day
Allocate time by weight, but front-load IAM
Let the official weights set your baseline - IAM (20%) and the Data Protection / Infrastructure pair (18% each) deserve half your calendar - but start with IAM regardless of the order you study the rest, because policy evaluation is the grammar the whole exam is written in. A typical plan for someone matching AWS’s recommended profile runs eight weeks at 8-10 hours a week: two weeks on IAM, two on data protection, one each on infrastructure and detection, one on incident response plus governance, and a final week of timed practice. Working security engineers can compress to six weeks; strong generalists newer to security should stretch to twelve and spend the extra time in a sandbox account. To turn any of these into dated weeks for your own start date, use the free study-plan generator.
Practise judgement, not recognition
Because the exam tests selection and configuration judgement, practise by explaining: for every practice scenario, articulate why the right answer wins and why each distractor fails - the distractors are usually real services used slightly wrong, and naming the “slightly” is the skill. Rebuild the classic scenarios hands-on: engineer a denial and diagnose it, break and fix a key policy, isolate an instance while snapshotting it, route a GuardDuty finding through EventBridge. Drill the new item types by writing sequences from memory - incident response order, policy evaluation order - since ordering and matching items give no partial credit. Benchmark with the official Skill Builder practice question set before booking. If you are weighing this exam against a vendor-neutral alternative, the CCSP vs CISSP comparison shows what the ISC2 route emphasises instead.
Exam day
You sit 65 questions in 170 minutes at a Pearson VUE centre or via online proctoring - about two and a half minutes per question, which is genuinely enough if you keep moving. Flag long scenario items rather than stalling; the 15 unscored pretest questions are invisible, so treat every question as real. Answer everything - unanswered counts as wrong and there is no guessing penalty. Read matching items twice before committing, since only a fully correct set scores. Results are not shown on screen; they appear in your AWS Certification account within five business days, and a pass is valid for three years, renewable by passing the then-current version of the exam.