AWS Security Specialty: From SCS-C02 to SCS-C03

AWS Certified Security – Specialty has moved beyond SCS-C02. AWS used SCS-C02 through December 1, 2025 and switched to SCS-C03 on December 2, 2025. Candidates preparing in 2026 should therefore treat SCS-C02 as a legacy blueprint and build their study plan around the current SCS-C03 Security – Specialty exam.

The certification still validates advanced AWS security skills, but the updated blueprint reorganizes the work around detection, incident response, infrastructure security, identity and access management, data protection, and security foundations and governance. AWS also added newer security concerns, including integrations using OCSF, generative-AI workload protections, expanded data-protection patterns, and modern key-management scenarios.

The most useful way to prepare is to think like a cloud security engineer: design controls, prove they work, detect failure, respond to incidents, and govern the environment across accounts. Memorizing isolated security services is not enough.

SCS-C03 separates detection from incident response

SCS-C02 combined threat detection and incident response in one domain and treated logging and monitoring as another. SCS-C03 reorganizes that work into a Detection domain and a separate Incident Response domain. The distinction matters because detecting a suspicious event and handling it are different engineering responsibilities.

Detection includes logging architecture, monitoring, alerting, and the ability to troubleshoot missing or misleading security telemetry. Incident response adds playbooks, evidence collection, containment, scoping, recovery, and the evaluation of findings from AWS security services.

For hands-on study, build a small environment where activity is recorded centrally. Generate known events, verify the logs, trigger a finding or alert, and document how you would investigate it. The important skill is the chain from evidence to action.

Infrastructure security requires edge, compute, and network controls to work together

SCS-C03 expects candidates to design and troubleshoot controls at the network edge, around compute workloads, and inside VPC connectivity. That means understanding how web application firewalls, DDoS protections, security groups, network ACLs, routing, load balancers, private connectivity, and workload hardening interact.

A strong security design is layered. A restrictive security group does not replace application authentication. A WAF does not replace secure code. Private subnets do not eliminate the need for IAM. The exam often asks candidates to choose the control that solves a specific part of the problem without introducing unnecessary complexity.

Networking knowledge therefore remains foundational. Reviewing AWS VPC design and configuration is useful because security decisions depend on where traffic flows, where it can be inspected, and which services are reachable through public or private paths.

IAM carries more weight in the current blueprint

Identity and Access Management represents a larger share of scored content in SCS-C03 than it did in SCS-C02. Candidates should be comfortable designing authentication and authorization strategies, not just reading IAM policy syntax.

Study federation, IAM roles, temporary credentials, permissions boundaries, resource policies, organization controls, least privilege, cross-account access, service roles, and the difference between authentication and authorization. Then practice troubleshooting. A policy that looks correct in isolation can still fail because of another policy layer, trust relationship, resource policy, explicit deny, or organization-level control.

Security engineers should also think operationally: how are identities provisioned, reviewed, rotated, disabled, and monitored? A technically valid access model can still be weak if no one owns the lifecycle.

Data protection now extends deeper into transit, storage, keys, and sensitive-data handling

SCS-C03 keeps data protection as a major domain while expanding some of the scenarios. Candidates need to understand encryption in transit and at rest, AWS KMS, certificate management, secrets, key policies, rotation, imported key material, multi-Region key strategies, and service-specific encryption behavior.

The exam is less about memorizing that “encryption is good” and more about choosing the right mechanism. When should a customer-managed key be used? Which principal needs permission in the key policy? How should applications retrieve secrets? How can sensitive content in logs or messages be masked? How do certificate and key decisions change across accounts or regions?

Practice by tracing one piece of sensitive data through a workload. Identify every place it is stored, every network hop it takes, every identity that can access it, and every key or secret involved. That creates a complete protection model.

Security governance is an engineering system, not a policy document

The Security Foundations and Governance domain covers account strategy, consistent deployment controls, and compliance evaluation. In a small environment, a security engineer can inspect individual resources manually. In an enterprise organization with many AWS accounts, that approach does not scale.

Candidates should understand centralized governance, account structures, organization policies, infrastructure as code, configuration controls, security baselines, and ways to evaluate compliance continuously. The goal is to make the secure configuration the easiest configuration to deploy.

