AWS SCS-C03: Security Decisions Across the Cloud

At the start of an incident, an AWS security engineer sees an unusual API call, a new route from a workload account and a surge in requests to an internal service. None of those signals establishes that a breach occurred. Together, however, they demand a coherent investigation: which identity was involved, what resources it could reach, what changed, what data may have been exposed and which containment action would reduce harm without destroying useful evidence. AWS Certified Security – Specialty (SCS-C03) examines that kind of technical judgment across identity, infrastructure, detection, response, data and governance.

SCS-C03 has been the current AWS Security Specialty exam since December 2, 2025, replacing SCS-C02, whose final delivery date was December 1, 2025. It is intended for people responsible for protecting AWS solutions, not solely for analysts who review alerts. A professional may need to design network controls in the morning, evaluate cross-account permissions after lunch, and help restore a service securely during an incident. The exam asks how those choices operate together.

Six domains, one connected security problem

AWS lists Detection (16% of scored content), Incident Response (14%), Infrastructure Security (18%), Identity and Access Management (20%), Data Protection (18%), and Security Foundations and Governance (14%). The weights highlight the breadth of the role and IAM's particular importance. They do not suggest that candidates should study six independent service catalogs. Nearly every realistic scenario crosses domain boundaries.

The division of detection from incident response is intentional. A monitoring control can reveal an event, but it cannot alone decide its significance or contain the affected system. A strong response process needs useful evidence, authority to act and a plan for preserving service or recovering safely. Similarly, an encrypted resource can be exposed through inappropriate permissions, and a private subnet can contain a compromised workload with extensive outbound access.

Candidates using older references should distinguish this blueprint from the retired SCS-C02 version. AWS reorganized its earlier logging and response categories, increased IAM emphasis, and added or revised tasks, including security considerations for generative AI applications. An old practice set may still teach sound principles while missing current tested responsibilities.

Detection starts with the questions investigators will ask

A useful detection system must answer questions such as: Who made the change? Which asset was affected? What activity followed? Could the action be part of approved maintenance? AWS CloudTrail can help establish supported API events, AWS Config can show configuration history and compliance state, and CloudWatch logs and metrics can describe workload behavior. GuardDuty and Security Hub contribute security findings and broader operational views. VPC Flow Logs, DNS records and other network telemetry can help reconstruct reachability and traffic patterns.

These services are complementary, not interchangeable. A network-flow record may show communication between addresses without proving which business user authorized the action. An API event may show that a policy changed without proving that sensitive objects were later read. A GuardDuty finding is a hypothesis requiring investigation, not a complete verdict. Designing useful detection means choosing sources that can be correlated and preserving enough history to examine a sequence of events.

Consider a temporary administrator role used during a production recovery. The associated API calls might look unusual but be legitimate. If the approval ticket, session record and changes made by the role can be correlated, responders can distinguish the recovery action from suspicious activity more quickly. Conversely, a role assumed from an unexpected origin at an unusual time may warrant scrutiny even when individual API calls are permitted. Effective detection depends on context and ownership, not alarm volume alone.

More detail about the relationship between AWS threat detection, logging and response helps explain why actionable findings need a clear investigative purpose. Blindly retaining unlimited sensitive logs can also create exposure and high costs; retention and access policies must follow the information's value and classification.

Incident response must preserve evidence while containing risk

When suspicious behavior is confirmed or sufficiently likely, the security team needs a prepared sequence for triage, containment, investigation, eradication and recovery. In the cloud, those actions might involve changing IAM credentials, restricting a security group, isolating a workload, protecting a snapshot or blocking a malicious access path. The right action depends on the threat and the need to preserve evidence. Deleting a compromised resource immediately may remove evidence and delay understanding of what happened.

An incident plan should name decision owners and escalation paths across security, operations, application teams, legal and communications functions when relevant. A security engineer may be permitted to deny a role but not to shut down the entire payment service without business approval. Predefined containment options make trade-offs visible before responders face a stressful choice.

Imagine an EC2 workload whose temporary credentials are being misused. Revoking or restricting the relevant permissions might stop access to AWS services, but the instance may also need network containment and forensic preservation. A later recovery could require rebuilding from a trusted image, restoring data and validating that the original exposure has been closed. Every step needs an auditable reason and a way to confirm its result.

After restoration, identify why the control failed. Was the role overly permissive, logging incomplete, an external service vulnerable, or an alert assigned to the wrong team? A post-incident review that merely notes that the service was restarted does not correct the underlying risk. SCS-C03 preparation should include reconstructing the entire incident timeline rather than memorizing a single containment command.

Network security requires explicit flows and trust boundaries

The AWS network is a set of possible paths, not one safe perimeter. VPC route tables, security groups, network ACLs, VPC endpoints, gateways and inspection services control different parts of reachability. Security groups are stateful and apply to supported interfaces; network ACLs are stateless subnet-level filters. Understanding those differences matters when troubleshooting a failed connection or designing layered restrictions.

A shared-services design may include multiple VPCs and accounts connected through a transit gateway or other mechanisms. Centralized connectivity can simplify operations, but it may also widen the blast radius of a permissive route or shared security rule. Engineers should map required source-to-destination flows and define which communications must remain impossible. A route does not grant IAM authorization, and an IAM permission does not create a working network path.

