AWS Certified Security – Specialty

The certifications hub already places this exam side by side with CKS and the site's DevSecOps-practitioner credential on one comparison table. This page is what that table can't hold: all six current domains with their published weights, what each domain actually asks a candidate to know with real IAM, KMS and GuardDuty examples, and — because it's the single fact most likely to trip up anyone studying from an old guide — a plain explanation of why the domain names in circulation on plenty of study material are already retired. AWS quietly rewrote this exam's entire domain structure in December 2025.

What this credential is, and the domain rewrite you need to know about first

☺ Like you're 10: It's Amazon's own knowledge test for defending things that run on Amazon's cloud specifically — and the test was quietly rewritten a few months before this page was.

The AWS Certified Security – Specialty exam is issued directly by Amazon Web Services, at the Specialty tier of its own certification ladder — above the Foundational and Associate tiers, alongside the other Specialty credentials rather than above them. It validates a candidate's ability to secure AWS workloads specifically: applying data classification and encryption mechanisms, following secure network protocols, using AWS's own security services correctly, and reasoning about tradeoffs between cost, security, and deployment complexity. Per AWS's own target-candidate description, it's aimed at people with roughly 3–5 years of experience securing cloud solutions. Where the CDE-style credentials covered elsewhere on this site test whether you can do the work against a live environment, this one tests whether you know AWS's specific answers well enough to select them from a list under time pressure.

AWS organizes its own knowledge and skills into "recommended AWS knowledge" for this exam: the shared responsibility model, managing identity at scale, multi-account governance, managing software supply-chain risk, incident prevention and response, cloud vulnerability management, layer 3–7 firewall rules at scale, incident root-cause analysis, audit response, logging and monitoring strategy, encryption at rest and in transit, and disaster-recovery controls. Just as tellingly, AWS also publishes what's explicitly out of scope: designing cryptographic algorithms, packet-level traffic analysis, architecting whole cloud deployments from scratch, managing end-user compute, and training machine learning models. That boundary matters — this is a defender's exam about configuring AWS's own controls correctly, not a cryptography exam and not a general solutions-architecture exam.

Where it sits on AWS's own ladder

AWS certifications run Foundational (Cloud Practitioner) → Associate (Solutions Architect, Developer, the newly renamed CloudOps Engineer — formerly SysOps Administrator, itself renamed on the same late-2025 schedule that swapped in SCS-C03) → Professional (Solutions Architect Pro, DevOps Engineer Pro) → Specialty, a set of narrower credentials — Security, Machine Learning, Networking, Data — that sit beside the Professional tier rather than above it. AWS removed formal prerequisites across its whole certification program at the end of 2018, so nothing blocks booking this exam cold. That doesn't mean it's wise to: the exam's own scenario questions assume Associate-level AWS service fluency as background you already have, the same way the CKA assumes you already know what a Pod is before it asks you to fix one.

The six current domains, weighted

☺ Like you're 10: Six topics, and unlike a lot of exams here, no single one dominates — the biggest is a fifth of the test, not a third.

These are the six content domains and weights exactly as published in AWS's current SCS-C03 exam guide. They sum to exactly 100% — 16 + 14 + 18 + 20 + 18 + 14 — and the shape is worth reading before the content: Identity and Access Management alone is the largest domain at 20%, with Infrastructure Security and Data Protection tied for second at 18% each. Detection and Incident Response — which used to be one combined domain — are now split, at 16% and 14%.

Listed in official order: Detection, Incident Response, Infrastructure Security, Identity and Access Management, Data Protection, and Security Foundations and Governance. That's 16 published task statements across the six domains — 3 + 2 + 3 + 2 + 3 + 3 — noticeably leaner than the equivalent CNCF exam guides on this site, because a multiple-choice knowledge exam doesn't need the same granularity as a performance-based one grading live cluster state.

How SCS-C02 maps onto SCS-C03, if that's what you've already studied

The mapping isn't a simple rename in every row — AWS's own appendix is explicit that Domains 1 and 2 were restructured, not relabeled: the old combined "Threat Detection and Incident Response" and "Security Logging and Monitoring" domains were dissolved and re-split into the new, cleanly separated Detection and Incident Response domains. Only the old Domain 6 was a straight rename, from "Management and Security Governance" to "Security Foundations and Governance." Infrastructure Security, Identity and Access Management, and Data Protection kept their names but not their weights.

Notice Infrastructure Security actually dropped four points (20% → 18%) while Identity and Access Management gained four (16% → 20%) — IAM overtook Infrastructure Security as the single largest domain in the rewrite. If a comparison you've read elsewhere still calls Infrastructure Security "the biggest domain," it's describing SCS-C02.