This is also where cost, deployment complexity, and security trade-offs become important. A security control that requires constant manual exceptions may not survive real operational pressure. Strong governance reduces the need for manual judgment by encoding clear guardrails.

Generative-AI security is now part of AWS security specialization

One of the notable SCS-C03 additions is protection for generative-AI applications. That reflects the reality that cloud security teams are increasingly responsible for systems using foundation models, retrieval, agents, and model-driven automation.

Security engineers need to think about prompt injection, data exposure, unsafe tool access, identity propagation, model access, input and output filtering, and the trust boundary between a model and the systems it can call. These risks do not replace traditional cloud controls; they are layered on top of them.

The AWS AI security and responsible-AI concepts provide useful context because AI governance, data protection, identity, and application security are becoming increasingly intertwined.

Build security labs around failure and investigation

Security certification becomes much easier when labs are designed to fail. Create an IAM role that is missing one permission and diagnose the result. Misconfigure a security group and trace the blocked path. Rotate a secret and test the application. Generate a CloudTrail event and find it centrally. Encrypt data with a KMS key and then test what happens when access to the key is removed.

These exercises teach the difference between knowing a service and troubleshooting a control. SCS-C03 scenarios often require the second skill.

Keep a short incident notebook. For each lab, record the symptom, evidence, hypothesis, control change, and final verification. That habit mirrors real security operations and helps candidates reason under exam pressure.

Use the blueprint verbs to set the depth of study. SCS-C03 uses verbs such as design, implement, troubleshoot, respond, evaluate, and develop. Those verbs imply more depth than “identify” or “describe.” If a task says design and troubleshoot network security controls, candidates should expect scenarios where several services appear plausible and the correct choice depends on architecture behavior.

Turn each task statement into a practical question. Can you explain the design? Can you configure a minimal version? Can you identify what evidence would prove it works? Can you diagnose the likely failure modes?

This prevents two common preparation errors: learning only service definitions, or going too deep into details the blueprint does not require. The task statements tell you what kind of competence is being tested.

Legacy SCS-C02 knowledge is useful only when it maps to the current exam. Older SCS-C02 books and courses can still teach IAM, encryption, networking, logging, and incident response effectively. The danger is assuming their domain structure and service emphasis remain current. AWS explicitly moved, added, and removed content when creating SCS-C03.

Use legacy material topic by topic. If it teaches KMS key policies or VPC security well, keep it. If it spends time on a task statement that no longer appears, do not let that content crowd out current priorities such as updated detection, generative-AI controls, or revised governance coverage.

The current blueprint should always be the index. Old material is a library, not the syllabus.

Map the SCS-C02 material you already know into the new blueprint

Candidates who already studied SCS-C02 do not need to throw that work away. Much of the technical foundation carries directly into SCS-C03, but it needs to be reorganized. Logging and monitoring now feed a dedicated Detection domain. Incident handling is separated into its own domain. IAM has greater weighting. Governance has been reframed around security foundations and organizational control, while newer content adds more explicit attention to generative-AI protections and modern data-protection patterns.

Create a migration table for your notes. Put each old topic into one of the six current domains and mark anything that has no obvious home. Then compare that table with the current exam guide. This reveals two kinds of risk: material you studied that is no longer emphasized, and new material your old course never covered. It is a much cleaner way to transition than starting a second set of notes from scratch.

The same method works for labs. Keep the IAM, KMS, VPC, CloudTrail, and incident-response exercises that still teach current skills. Add new exercises only where SCS-C03 introduces a meaningful new task. That preserves useful effort while keeping the syllabus current.

Prepare like a security engineer who owns the whole control lifecycle

A strong SCS-C03 candidate can move from architecture to operation. They can design identity and network controls, protect data, centralize logs, detect suspicious behavior, respond to incidents, and enforce governance across accounts. That is a broader responsibility than configuring one security service.

Build your study plan around that lifecycle. Start with architecture and IAM, then data protection and network controls, then central logging and detection, then incident response and governance. Revisit the same lab environment from each perspective so the concepts connect.

SCS-C02 was an important step in the certification’s evolution, but it is no longer the exam. Candidates preparing now should use SCS-C03 as the source of truth and treat the transition as an opportunity to align study with the way cloud security work has actually changed.