AWS Security Specialty SCS-C03 Guide (2026)

AWS Certified Security - Specialty (SCS-C03) validates the ability to secure AWS products and services. The official guide expects more than naming security tools. Candidates must apply data classifications and protection mechanisms, implement encryption, use secure internet protocols, operate AWS security features, understand security risks, and choose among security, cost, and deployment-complexity trade-offs.

The target candidate has the equivalent of three to five years securing cloud solutions. Recommended knowledge spans the shared responsibility model, identity at scale, multi-account governance, software supply-chain risk, incident prevention and response, vulnerability management, firewall rules from Layers 3 through 7, root-cause analysis, audits, logging, encryption, and disaster-recovery controls. That is why SCS-C03 questions often present an architecture with several controls that are individually useful but only one combination satisfies ownership, evidence, blast radius, recovery, and operational constraints.

The exam guide lists multiple-choice, multiple-response, ordering, and matching response types. It says 50 questions affect the score and 15 are unscored. Results use a compensatory model on a 100–1,000 scale with 750 as the minimum passing score. Do not turn those facts into a memorization strategy. Domain feedback is broad, and a candidate must reason across boundaries: a KMS denial can involve an IAM role, key policy, grant, SCP, encryption context, key state, and Region at once.

The PrepKloud five-phase SCS-C03 roadmap sequences the current objectives, while the questions, flashcards, and projects use original scenarios and synthetic data. This guide explains the technical priorities and the reasoning habits needed to connect them.

Official SCS-C03 domains and weights

Identity and Access Management is the largest domain, but the exam remains balanced. Identity controls determine who can change logging, isolate compute, use keys, read data, remediate Config findings, or administer an organization. Likewise, Detection produces the evidence consumed in Incident Response; governance deploys the controls practiced in Infrastructure Security and Data Protection. Study percentages should guide time, not create isolated service silos.

What changed from SCS-C02

The official comparison shows a structural reset. SCS-C02's Threat Detection and Incident Response domain and Security Logging and Monitoring domain became the separate SCS-C03 Detection and Incident Response domains. Infrastructure Security changed from 20% to 18%. Identity and Access Management changed from 16% to 20%. Data Protection remains 18%. The final domain remains 14% but is renamed from Management and Security Governance to Security Foundations and Governance.

AWS also identifies additions worth deliberate practice. Incident Response now calls out validating security-service findings to assess scope and impact. Infrastructure Security adds edge and third-party integrations, including OCSF ingestion and third-party WAF rules, plus protections and guardrails for generative AI applications. Data Protection adds inter-resource encryption in transit, differences between imported and AWS-generated key material, masking sensitive data, and managing keys and certificates in one or multiple Regions.

Some older details were removed or recategorized. That does not mean foundational networking, TLS, host hardening, or log interpretation is irrelevant to real security work. It means the current exam guide should determine preparation emphasis. Avoid using a retired weight table, calling Domain 2 “Logging and Monitoring,” or describing the current Domain 6 under its old name.

Domain 1: Detection — build reliable evidence

Detection contains three official tasks: design monitoring and alerting for an account or organization, design logging, and troubleshoot monitoring, logging, and alerting. Start by mapping telemetry to questions. CloudTrail management events answer who changed control-plane resources. Selected data events can answer who accessed an S3 object or invoked a Lambda function. VPC Flow Logs describe network-flow metadata and accept or reject results. Route 53 Resolver query logs capture DNS queries. AWS Config records supported resource configuration and evaluates rules. None of these sources is a universal forensic record.

An organization trail delivered to a dedicated log-archive account is a central pattern, but details decide whether it is trustworthy. Bucket and KMS policies must allow delivery without granting workload administrators mutation rights. Event selectors must include the events required by the threat model. Retention and lifecycle must satisfy evidence and cost needs. Log-file validation can support integrity checks. EventBridge can alert on stop-logging, trail deletion, or policy changes. If GetObject is missing while CreateBucket appears, inspect S3 data-event selectors before rebuilding the logging system.

GuardDuty, Security Hub, Security Lake, Macie, and Detective have distinct roles. GuardDuty analyzes supported data sources and emits threat findings. Security Hub aggregates findings and security-control results from supported sources. Security Lake centralizes supported security data in Open Cybersecurity Schema Framework format for governed analysis. Macie inventories S3 security posture and discovers sensitive data. Detective helps analysts investigate relationships and behavior. A mature answer combines services only when the scenario needs their different outcomes.

