AWS SCS-C02: Understanding the Former Security Specialty Exam

A candidate finds an AWS Certified Security – Specialty practice set labeled SCS-C02 and assumes it must be the current version because much of its material still discusses IAM, GuardDuty, CloudTrail and encryption. The technology may be relevant, but the exam code is not current. AWS delivered SCS-C02 through December 1, 2025, and SCS-C03 began on December 2, 2025. The distinction matters when a candidate chooses study material, interprets a blueprint or attempts to book a test. The retired blueprint still provides useful security foundations, but preparation for a new attempt must follow SCS-C03’s published objectives.

Security skills do not vanish when a certification guide changes. A professional who studied identity policy evaluation, cross-account access, network segmentation, incident evidence and encryption on the earlier exam learned concepts that remain important. But the weight of those concepts, the structure of the objectives and several tested tasks changed. Treating the two guides as interchangeable can leave gaps even when every practice question seems technically plausible.

What changed between SCS-C02 and SCS-C03

The SCS-C02 blueprint had six domains: 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%). AWS reorganized the successor version to separate Detection and Incident Response, increase the share of IAM and update the scope of governance and infrastructure controls.

Historical SCS-C02 and current SCS-C03 weightings

Earlier SCS-C02 topic	SCS-C02	Related SCS-C03 topic	SCS-C03
Threat Detection and Incident Response	14%	Detection	16%
Security Logging and Monitoring	18%	Incident Response	14%
Infrastructure Security	20%	Infrastructure Security	18%
Identity and Access Management	16%	Identity and Access Management	20%
Data Protection	18%	Data Protection	18%
Management and Security Governance	14%	Security Foundations and Governance	14%

This table is a guide to domain emphasis, not an assertion that every paired row tests identical content. For example, the earlier detection-and-response work and the separate logging-and-monitoring domain were redistributed across the current Detection and Incident Response categories. AWS publishes a detailed crosswalk describing those task-level changes. Candidates preparing for today's exam should use AWS Security Specialty SCS-C03 and its current guide as the primary reference rather than trying to reconstruct the new blueprint from an old practice set.

Detection and logging require different kinds of judgment

The old exam asked candidates to choose appropriate ways of observing account, workload and network activity. AWS CloudTrail records supported API activity, Amazon CloudWatch helps collect metrics and logs, VPC Flow Logs can describe network-flow metadata, and services such as Amazon GuardDuty and AWS Security Hub provide different security findings and aggregation capabilities. None offers a universal record of every activity that matters to an investigator.

Imagine a service role unexpectedly changing an S3 bucket policy. The responder wants to know which principal made the API call, from where, and what related actions followed. A resource utilization graph will not answer those questions. CloudTrail and relevant service or configuration records may be necessary, alongside logs showing whether the policy change caused object access. Security engineering begins by matching the evidence source to the question, preserving sufficient history and knowing what the logs do not contain.

Security logging also has a resilience problem. Sending logs to a centralized account can aid consistent retention and review, but the pipeline must be protected from accidental deletion, policy mistakes or a compromised workload. Ingesting everything without classification, access controls or retention planning can create high costs and expose sensitive payloads to people who should not see them. The old SCS-C02 scope recognized that logging is a system with operational boundaries, not simply a switch that should always be turned on without thought.

Modern security detection and incident response still depends on trustworthy logs, identities and workload evidence. SCS-C03 material can extend that understanding, but it does not redefine the former SCS-C02 blueprint.

Infrastructure security depends on the complete traffic path

A workload can be placed in a private subnet yet still expose data through permissions, outbound connections or a shared service boundary. Security groups, network ACLs, route tables, firewalls, load balancers, WAF rules and VPC endpoints answer different parts of the question: who can reach a resource, over which path, with which controls and under what application authorization. Candidates needed to understand these distinctions when reasoning about infrastructure risk.

For example, an application uses an internet-facing load balancer but runs its compute tier in private subnets. A design review should consider the edge protection, permitted listener routes, target security rules, health checks, outgoing dependencies and how the database is shielded from unintended paths. A blanket instruction to 'make the application private' is not an architecture. The right exposure depends on whether the customer-facing interface itself must be public and which backend traffic must remain restricted.

Cross-account sharing introduces additional boundaries. A route from one VPC to another establishes potential network reachability but does not authorize access to S3 objects or database records. Identity controls and resource policies must be evaluated separately from packet movement. Overlapping CIDR ranges, unintended transitive routes and broad shared services can create security or reliability problems despite apparently correct isolated settings.