What the domains actually test

☺ Like you're 10: Here's the real substance behind each percentage — the actual AWS services and the actual configuration choices, not just the domain's name.

Identity and Access Management — 20%

The exam's single largest domain, split across two task statements: designing, implementing, and troubleshooting authentication strategies, and designing, implementing, and troubleshooting authorization strategies. In practice that's IAM users, roles, and policies; federation with IAM Identity Center or an external SAML/OIDC provider; resource-based versus identity-based policies and how AWS evaluates them together; permission boundaries; and — the AWS-specific version of workload identity covered generally in Workload Identity & Pipeline IAM — IAM roles for EC2 instance profiles, IAM Roles Anywhere, and IRSA or EKS Pod Identity for workloads running inside a cluster.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ReadArtifactsWithFreshMFA",
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:ListBucket"],
    "Resource": ["arn:aws:s3:::platform-artifacts", "arn:aws:s3:::platform-artifacts/*"],
    "Condition": {
      "Bool": { "aws:MultiFactorAuthPresent": "true" },
      "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" }
    }
  }]
}

An identity-based policy like that one is never the whole story on AWS: a resource-based bucket policy attached to the same bucket is evaluated alongside it, and an explicit Deny anywhere in either one beats any Allow, no matter how permissive the other policy is. The exam tests that evaluation order directly, and it's the same logic behind the SCP guardrail later on this page.

The Capital One breach disclosed in 2019 is worth knowing cold for this domain and the next one. An attacker used a server-side request forgery against a misconfigured web application firewall to reach the EC2 instance metadata service, retrieved temporary credentials for an IAM role that was authorized to list and read far more S3 buckets than that application ever needed, and used those credentials to exfiltrate roughly 106 million records. Nothing about the initial SSRF was exotic — the finding that actually mattered was an over-permissioned role. AWS's own shipped mitigation is IMDSv2, which requires a session-oriented token obtained via a PUT request before any metadata GET succeeds, defeating the simplest class of SSRF-to-credential-theft attack outright.

# require IMDSv2 on every new instance in the account — the exam-relevant
# control that would have blunted the Capital One SSRF path directly
aws ec2 modify-instance-metadata-options --instance-id i-0abc123 \
  --http-tokens required --http-put-response-hop-limit 1

Study here: Workload Identity & Pipeline IAM for the general least-privilege and short-lived-credential discipline; Zero Trust for Pipelines for why "authenticated" and "authorized to do this specific thing" are two different questions; the Capital One case study for the full breach walkthrough.

Infrastructure Security — 18%

Three task statements: security controls for network edge services (in SCS-C03, explicitly including integrations with third-party services and ingesting findings in Open Cybersecurity Schema Framework format), security controls for compute workloads (newly including guardrails for generative AI applications, referencing the OWASP Top 10 for LLM Applications), and network security controls generally. Concretely: security groups and NACLs, AWS WAF and Shield for edge protection, Network Firewall for VPC-level filtering, and the EKS/ECS container-platform controls this course covers in far more depth in Kubernetes Security Deep Dive and Container Runtime Security.

This is also the domain where the two-part Capital One lesson finishes: the WAF misconfiguration that let the SSRF request through in the first place is squarely Infrastructure Security, while the over-broad IAM role that made the SSRF worth exploiting is Identity and Access Management. The exam, like the real incident, expects you to reason about both layers together rather than treat either one as sufficient alone.

Data Protection — 18%

Three task statements: controls for data in transit (SCS-C03 adds explicit coverage of inter-resource encryption — EMR inter-node encryption, EKS, SageMaker, Nitro encryption), controls for data at rest, and controls to protect confidential data, credentials, secrets, and cryptographic key material — with new SCS-C03 content on the difference between imported and AWS-generated KMS key material, masking sensitive data with CloudWatch Logs and SNS data-protection policies, and managing keys and certificates across single or multiple Regions.

# a customer-managed KMS key, an S3 bucket that can't be created without
# encrypting through it, and a bucket that can't be made public no matter who tries
aws kms create-key --description "platform-artifacts key" \
  --key-usage ENCRYPT_DECRYPT --key-spec SYMMETRIC_DEFAULT

aws s3api put-bucket-encryption --bucket platform-artifacts \
  --server-side-encryption-configuration '{"Rules":[{
    "ApplyServerSideEncryptionByDefault":
      {"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"alias/platform-artifacts"},
    "BucketKeyEnabled": true}]}'

aws s3api put-public-access-block --bucket platform-artifacts \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

Study here: Secrets management for the discipline of never letting a credential sit somewhere it could be found; Cryptography & Key Management for the KMS-specific depth this exam expects; HashiCorp Vault and Sigstore & cosign for the portable, multi-cloud version of the same idea.