At the application edge, security requirements may include AWS WAF policies, protection from volumetric attacks, TLS, load balancer behavior and restrictions on direct origin access. Inside the environment, private endpoints and appropriate outbound controls can reduce unnecessary internet exposure. The right arrangement depends on the workload's data sensitivity, available integration patterns and the ability to observe legitimate and malicious flows.

Meaningful network security across VPC boundaries requires more than calling a subnet or workload 'private.' Security decisions must consider ingress, east-west communication, egress and hybrid connections, including how an attacker might move after obtaining a valid workload identity.

IAM is an authorization system, not a collection of broad roles

Identities include human users, applications, services and temporary roles used across accounts. Authentication determines who or what is requesting access; authorization determines which actions that principal may take on particular resources under specific conditions. IAM policies, role trust policies, resource policies, permissions boundaries, service control policies and explicit Deny rules interact. When access fails, the engineer should trace the complete policy chain rather than adding a broad Allow statement in frustration.

For example, a Lambda function needs to decrypt an encrypted object in an S3 bucket owned by another account. The execution role's identity policy may allow the S3 read, but the bucket policy and relevant KMS authorization can still prevent the operation. Fixing the failure may require a precise change in a resource or key policy. Giving the function administrator access to its own account does not necessarily solve it and creates unnecessary exposure.

Role assumption requires its own reasoning. A trust relationship allows specified principals to assume a role; the permissions on the assumed role determine what that new session may do, subject to applicable limits. Cross-account administration, external IDs where appropriate, session conditions, federation and human access lifecycle controls reduce confusion over which identity actually acted. Privileged sessions should be monitored and designed to expire rather than becoming permanent exceptions.

Identity design without excess privilege also means choosing an access model that remains comprehensible as teams and accounts grow. Attribute-based approaches and managed policies can help when governed carefully; they are not automatic remedies for missing ownership or undocumented exceptions.

Data protection reaches beyond encryption settings

Security for sensitive data begins with knowing what information exists, where copies are created, who may use them and when they should be retained or deleted. Encryption at rest protects against certain storage-level exposures; encryption in transit protects supported network communications; neither establishes that the application calling the data is authorized to use it for the proposed purpose. Identity, network, data classification and audit controls therefore need to be designed together.

AWS KMS supports cryptographic key management, while AWS Secrets Manager addresses sensitive credential material. Their use cases are related but different. A company may rotate database passwords correctly yet leave an encryption key policy open to too many principals. It may encrypt backups but fail a disaster-recovery rehearsal because the recovery account cannot use the key. Operational testing and key lifecycle management belong in the security architecture.

Object storage and databases also create data-lifecycle questions. An S3 bucket can contain object versions, replication copies and retained backups; removing an exposed object from one path does not guarantee every copy is gone. Access logs, public access settings, resource policies, lifecycle rules and appropriate ownership controls reduce risk when they are evaluated as a system.

Effective AWS data protection must distinguish a cryptographically protected asset from a well-governed data lifecycle. Ownership of keys, access to decrypted data, retention and rotation all change the exposure a proposed control can prevent. Exam scenarios commonly become clearer once the candidate asks which exposure the proposed control can actually prevent.

Governance and new workloads extend the security boundary

Organizations with many AWS accounts need rules for guardrails, logging, approved services, resource deployment, security findings and incident ownership. AWS Organizations and related governance controls can support consistent policy across accounts, while CloudFormation and other provisioning tools can help express approved configurations. But a centrally deployed mistake can spread as readily as a centrally deployed best practice. Standards need testing, versioning, exceptions and meaningful review.

Modern cloud estates increasingly include generative AI applications with prompt inputs, retrieval stores and agent tools. An AI application can introduce sensitive data into model context or allow a tool to take actions under an overprivileged role. Network isolation alone will not solve a prompt-injection issue; a guardrail alone will not enforce business-level authorization. SCS-C03's updated scope makes it important to recognize these additional assets and action pathways as security surfaces.

Where a company develops such systems, AWS Generative AI Developer – Professional (AIP-C01) represents a different technical concentration on building and integrating GenAI products. SCS-C03 remains focused on assessing and implementing effective security controls, including those that need to protect the wider cloud environment. The credentials overlap in risk areas but are not substitutes for one another.

Governance is also about proof. Compliance dashboards should connect rules to actual obligations, account owners and remediation work. Detection findings must have reviewers; exceptions must have reasons and expiration or review dates; recovery procedures must be tested. A passing configuration check is useful evidence, not a guarantee that the operating system will remain safe under attack or error.

Prepare through connected scenarios, not isolated features

Start from the official SCS-C03 guide and test each domain with a concrete architecture. A production web application might span multiple accounts, use encrypted data, expose an API, send logs to a central security account and contain a tool-using GenAI component. Draw its trust boundaries and data flows. Then introduce one event at a time: a leaked role credential, unusual DNS requests, an accidental public policy, a failed cross-account restore or an injection attempt inside retrieved content.

For every scenario, ask four questions: What evidence establishes the problem? Which identity and resource controls apply? What is the smallest safe remediation? How will the team verify that the business service and security boundary have recovered? The answers reveal whether a proposed AWS service actually solves the stated problem or merely adds another dashboard.

Strong SCS-C03 preparation produces a habit of checking the full path from identity to resource, from signal to investigation and from encryption to recoverability. The examination rewards security engineering that still works when services, users and failure conditions interact—not just familiarity with individually secure AWS features.