Current SCS-C03 infrastructure coverage also contains newer emphasis, including protections relevant to generative AI applications and supported security-service integrations. An old exam bank that ignores these developments cannot be assumed complete for the current examination even when its networking questions remain useful technical exercises.

Identity policies need both trust and authorization reasoning

IAM work is often summarized too casually as granting an Allow action. The effective permission can depend on identity policies, resource policies, permissions boundaries, service control policies and explicit Deny statements. The ability to assume a role is not the same as authorization to read every resource after assumption. Candidates should trace the requesting principal, role trust relationship, allowed action, target resource and applicable guardrails before selecting a fix.

Consider a backup process that can read a snapshot but cannot restore it into a recovery account. The access chain may involve a role that lacks permissions, a resource policy that excludes the account, or a KMS key policy preventing decryption. Broadly adding `*` to an identity policy may fail to solve the real problem while enlarging risk. A precise diagnosis identifies which policy boundary stops the requested action and whether expanding it meets the least-privilege requirement.

Human access management has a different lifecycle. Emergency administrator access needs approval, strong authentication, session accountability and review. Routine automation should not depend on one person's long-lived keys. AWS Organizations and IAM Identity Center can support centralized arrangements where appropriate, but organizational structure does not by itself create clean authorization. Security ownership, joiner/mover/leaver processes and exception handling still matter.

The expanded IAM weight in SCS-C03 highlights the importance of this discipline. Candidates reading historic SCS-C02 notes should place extra emphasis on the active examination's current authorization and authentication statements rather than relying on the old domain percentage alone.

Data protection means managing the whole lifecycle

Encryption at rest and in transit serve distinct purposes and neither automatically restricts application-level access. AWS KMS supports controlled cryptographic key management; AWS Secrets Manager helps manage sensitive credentials. Amazon S3 policies, bucket settings, versioning, lifecycle choices and account permissions affect how stored objects can be used. Sensitive data also travels through backups, logs, caches and analytics pipelines, where different controls may apply.

A security reviewer should examine key lifecycles and recovery assumptions. Imagine backups replicated to another Region, but the recovery role lacks the rights needed to decrypt them. Copying ciphertext is not the same as proving recoverability. Consider who can create, rotate, disable or use keys, and what happens during a disaster or account compromise. These design choices matter in both SCS-C02 history and SCS-C03 preparation.

The distinction between an encryption key and an API secret is also practical. Rotating a database password is not the same as changing a data-encryption key, and protecting one will not necessarily protect the other. Teams need an inventory of sensitive assets, the processes that use them and the people or workloads authorized to perform each operation.

For a deeper current treatment, data protection in AWS security architecture examines the control decisions around encryption, access and recovery. The technology concepts are transferable even when exam objectives are not word-for-word identical.

Security governance was never just a compliance report

The earlier SCS-C02 governance content included applying organizational security standards, assessing configurations and managing security controls across AWS accounts. A secure multi-account design should make it clear who owns the root-level organization settings, what service restrictions apply, how logs are aggregated and how resource deviations are detected. Control consistency matters, but a uniform setting is not always appropriate for every workload.

A central prohibition on an insecure storage configuration may be suitable across many accounts. A particular production service may still need a documented exception for region placement or networking. Good governance provides a review path, time-bound ownership and evidence that an exception was justified. A dashboard of passing configuration checks is helpful only if those checks represent real business and security requirements.

Incident response processes should also recognize that security and reliability objectives can compete. Isolating a compromised instance may preserve the environment but interrupt customer traffic; leaving it running may preserve service while allowing attacker activity. Preplanned containment options, evidence handling and clear authority allow teams to act under pressure without improvising every risk trade-off.

How to use SCS-C02 material responsibly now

Use historical SCS-C02 questions as exercises in reasoning, not as promises about current exam objectives. When the scenario involves a network path, trace actual flow and permissions. When it involves a KMS failure, identify the key policy and principal. When it involves investigation, state what evidence would prove the hypothesis. Then compare the scenario against the current SCS-C03 guide and any newly introduced tasks before drawing conclusions about examination readiness.

Do not describe SCS-C02 as an alternate active delivery route or a separate currently offered Security Specialty credential. It is a predecessor version. Existing professionals may accurately describe having passed SCS-C02 when it was available, while current candidates should prepare for SCS-C03 instead.

The enduring lesson of the former exam is that cloud security requires several complementary control layers. The version-specific lesson is just as important: strong foundational knowledge is not permission to ignore an issuer's updated syllabus, lifecycle dates or current practical requirements.