AWS SCS-C02: The Legacy Security Specialty Blueprint

The AWS Certified Security – Specialty exam version SCS-C02 is no longer the current test. December 1, 2025 was its last date in use; SCS-C03 began on December 2, 2025, according to AWS's official exam comparison. The AWS Certified Security – Specialty certification remains active as a program, but people preparing in October 2026 should use the current Security – Specialty SCS-C03 exam and its revised guide. This historical page explains what SCS-C02 assessed and what changed, so that candidates encountering older courses can distinguish durable security concepts from obsolete exam-version assumptions.

The previous SCS-C02 guide organized scored content into six areas: Threat Detection and Incident Response (14%), Security Logging and Monitoring (18%), Infrastructure Security (20%), Identity and Access Management (16%), Data Protection (18%), and Management and Security Governance (14%). The newer guide splits and reorganizes the detection and response material, raises the weight on IAM, and adds updated requirements for application security and data protection. A stale course that says SCS-C02 is current can mislead candidates even when many of its cloud-security explanations remain accurate.

What the old detection and monitoring split represented

SCS-C02 distinguished threat detection and incident handling from security logging and monitoring as separate domains. Practically, they belong to one evidence-driven workflow. An organization first identifies suspicious activity, preserves trustworthy telemetry, triages a finding, determines scope and business impact, contains threats with appropriate approvals, and investigates root causes. A monitoring tool can detect an unusual event but cannot independently decide whether the event is malicious. Security work requires interpreting context, not treating every finding as proof of compromise.

AWS CloudTrail records supported account and API activity; Amazon CloudWatch collects metrics and log data; Amazon GuardDuty uses supported telemetry and detection techniques to identify potential threats; AWS Security Hub helps aggregate and manage security findings. The tools do not have identical roles. CloudTrail evidence for security investigations can help explain why an investigator needs both a record of access and a defensible timeline of what occurred. Logging is useful only if retention, account permissions and integrity controls prevent routine tampering or accidental deletion.

A detection may be a true security issue, an authorized administrative change, a test or a false positive. Investigators should ask which identity acted, which resource was affected, whether the activity fits historical behavior and which independent signals corroborate it. For example, a reported unusual API call might coincide with a planned migration. Conversely, a familiar role could behave suspiciously if its credentials were stolen. The relationships in GuardDuty findings and investigation workflows remain relevant to historical and current exam candidates because attribution and validation cannot be reduced to alert severity alone.

Under SCS-C03, Detection and Incident Response are explicit separate domains. This is more than a new label. AWS's comparison explains that older threat detection and security-logging tasks were redistributed into designing monitoring and alerting, logging, response planning and response actions. When updating an SCS-C02 study outline, candidates should map each concept to the current task statements rather than using old domain percentages for exam practice.

Infrastructure security required the right boundary

Infrastructure Security was the largest SCS-C02 domain at 20%. Candidates had to reason about network protections, compute hardening, service configuration and exposure control. A VPC provides a logical networking boundary, but it does not prove that every resource inside it is private. Route tables, internet gateways, subnet placement, security groups, network ACLs and endpoint access all affect connectivity. A workload can become publicly reachable through a combination of permissive network policy and application configuration even when the team believes it occupies a “private” network.

Security groups are stateful and evaluated at supported resource interfaces; network ACLs are stateless subnet-level controls. A security engineer should diagnose the complete path before widening access. Private connectivity alternatives may reduce the need to traverse public endpoints for eligible service traffic, but they introduce policy, DNS and routing questions. PrivateLink and VPC endpoint controls provide useful context for preventing unnecessary exposure without assuming all internal connectivity is automatically trusted.

Application edge protection adds other layers. AWS WAF can filter supported web requests according to configured rules; AWS Shield services address supported DDoS protections. Neither substitutes for secure application design or endpoint authorization. An application that trusts a user-controlled order identifier can expose another customer's records even behind a well-configured web firewall. WAF and Shield protections for public applications help distinguish volumetric defense from application-layer misuse.

A historical course might emphasize specific host hardening commands or service settings that have changed. The conceptual questions remain: who can reach the workload, who can administer it, which software runs with privilege, how vulnerabilities are detected and what containment is possible? Use current service documentation for actual configuration, not an old exam screenshot.

Identity and access controls were always central

