SCS-C02: The Retired AWS Security Specialty Exam and Its Current Successor

AWS Certified Security – Specialty examines cloud security decisions that reach across identities, networks, data, detection, and organizational guardrails. Its former SCS-C02 version remains visible in old training plans and archived examination URLs, but it should no longer be represented as a current booking option. AWS used SCS-C02 through December 1, 2025 and introduced SCS-C03 on December 2, 2025. People who earned a credential under the earlier exam retain its normal validity; someone preparing for a new sitting must use the current AWS Security – Specialty SCS-C03 examination requirements.

The retired SCS-C02 guide grouped its content into 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%). These domains reflected six connected operational problems. The newer blueprint reorganizes their relative emphasis, expands some coverage, and incorporates newer cloud and AI-related security responsibilities. The older code therefore has value as a historical and technical reference, not as an interchangeable version of a live exam.

Reconstruct the threat-detection and response lifecycle

SCS-C02 assessed the ability to identify abnormal activity and respond without destroying useful evidence. A suspected compromised IAM identity, for example, might leave a trail of unusual API calls, unexpected access patterns, changes to resource policy, and suspicious data movement. No single service report proves compromise. An investigator needs to correlate actors, timestamps, resources, source addresses, permissions, and business context before deciding what happened and how broadly the event spread.

Detection is most useful when an alert has a known operating consequence. Amazon GuardDuty can identify certain suspicious behaviors, but a finding needs triage and validation before a responder concludes that data was stolen. An unexpected API call may be the result of a legitimate workload update; a low-severity finding may become significant when combined with a newly granted privilege. Analysts should establish the timeline, assess affected resources, verify whether the event is continuing, and document uncertainty rather than producing a definitive story too early.

Containment choices require judgment. Disabling an account, changing an IAM role, isolating a workload, or restricting network connectivity can stop an attack yet also interrupt essential services. A runbook should identify who can authorize disruptive actions, which evidence must be captured, and how to confirm that the mitigation worked. Security automation can speed repeated tasks, but it needs scopes and guardrails. An unbounded event rule that deletes every resource matching a broad pattern may cause more damage than the original incident.

The historical domain connects directly to incident response inside AWS accounts, but the current content should be studied from SCS-C03 rather than copied back into the older test as if it were identical. Its enduring lesson is the distinction between alert collection, incident verification, immediate containment, eradication, recovery, and post-incident improvement. Each step requires evidence and documented responsibilities.

Interpret security logs and monitoring evidence correctly

SCS-C02 gave security logging and monitoring a separate domain with substantial weight. CloudTrail management events and relevant data events can document API operations, while other network, application, and service logs provide different perspectives. A VPC Flow Logs record does not contain application payloads, and a successful API response is not evidence that a business transaction was legitimate. Professionals need to understand the provenance, coverage, retention, and limitations of each signal before relying on it during an investigation.

Centralized collection reduces blind spots when an organization operates many AWS accounts. A well-designed approach protects logs from unauthorized deletion, chooses appropriate retention, and makes timestamps and identity context useful for correlation. Separation of duties matters: a team responsible for changing production resources should not automatically have unrestricted access to disable the independent audit trail. Where encryption keys or storage policies prevent security personnel from reading records, the logging system may be technically active but operationally ineffective.

Missing evidence can be more informative than noisy evidence. If a company captures only regional management events from selected accounts, analysts should not confidently describe user-level object access across the entire organization. Investigations should record which event classes were enabled at the relevant time and whether a service was outside the collection scope. CloudTrail for security investigations is a useful subject because it teaches the limits of what a particular event source can establish.

Monitoring also has an economics and privacy dimension. Capturing every high-volume data event indefinitely may produce high costs and unnecessary retention of sensitive operational details. Insufficient collection can make incident reconstruction impossible. Select events using a documented risk model, test whether alerts are actionable, and periodically verify that critical activity actually appears where incident responders expect it. Alert tuning should improve signal without simply suppressing uncomfortable categories of events.

Harden infrastructure at the network and compute boundaries

Infrastructure Security accounted for 20% of the earlier examination. AWS shared responsibility means that managed physical infrastructure does not eliminate customer responsibility for network design, operating systems under customer control, identity policies, encryption settings, and application vulnerabilities. Security depends on the services and deployment model used. A container on a customer-managed host has different operational duties from a managed service endpoint with limited customer control over its runtime.

Security groups, network ACLs, route tables, VPC endpoints, DNS, and traffic-inspection patterns solve different problems. A security group can restrict permitted traffic at an elastic network interface, but it cannot repair an application that trusts malicious input. A route table determines where traffic is forwarded, while an endpoint policy can restrict some access to a connected AWS service. A private network path alone does not prove that the principal accessing the service is authorized to read every object or execute every API.

The old exam encouraged thinking about both internet exposure and internal movement. An internal workload with excessive permissions can become a route to sensitive data even when no public listener exists. Limit east-west access according to application need, isolate administrative services, and protect build or management systems that can modify many workloads. Where centralized inspection is used, understand which traffic classes actually traverse the inspection path; a misrouted subnet can create a gap that a diagram obscures.