Coverage matters as much as configuration. A central dashboard can look healthy while a new account, Region, protection plan, trail selector, Config recorder, or log subscription is absent. Track enabled, suspended, unsupported, excluded, and not-evaluated states. Test account creation and Region expansion. Detection is not complete until missing signals themselves become visible.

Domain 2: Incident Response — prepare, validate, contain, recover

The response domain has two tasks: design and test a plan, then respond to security events. Preparation includes runbooks, roles, evidence destinations, communication, service access, tools, quotas, and blast-radius decisions. Cross-account responder roles and evidence KMS permissions should be created and tested before an incident. Break-glass access should be separate, strongly authenticated, time-bound where possible, monitored, and rehearsed.

SCS-C03's finding-validation addition is important. A GuardDuty severity is not proof that every resource is compromised. Review affected identity and resource, API, source, network context, time, behavior, and related findings. Correlate CloudTrail and applicable logs. Use Detective to explore supported entities and relationships. Decide whether the event is true positive, false positive, expected but risky, or incomplete. Then determine scope and impact.

Containment should be fast but evidence-aware. For a disposable EC2 instance communicating with a command-and-control address, a tested isolation security group can reduce external communication while preserving responder access. Capture required volatile evidence and snapshots according to the runbook. Revoking a compromised role session, changing a resource policy, or blocking an indicator may also be necessary. Automation through EventBridge, Lambda, Systems Manager, or Step Functions should be scoped, idempotent, reversible, observable, and approval-aware.

Termination is not recovery. Eradicate malicious persistence, vulnerable configuration, exposed secrets, and compromised sessions. Recover from a trusted image or backup and confirm that the backup predates the compromise and remains usable. Monitor the recovered system, compare configuration with the baseline, preserve the incident timeline, and update controls through lessons learned.

Domain 3: edge, compute, and network controls

Infrastructure Security covers the network edge, compute workloads, and network controls. AWS WAF examines supported HTTP requests. Managed rule groups accelerate common coverage, but deploy them in Count first, inspect labels and logs, tune exclusions narrowly, and then enforce. Rate-based rules can slow abusive clients. CloudFront can keep the origin behind an edge control. Shield Standard is automatic; Shield Advanced adds features for organizations that require enhanced detection, visibility, cost protection conditions, and response capabilities for eligible critical resources.

AWS Network Firewall is a routed network control, not a WAF substitute. It uses stateless and stateful rule groups and can log flow and alert activity. Its endpoints inspect only traffic routed through them. In centralized architectures, verify the transit gateway, appliance mode where applicable, same-Availability-Zone endpoint selection, forward and return paths, NAT order, and bypass routes. A healthy endpoint with the wrong route table inspects nothing.

Security groups are stateful interface controls with allow rules. Network ACLs are stateless subnet controls with ordered allow and deny rules. Private subnets do not automatically mean private service traffic: NAT can still send traffic to public endpoints. Use gateway or interface VPC endpoints and resource policies when private AWS-service access is required. Verified Access can provide identity- and context-aware access to supported applications without making network location the only trust signal.

Compute security includes hardened AMIs and container images, patching, Inspector vulnerability findings, GuardDuty runtime coverage where supported, least-privilege instance/service/execution roles, and administrative access through Systems Manager Session Manager. Pipeline checks should catch unsafe images, templates, dependencies, and permissions before deployment. SCS-C03 also adds generative AI guardrails: treat prompts and model output as untrusted, constrain tool schemas and permissions, isolate data, validate input/output, monitor decisions safely, and test prompt injection and excessive agency.

Domain 4: identity and access management

The 20% IAM domain has authentication and authorization tasks. IAM Identity Center is the standard workforce starting point for centralized account access: connect an identity source, assign groups to accounts and applications, define permission sets, apply MFA policy, and issue temporary sessions. Avoid long-term workforce access keys and shared IAM users. Amazon Cognito serves application-user identity patterns, while AWS STS supplies temporary role credentials. IAM Roles Anywhere supports authorized workloads outside AWS that use certificate-based identity.

Cross-account role trust requires both sides. The trusting account defines who may call AssumeRole, conditions, and the role's permissions. The caller needs sts:AssumeRole. For third-party platforms serving many customers, require a unique external ID to mitigate confused-deputy risk. It is a condition value, not a secret or a substitute for trusting the correct vendor principal.

Authorization is an evaluation problem. Identity and resource policies can contribute allows. Permissions boundaries, session policies, SCPs, and RCPs set different maximums or intersections. Explicit deny wins. KMS adds key policies and grants. A permission-set policy allowing kms:Decrypt is insufficient if the key policy does not authorize cross-account use or an SCP denies the action. CloudTrail, IAM Policy Simulator, Access Analyzer, and encoded authorization messages where supported help identify the failed layer.