Detection — 16% — and Incident Response — 14%

Detection's task statements are designing monitoring and alerting for an account or organization, designing logging, and troubleshooting monitoring, logging, and alerting when it isn't working. Incident Response's are designing and testing an incident response plan, and responding to security events — including, new in SCS-C03, explicitly validating findings from AWS security services to assess an event's real scope before acting on it. Together these two domains are AWS's version of the shift-left-plus-runtime argument made in What is DevSecOps?: catching things early doesn't remove the need to keep watching once something's live.

# wire a GuardDuty finding straight into an automated first response —
# no human has to be awake and watching a dashboard for this to fire
aws guardduty create-detector --enable --finding-publishing-frequency FIFTEEN_MINUTES

aws events put-rule --name guardduty-high-severity \
  --event-pattern '{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],
                    "detail":{"severity":[{"numeric":[">=",7]}]}}'
aws events put-targets --rule guardduty-high-severity \
  --targets 'Id=1,Arn=arn:aws:lambda:eu-west-1:111122223333:function:isolate-instance'

# the containment step itself — strip routable security groups, drop the
# instance into a quarantine group with no rules at all, pending investigation
aws ec2 modify-instance-attribute --instance-id i-0abc123 \
  --groups sg-0quarantine00000000

Study here: Incident response & forensics is the direct match for the Incident Response domain; Detection Engineering & Security Observability for the Detection domain's broader, tool-agnostic version; Falco and Wazuh for the equivalent behavioral-detection tooling outside AWS's own managed services.

Security Foundations and Governance — 14%

Three task statements: developing a strategy to centrally deploy and manage AWS accounts, implementing a secure and consistent deployment strategy for cloud resources, and evaluating the compliance of AWS resources. This is AWS Organizations, Control Tower, Service Control Policies as an account-wide guardrail that only ever subtracts permission and never grants it, AWS Config for continuous compliance evaluation, and Security Hub for aggregating findings against a named standard like CIS or the AWS Foundational Security Best Practices.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnencryptedEBSVolumes",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:volume/*",
    "Condition": { "Bool": { "ec2:Encrypted": "false" } }
  }]
}

An SCP like that one is enforced organization-wide and cannot be overridden by any single account's own IAM policy — it sets a ceiling, not a grant, which is exactly the "only ever subtracts" property that makes it a governance control rather than a permissions control.

Study here: Compliance & governance for the evidence-and-audit-trail half of this domain; Compliance as Code at Scale for expressing exactly this kind of guardrail as a versioned, reviewable artifact instead of a console click; Prowler and ScoutSuite for open-source tools that check an AWS account against the same benchmarks Security Hub does.

Exam logistics — attributed, and due for a re-check by the time you read this

☺ Like you're 10: Here are the numbers Amazon has published. Numbers like these move — check them yourself before you pay.

Everything below reflects the official AWS certification page and the SCS-C03 exam guide as of this page's writing in August 2026. Duration, price, and validity are widely and consistently published figures that AWS's own domain-and-format revision did not appear to change — but a content revision of this size is exactly the kind of event that makes "widely published" worth double-checking rather than trusting.

Why a DevSecOps practitioner might take it — and when to skip it

☺ Like you're 10: Take it if your whole job runs on Amazon's cloud specifically. If it doesn't, you'd be memorizing one landlord's rulebook for a building you don't live in.

Take this exam if AWS is the platform your team's workloads actually run on, and your job increasingly means being the person who can say with confidence whether an IAM role, an SCP, or a KMS key policy is doing what everyone assumes it's doing. It's also a real, unromantic hiring signal at plenty of AWS-committed organizations, independent of how much it teaches you personally. The IAM and Data Protection domains in particular reward exactly the kind of least-privilege, defense-in-depth thinking this whole course argues for — this exam just examines it through one vendor's specific service catalog rather than the portable version.

Where it sits among the other credentials on this site

☺ Like you're 10: It's one specific answer to "prove you can secure a cloud" — useful, but only one of several equally valid answers.

Within AWS's own ladder, Security Specialty sits beside the DevOps Engineer and Solutions Architect Professional exams rather than above them, and requires none of them formally — though the scenario questions assume the Associate-level fluency those exams also build. Outside AWS specifically, the certifications hub compares it directly against CKS and this course's hands-on practitioner credential on assessment style and scope; that three-way framing is the better starting page if you haven't chosen a certification yet. If your organization runs on more than one cloud, treat this page, the AZ-500 page, and the GCP Professional Cloud Security Engineer page as parallel, not sequential — there's no ladder rule that says learn one cloud's security model before another's, only the reality of which cloud your team is actually paying to run.