The SCS-C03 exam is the current AWS Certified Security – Specialty version and has been in use since December 2, 2025. AWS published the current exam guide version on March 26, 2026. It targets professionals responsible for securing cloud solutions and expects deeper operational security judgment than a general architecture or foundational credential.
AWS describes a target candidate with roughly three to five years of experience securing cloud solutions. The exam includes 50 scored questions plus 15 unscored questions, uses a scaled score from 100 to 1,000, and requires 750 to pass. More important than the mechanics, however, is the blueprint’s emphasis on designing, implementing, troubleshooting, and operating security controls across AWS accounts and workloads.
The six domains form a security operating model
SCS-C03 is divided into Detection (16%), Incident Response (14%), Infrastructure Security (18%), Identity and Access Management (20%), Data Protection (18%), and Security Foundations and Governance (14%). The weighting makes identity the single largest domain, but the exam is deliberately balanced. No one service family can carry the score.
The domains also depend on one another. Detection produces findings and logs. Incident response turns evidence into containment and recovery. Infrastructure security reduces exposure. IAM controls who and what can act. Data protection secures information and keys. Governance standardizes those controls across accounts.
Detection is about building useful security telemetry
The detection domain requires candidates to design monitoring and alerting for individual accounts and organizations, configure logging, aggregate events, and troubleshoot missing or incorrect security telemetry. Services such as GuardDuty, Security Hub, Security Lake, CloudWatch, CloudTrail, Macie, AWS Config, Athena, OpenSearch, and Lambda can all appear in that workflow.
A practical example is Amazon GuardDuty, which can contribute managed threat findings. That does not eliminate the need for CloudTrail, VPC Flow Logs, Route 53 Resolver logs, application logs, or centralized analysis. The exam can test whether the candidate chooses the correct source and aggregation method for the security question.
Incident response begins before an incident
The incident-response domain includes designing and testing response plans, pre-provisioning access, minimizing blast radius, deploying security tools, validating response plans, automating remediation, preserving forensic artifacts, correlating evidence, containing affected resources, restoring from backups, and performing root-cause analysis.
This is important because “respond to the finding” is not the entire discipline. A mature AWS incident-response design prepares identities, accounts, logging, snapshots, isolation controls, and automation before the event. The AWS Backup relationship matters when recovery is part of the containment and restoration plan.
Infrastructure security covers the paths into and through workloads
The infrastructure domain covers network edge controls, compute security, and network security architecture. Candidates should expect to reason about security groups, network ACLs, AWS Network Firewall, WAF-style protections, load balancers, VPC endpoints, private connectivity, segmentation, secure remote access, and the security posture of compute services.
Understanding AWS security groups is useful because they illustrate stateful instance-level filtering, but SCS-C03 goes beyond a single control. A scenario may ask where to enforce a policy, how to centralize firewall management, or how to reduce exposure while preserving application connectivity.
Identity and access management has the largest weight for a reason
The IAM domain requires candidates to design, implement, and troubleshoot authentication and authorization strategies. That can include IAM users and roles, identity federation, IAM Identity Center, resource policies, permission boundaries, service control policies, cross-account access, temporary credentials, least privilege, and the difference between identity-based and resource-based authorization.
A solid foundation in AWS Identity and Access Management helps, but Specialty-level questions usually add organizational scale, federation, service-to-service access, or policy interactions. The correct answer often depends on effective permissions rather than one policy document in isolation.
Data protection means encryption, integrity, secrets, and lifecycle
The data-protection domain covers encryption in transit, private access, encryption at rest, integrity controls, lifecycle and retention, backup, secrets, credentials, imported key material, external key stores, data masking, certificates, and regional or multi-Region key strategies.
AWS KMS is central to many scenarios, but the blueprint expects candidates to know when CloudHSM, customer-managed keys, imported material, or different encryption models are more appropriate. Secrets have their own lifecycle as well; Secrets Manager and Parameter Store should not be treated as identical stores with different names.
Governance scales security across accounts
The final domain covers AWS Organizations, Control Tower, SCPs, resource control policies, AI service opt-out policies, delegated administration, root-user protections, infrastructure as code, tagging, Firewall Manager, cross-account resource sharing, AWS Config, Security Hub, Audit Manager, Artifact, and Well-Architected security evaluation.
This is where the AWS shared responsibility model becomes operational. AWS secures the underlying cloud infrastructure, but customers still need repeatable governance for identities, resources, data, and configuration across their environment.
SCS-C03 is broader than the older exam version
AWS’s own comparison shows that SCS-C02 ended on December 1, 2025 and SCS-C03 began on December 2. Candidates should therefore be cautious with older preparation material. The domain structure changed, the weightings changed, and SCS-C03 adds or expands modern governance, automation, security-data, and organizational controls.
Older resources about preparing for the AWS Security Specialty can still help with durable concepts, but every objective should be checked against the current guide. That is especially important for services that have evolved or become central to organization-wide security operations.
The exam rewards trade-off reasoning, not service recall
AWS explicitly states that candidates should make decisions that account for cost, security, and deployment complexity. That means two technically secure answers can still differ in operational fit. The exam can ask for the most scalable logging design, the least-privilege access method, the most appropriate encryption model, or the response strategy that minimizes blast radius without creating unnecessary overhead.
Approach SCS-C03 as a security architecture-and-operations exam inside the broader AWS certification ecosystem. Service knowledge matters, but the decisive skill is understanding how controls work together and selecting the design that satisfies the stated requirement with the fewest unmanaged gaps.
SCS-C03 also expects candidates to understand the difference between preventive, detective, responsive, and governance controls. An SCP can prevent classes of actions at an organizational boundary. A security group can restrict traffic before it reaches a workload. GuardDuty can detect suspicious behavior after signals are observed. A response automation can contain a resource. AWS Config can continuously evaluate whether a resource remains compliant. Scenario questions often become easier when you first classify what kind of control the requirement actually needs.
The exam’s in-scope service list should be treated as a vocabulary boundary, not a checklist to memorize. Services such as Organizations, Control Tower, IAM Identity Center, KMS, CloudHSM, Secrets Manager, Certificate Manager, CloudTrail, CloudWatch, Security Hub, GuardDuty, Macie, Config, WAF, Shield, Network Firewall, Systems Manager, Backup, and S3 appear because they implement recurring security patterns. The important preparation task is to know which security problem each service solves, which identities and logs it depends on, and how it behaves across accounts and Regions.
Multi-account security is especially important in the new version. A centralized security team may need delegated administration for GuardDuty or Security Hub, organization-wide CloudTrail, standardized controls from Control Tower, SCPs that establish non-negotiable limits, and a separate log archive or security account. Each component solves a different problem. Delegated administration helps operate a service centrally; an SCP limits permissions; a log archive protects evidence; a Control Tower control helps standardize posture. Combining those concepts is closer to the level expected on SCS-C03 than memorizing one product screen.
Another recurring theme is troubleshooting. The current guide explicitly includes troubleshooting logging and monitoring, network security controls, compute security controls, authentication, and authorization. Candidates should practice asking what evidence distinguishes a policy problem from a network problem, a missing log from a missing detector, and a KMS authorization failure from ordinary resource access. That diagnostic reasoning is one of the clearest differences between Specialty-level preparation and entry-level cloud security study.
Preparation should also include regional and organizational failure modes. A security service that works in one Region may need separate enablement elsewhere, and a delegated administrator may require explicit organization configuration before it can see member-account findings. Likewise, centralized logs need carefully designed bucket, key, and organization permissions. These details matter because Specialty questions often ask why a control that is conceptually correct still fails at scale.
Finally, remember that AWS lists some tasks as explicitly out of scope: designing cryptographic algorithms, packet-level traffic analysis, overall cloud architecture, end-user compute management, and training machine-learning models. Those exclusions help define the expected depth. SCS-C03 wants security engineers who can apply AWS controls and troubleshoot their behavior—not cryptographers or network-forensics specialists working below the service layer.
A final readiness check is whether you can explain the security purpose of a control without naming the AWS service first. If you can describe the requirement as “centralize evidence,” “limit effective permissions,” “protect key material,” or “contain a compromised workload,” you are less likely to be distracted by a service that is familiar but operates at the wrong boundary.
That boundary-first thinking is especially valuable when AWS introduces new features, because the underlying security problem remains recognizable even when the implementation options evolve.