ABAC can scale project or environment access by comparing trusted principal/session attributes with resource and request tags. The hard part is trust. Control who can pass session tags, tag new resources, and change protected tags. Confirm that each service and action supports the condition keys used. If a developer can relabel a production resource as their own project, the ABAC design has created escalation.

Domain 5: data in transit, at rest, and cryptographic lifecycle

Data Protection covers transit, at-rest controls, integrity, retention, backup, secrets, credentials, sensitive data, keys, and certificates. TLS at a public load balancer protects one connection. SCS-C03 explicitly expects inter-resource encryption such as service-specific inter-node settings for EMR, EKS, SageMaker AI, or Nitro paths. Verify every hop, certificate trust, security policy, client compatibility, and performance. Private connectivity does not eliminate the need for encryption when the requirement calls for it.

For data at rest, compare service-managed encryption, KMS customer managed keys, client-side envelope encryption, CloudHSM, and external key stores from requirements. KMS integrates broadly and records key API activity in CloudTrail. Key policies, IAM permissions, grants, encryption context, aliases, rotation, deletion windows, and Region are common troubleshooting areas. CloudHSM gives dedicated HSM control but requires more customer operations and application integration.

Imported KMS key material adds customer control over origin and can be configured to expire or be deleted. That also adds availability responsibility. If imported material is unavailable, KMS cannot decrypt ciphertext until the same material is reimported when supported. AWS does not save a plaintext recovery copy for the customer or replace the material silently. AWS-generated material follows KMS-managed creation and lifecycle instead. Multi-Region keys can simplify compatible multi-Region encryption designs, but replicas are related key resources with their own policies, grants, aliases, and operational state.

Secrets Manager supports managed storage and rotation workflows for supported secrets. Rotation code, database overlap, application caching, and failure rollback must be tested. Certificate Manager and AWS Private CA address public and private certificate patterns. CloudWatch Logs data protection policies can audit and mask matching values, and SNS message data protection can enforce supported message-data policies. These controls reduce exposure but do not replace source minimization.

Integrity and resilience require more than encryption. S3 versioning preserves versions. Object Lock governance mode can be bypassed by specifically authorized principals; compliance mode prevents protected versions from deletion or overwrite during retention, including by root. Backup copies must have separated access and tested restores. A retained backup encrypted under a deleted KMS key is not recoverable. Design data retention, key retention, replication, and cleanup together.

Domain 6: security foundations and governance

Organizations is the governance foundation. Separate management, security-tooling, log-archive, infrastructure, and workload responsibilities according to scale and risk. Register delegated administrators for supported services so routine GuardDuty, Security Hub, Macie, Config, or Firewall Manager work does not require daily use of the management account. Protect root access, centralize member-account root access where appropriate and supported, require MFA, and document break-glass procedures.

SCPs limit the maximum permissions available to principals in member accounts. They do not grant access. RCPs limit what supported resource policies can grant to protected resources. Tag policies standardize tagging; AI services opt-out policies control supported service data-use preferences; declarative policies can enforce supported service settings. Each policy family has a different purpose. Test policies in a canary OU, preserve service-linked and response paths, and document global-service and Region exceptions.

Secure deployment uses CloudFormation StackSets to distribute approved baselines across accounts and Regions. CloudFormation Guard and linting can reject templates that violate policy before deployment. Firewall Manager centrally deploys supported WAF, Shield Advanced, security group, DNS Firewall, and Network Firewall policies. Service Catalog and Resource Access Manager support governed product and resource sharing instead of unmanaged duplication.

AWS Config records supported resource configurations and evaluates rules. Organization rules, conformance packs, and aggregators support multi-account views. Systems Manager remediation can correct selected violations, but permissions, concurrency, exceptions, destructive impact, and rollback require control. Audit Manager organizes assessment evidence; Artifact provides AWS compliance reports and agreements. Neither replaces customer responsibility or proves every resource is compliant by itself.

Two portfolio projects for the current blueprint

The first SCS-C03 project builds a multi-account detection and incident response environment. Use a security account and log archive, organization CloudTrail, GuardDuty, Security Hub, Detective, Config, EventBridge, Systems Manager, KMS, and S3 retention. Generate GuardDuty sample findings and benign API changes only. Validate scope, isolate a tagged disposable instance, preserve synthetic evidence, recover from a trusted template, measure response time, and remove every service in dependency order.