Compute security includes patching responsibility, image provenance, runtime configuration, secrets access, and diagnostic telemetry. Automated fleet management helps maintain consistency, but it can distribute a bad configuration just as efficiently as a good one. Security reviews should test how changes are approved and rolled back. In container environments, restricting execution privileges and protecting image supply chains matter alongside network segmentation. Infrastructure security is a set of mutually reinforcing controls, not a single firewall configuration.

Reason through IAM decisions rather than memorize policies

Identity and Access Management represented 16% of SCS-C02 scored content and remains an essential AWS security skill. An effective decision must account for the principal, action, resource, conditions, and applicable policy layers. Identity-based policies and resource-based policies interact with permission boundaries, organization-level restrictions, and explicit denies. A statement that appears to allow an action may still be blocked by another applicable control, while a resource policy can introduce access that an engineer did not anticipate from an identity policy alone.

Consider a service that needs to read one set of S3 objects and send messages to one queue. The role should receive only those actions on the appropriate resources, subject to any necessary conditions. Broad * permissions create risk if the service's credentials are later misused. Long-lived static keys increase the burden of rotation and theft prevention. Temporary role credentials and short trust paths are generally more suitable for managed workloads, provided that trust policies and role-assumption permissions are correctly scoped.

Cross-account access makes seemingly simple examples harder. A role may be allowed to assume another role, but the target role's trust policy must also support the relationship. An organization SCP does not grant permissions; it constrains what principals in an affected account may do. A permission boundary similarly sets a limit, not an independent source of authority. IAM policy evaluation is valuable when troubleshooting apparent conflicts and avoiding accidental over-permissioning.

Authentication and authorization must be distinguished. Multi-factor authentication can strengthen a user's sign-in, yet it does not guarantee that their granted actions meet least privilege. Federation can streamline workforce identity, while still requiring responsible role mappings and session controls. Detection for unusual role assumption or privilege changes complements IAM architecture. A cloud environment can have valid authentication everywhere and still be insecure because access grants are too broad.

Protect information throughout storage, transfer, and recovery

SCS-C02 dedicated 18% of its score to data protection. Encryption at rest, encryption in transit, and key governance matter, but the engineer also needs to control who may use a key, who can change its policy, and which applications may decrypt data. AWS KMS key policies, grants, and related IAM permissions influence access to encrypted resources. A resource can be encrypted successfully yet unavailable to its legitimate recovery service because the necessary KMS permissions were omitted.

Data classification establishes the right controls for different information categories. A regulated record may require stricter access, limited retention, regional restrictions, audit trails, and deletion procedures. Those requirements must extend beyond the primary database to exports, snapshots, caches, logs, and test datasets. Copying a production table to a permissive analytics bucket can undermine otherwise sound encryption and identity controls. The data path should be traced from ingestion to use and eventual disposal.

Backups protect against some forms of corruption or accidental deletion, but a backup strategy is only as useful as a tested restore process. Assess recovery time, recovery point, authorization, key availability, and dependency order. Replication may transfer accidental deletion or malicious changes to another location, so isolation and immutable retention may be needed for certain threat models. S3 data protection and Object Lock are relevant because preventing an attacker from altering retained backups is different from making a normal storage copy.

Secrets require separate handling from general configuration. Credentials stored in repositories or application logs are difficult to secure merely by encrypting a volume. Use controlled retrieval, rotation where appropriate, and permissions limited to the application that needs the secret. Tests should confirm that a missing or revoked credential produces a safe failure instead of exposing the secret in error output. An operational support process must know who may rotate credentials without granting broad access to unrelated production systems.

Carry governance forward into the SCS-C03 examination

The old Management and Security Governance domain accounted for 14% of SCS-C02. It concerned account structures, organizational guardrails, auditing, and consistent application of security requirements. Multi-account AWS environments should separate duties, provide appropriate central logging and security visibility, and define how exceptions are requested and tracked. A compliance dashboard that shows green controls without demonstrating actual enforcement provides weaker assurance than repeatable tests and reliable evidence.

The updated SCS-C03 splits detection from incident response, revises the infrastructure and IAM emphasis, and names security foundations and governance more explicitly. AWS also added or recategorized newer topics, including contemporary AI/ML security concerns. The new six-domain weighting is Detection 16%, Incident Response 14%, Infrastructure Security 18%, Identity and Access Management 20%, Data Protection 18%, and Security Foundations and Governance 14%. The comparison confirms continuity in the security mission but not identical question distribution or exact content.

A practical way to use historical SCS-C02 material is to treat it as a case-study archive. Recreate one incident across several accounts: trace unauthorized access, evaluate policies, preserve evidence, isolate resources safely, check whether confidential objects were reached, and test recovery. Then map the scenario to the current SCS-C03 domains and add newer guardrails and threat types. That approach retains worthwhile technical learning while making the latest examination requirements the preparation authority.

Readers should be cautious of pages claiming that SCS-C02 can still be taken today. AWS's documented transition ended that exam version in December 2025. Existing holders can continue to represent their valid AWS Security – Specialty credential according to AWS's normal validity rules, and practitioners can use old study material to refresh foundational concepts. But registration, blueprint weights, service coverage, and final preparation must come from the current issuer sources. Historical accuracy is useful only when it is clear about what is and is not current.