SCS-C02 gave IAM 16% of scored content; SCS-C03 assigns it 20%. The importance of access controls was never limited to a percentage. AWS policies can include identity-based permissions, resource policies, permission boundaries, session policies and organization service control policies. Their combined evaluation can be more restrictive than any single allow statement suggests. A role that appears to grant access may still be blocked by an explicit deny or an unmet condition. IAM policy evaluation provides the necessary reasoning for safe troubleshooting.

Role assumption and temporary credentials generally offer better control than sharing long-lived access keys across systems. Cross-account roles help manage intended trust relationships but must be constrained on both sides. A trust policy determines who may assume a role; the role's permissions determine which actions it can take once assumed. An identity allowed to assume a powerful role is effectively part of that role's security boundary. The patterns in cross-account access without static keys show why permissions design should address trust and use separately.

A common mistake is assuming that adding AdministratorAccess will resolve any authorization failure. Some controls deliberately prevent actions regardless of account-level administrator permission. AWS Organizations restrictions, resource policies and KMS key policies may still block the request. The proper response is to identify the denied action and governing policy, then authorize the smallest valid operation through the approved process. Overbroad access created during troubleshooting is itself a security defect.

Data protection included keys, storage and lifecycle

Data Protection accounted for 18% of SCS-C02 scored content and retains that weighting in SCS-C03. AWS KMS keys and encryption configuration support protection of supported data at rest, while TLS and other controls protect data in transit where correctly implemented. Encryption should not be confused with access authorization: an application that decrypts for any authenticated user may still disclose sensitive data. Conversely, a properly authorized S3 read can fail if its principal lacks permission to use the key protecting the object.

Key governance includes rotation policies where relevant, separation of key administration and use, recovery planning, grants and the effects of disabling or deleting a key. An encrypted backup may become unrecoverable if its key is unavailable or improperly shared. KMS key policies and envelope encryption highlight why security and recoverability must be evaluated together rather than as isolated technical features.

S3 storage protections may include blocking public access, restrictive bucket policies, object encryption, versioning and Object Lock when appropriate. These measures address different risks. Object Lock can protect against certain deletion or alteration scenarios, but retention settings also create obligations and costs. The discussion of S3 Object Lock and encryption is useful for understanding why backups, immutability and authorization should not be described as equivalent protections.

Governance had an operational dimension

The former Management and Security Governance domain covered security controls across accounts, policies, management practices and compliance evidence. AWS Organizations can apply organization-level guardrails, while AWS Config and security services help identify selected configuration states or findings. Such technical checks are part of governance, not a substitute for it. The organization must still decide which workloads may process regulated data, which Regions are permitted, who owns exceptions, how incidents are escalated and how compliance evidence is retained.

The current SCS-C03 program calls the corresponding domain Security Foundations and Governance and uses updated task allocations. The older material remains useful when it explains account isolation, identity federation, logging ownership and the need to validate security posture across an estate. Security Hub for multi-account security posture is one current example of consolidating visibility while leaving policy ownership and corrective action with the organization.

A security control should have a testable objective. “Encrypt everything” is not adequate guidance without specifying what data, which keys, who can decrypt, where plaintext appears and how recovery works. “Enable monitoring” is equally incomplete without defining events of interest, alert owners, investigation workflow and retention. Strong exam preparation treats AWS service settings as expressions of a broader control design.

The SCS-C03 changes that invalidate an old study plan

AWS's official side-by-side comparison shows SCS-C03 weights of Detection 16%, Incident Response 14%, Infrastructure Security 18%, IAM 20%, Data Protection 18%, and Security Foundations and Governance 14%. Compared with SCS-C02, it introduces explicit material on protections for generative AI applications, third-party and edge integrations, sensitive-data masking, additional encryption scenarios and distinctions involving key material. It also removes or recategorizes some older task statements. These are concrete syllabus changes, not a mere replacement of “C02” with “C03” in a course title.

Candidates using archived SCS-C02 notes should label what remains useful and what needs replacement. The best migration method is to read the current AWS SCS-C03 guide, compare the domain maps and test new objectives using current product documentation. An old outline may still help explain IAM policy evaluation, VPC boundaries or KMS; it should not determine scoring weights, emerging threats or appointment selection.

The page exists to preserve the historical meaning of the SCS-C02 URL, not to persuade readers to sit an unavailable version. Candidates seeking the current exam should focus on the SCS-C03 syllabus and confirm scheduling details directly with AWS. Understanding the old blueprint is valuable for interpreting earlier training and the evolution of security practice, but the current standard of competence is established by the active exam's published objectives and the organization's real threat environment.