The second project builds a governed zero-trust and data-protection platform. Apply canary SCPs and evaluate RCPs. Federate synthetic users through IAM Identity Center and test trusted ABAC attributes. Protect a small public app with CloudFront and WAF. Protect a private administrative app through Verified Access or an equivalent identity-aware pattern. Route selected traffic through Network Firewall, enforce KMS and private data access, scan known synthetic identifiers with Macie, and evaluate resources with Config and Security Hub.

Both projects require seven or more implementation phases, validation, cost accounting, and cleanup. They prohibit real secrets, customer data, malware, unauthorized scans, or testing outside owned lab endpoints. This is good portfolio discipline: show architectural reasoning and auditable results without turning a learning environment into a security incident.

A ten-to-fourteen-week study plan

1. Weeks 1–2: map all domain tasks, create an organization logging design, compare CloudTrail event classes, and centralize GuardDuty/Security Hub sample findings.
2. Weeks 3–4: write and test an incident runbook with response roles, finding validation, reversible EC2 isolation, synthetic evidence, Detective analysis, and trusted recovery.
3. Weeks 5–7: deploy WAF in Count then Block, route safe lab traffic through Network Firewall, test security groups/NACLs/endpoints, patch a managed node, and analyze Inspector findings.
4. Weeks 8–9: configure IAM Identity Center permission sets, cross-account trust, external IDs, boundaries, session policies, and trusted ABAC; diagnose deliberate authorization failures.
5. Weeks 10–11: implement KMS key policies and grants, envelope encryption, service TLS/internal encryption, Secrets Manager rotation, Object Lock, backup restore, Macie, and masking.
6. Weeks 12–13: stage SCPs/RCPs, StackSets, CloudFormation Guard, Firewall Manager concepts, Config rules/remediation, Audit Manager, and Artifact evidence.
7. Week 14: finish both projects, perform deletion rehearsals, take timed original questions, explain every distractor, and recheck the official guide.

Use the 25 original SCS-C03 questions to diagnose reasoning. Their answer arrays are zero-based for the PrepKloud engine; that implementation detail has nothing to do with AWS scoring. Use the 25 flashcards for active recall. For every error, open the official reference and state which requirement made the chosen option inferior.

Preparation mistakes to avoid

• Using SCS-C02 weights. The active blueprint has Detection 16%, Incident Response 14%, Infrastructure 18%, IAM 20%, Data Protection 18%, and Foundations/Governance 14%.
• Treating a finding as a verdict. Validate actor, behavior, resource, time, network, scope, impact, and related evidence.
• Calling a dashboard centralized security. Measure actual account, Region, log-source, protection-plan, and control coverage.
• Automating destruction. Prefer reversible containment and approval for ambiguous or destructive response.
• Ignoring routes around Network Firewall. Inspect forward and return routing, Availability Zones, transit mode, NAT order, and bypasses.
• Assuming private means encrypted. Enforce TLS and service-specific internal encryption when required.
• Saying SCPs grant access. SCPs and RCPs set maximums; applicable permissions must still allow the request.
• Trusting arbitrary ABAC tags. Protect session attributes, tag-on-create, and tag mutation.
• Forgetting KMS key policies. IAM allows alone may not authorize key use, especially cross-account.
• Deleting a key before backups. Inventory every ciphertext and restore dependency before scheduling deletion.
• Deploying WAF managed rules directly to Block. Count, observe, tune, then enforce.
• Leaving labs running. Firewall endpoints, NAT, Config, Detective, Macie, data events, logs, and retained storage can accrue cost rapidly.

Official AWS references

• AWS Certified Security - Specialty certification page
• AWS Certified Security - Specialty SCS-C03 exam guide
• Official SCS-C02 and SCS-C03 comparison
• Content Domain 1: Detection
• Content Domain 2: Incident Response
• Content Domain 3: Infrastructure Security
• Content Domain 4: Identity and Access Management
• Content Domain 5: Data Protection
• Content Domain 6: Security Foundations and Governance
• Create an organization trail
• Security Hub central configuration
• AWS Security Incident Response Guide
• AWS WAF Developer Guide
• AWS Network Firewall architecture models
• AWS IAM attribute-based access control
• Importing key material into AWS KMS
• AWS Organizations resource control policies

Continue across PrepKloud

• SCS-C03 five-phase roadmap
• SCS-C03 original practice questions
• SCS-C03 flashcards
• SCS-C03 synthetic portfolio projects
• Cloud security jobs board
• Technology career paths
• All certification roadmaps
• All PrepKloud guides
• PrepKloud editorial policy

Frequently asked questions