Use the SCS-C03 blueprint, not the retired domain map
AWS Certified Security – Specialty is a security-engineering examination, not a vocabulary test for AWS services. The current exam code is SCS-C03. AWS introduced it on 2 December 2025, replacing the SCS-C02 blueprint. A candidate preparing in October 2026 should not use SCS-C02 domain weights to allocate study time or assume that a service appearing in an old course represents the current task statement. The underlying engineering principles often remain useful; the examination map and the way tasks are grouped have changed.
The official SCS-C03 guide describes 65 questions and a 170-minute appointment, with 50 scored questions and 15 unscored questions that are not identified during the examination. It permits multiple-choice and multiple-response formats, including ordering and matching items. Confirm delivery, language, price, accommodations and any later revisions through AWS before scheduling. A correct answer is usually the option that satisfies the security objective and the operational constraints, not merely the service with the most security-related name.
The six current domains are Detection (16%), Incident Response (14%), Infrastructure Security (18%), Identity and Access Management (20%), Data Protection (18%), and Security Foundations and Governance (14%). Together they account for 100% of scored questions. There is no separate present-day “Logging and Monitoring” domain; those skills are assessed where they support detection, incident response and other tasks. A similarly worded SCS-C02 course can still teach a principle, but its domain percentages are not a valid SCS-C03 study plan.
Begin with the identity and resource boundary
Identity and Access Management carries the largest single domain weighting at 20%, but its real importance is that authorization errors cross almost every AWS service boundary. Distinguish identities, role sessions, trust policies, identity-based permissions, resource-based policies, session policies, permission boundaries and Organizations service control policies. An apparently correct allow statement may be constrained by a separate explicit deny. A trust relationship that permits a principal to assume a role is not the same as the permissions the resulting role session can exercise.
Build a deliberately small cross-account laboratory. In Account A, create an assumed-role workflow with narrow read permission to a test S3 object in Account B. Record the caller identity and the effective request. Test what happens when the resource policy permits access but an identity or organization-level restriction blocks it, and reverse the situation. Do not disable monitoring or widen permission until the test succeeds. The useful artifact is a short decision trace showing principal, action, resource, condition context, policy evaluation and outcome. Repeat with a role session whose source identity or tag conditions change.
Use IAM Access Analyzer, CloudTrail and policy simulation carefully. A simulation is a reasoning aid, not evidence that every service call, network path and organizational constraint will behave identically in production. Tests should be performed on authorized resources and kept separate from live customer data. Practical preparation means understanding why an access decision failed and identifying the narrowest fix that restores the intended operation.
Detection requires trustworthy signal and investigative context
For the 16% Detection domain, start with what evidence is being produced, where it is delivered and who can alter or delete it. CloudTrail management events, relevant data events, VPC Flow Logs, DNS query logs, application logs and AWS Config change records answer different questions. GuardDuty analyzes supported telemetry for suspicious activity; Security Hub can consolidate and prioritize findings. A finding alone is not a complete incident history, and an absence of findings is not proof of safety.
In a safe lab, create an alerting flow for an unauthorized API attempt and compare the resulting CloudTrail event with the IAM decision that produced it. Identify the event time, caller, source address, role session, requested API, affected resource and error. Trace whether events reach the intended retention and analysis destination, and whether investigators in a separate security account can still access the record after a workload account is compromised.
Write one detection hypothesis at a time: for example, an unexpected privilege change on a role used by a CI/CD pipeline. Decide which event types could prove the change, which benign activities could resemble it, and how the signal should route into review. These questions are more transferable than memorizing a list of every CloudWatch, GuardDuty or Security Hub screen.
Incident response is a constrained series of decisions
The 14% Incident Response domain tests containment, investigation, recovery and lessons learned under real-world constraints. Imagine that a production role has issued unusual S3 reads from an unfamiliar network. Before deleting identities, isolate the scope of the role, capture relevant CloudTrail and S3 evidence, identify active sessions or automation dependencies, and decide what would contain the abuse with the smallest acceptable operational interruption.
An explicit denial or changed role permission may stop a class of future actions but does not necessarily undo already completed reads. Rotating a key or changing a security group solves only the risks that control actually governs. Distinguish preserving an immutable evidence trail from cleaning a compromised resource, and document the order of the actions. If workload availability matters, plan an alternate identity or recovery process before revoking access that a business-critical service relies on.
Use an event-driven playbook for a hypothetical suspicious finding: validate the event, determine the account and affected principal, notify the correct owner, preserve evidence, apply bounded containment, verify the effect, restore safely and update preventive controls. In a simulation, measure time to identify scope, time to containment and whether the workflow could accidentally disrupt unrelated resources. A successful tabletop produces a tested decision record, not just a completed checklist.
Infrastructure security needs both packet paths and permission paths
Infrastructure Security accounts for 18% of scored content. Security groups, network ACLs, route tables, subnets, transit gateways, VPC endpoints, load balancers, inspection appliances, AWS Network Firewall and edge protections solve different problems. Security groups are stateful controls, while network ACLs evaluate traffic statelessly. A correct security-group allow rule does not repair an absent route or a DNS resolver returning the wrong destination.
Trace one application transaction from a private instance through name resolution, routing, inspection, endpoint selection and service authorization. VPC network controls beyond security groups become meaningful only when you can show whether the packet reaches its destination and whether the caller has IAM or resource-policy permission to perform the requested operation. For example, a reachable S3 endpoint does not mean an S3 GetObject call is authorized, and an allowed GetObject permission does not supply network connectivity by itself.
For internet-exposed workloads, distinguish protective measures against malicious HTTP requests and volumetric attacks from ordinary VPC isolation. Choose a control based on the attack and its insertion point. A web application firewall is not a substitute for a private subnet, and subnet isolation cannot inspect every application-layer exploit. Document where TLS is terminated and where traffic is inspected; encrypted application data may be invisible to a control at an unexpected point in the architecture.
Data protection spans keys, access and recovery
The 18% Data Protection domain requires a lifecycle view. For a regulated application, identify what is sensitive, where it is created, how it moves, what copies and logs contain, when it expires and how the organization can prove deletion or restore. Server-side encryption at rest is important but incomplete when policies allow the wrong principal to decrypt, download or copy the data.
Compare AWS KMS customer-managed keys with service-managed choices, key policies, grants, rotation controls and multi-account access boundaries. A principal may be allowed to call an S3 API but unable to decrypt data protected by a key it does not control. Conversely, possession of a decryption permission does not automatically bypass S3 object permissions. Build a small test matrix separating the S3 and KMS decisions so the source of denial is visible.
Distinguish replication and high availability from backups that can survive logical corruption or destructive permissions. Object versioning, retention controls, Backup Vault Lock and cross-account recovery can be appropriate, but each has configuration and operational implications. Test a restoration path with a known recovery-point objective and recovery-time objective. An untested backup is a plan, not evidence that an incident can be recovered from.
Governance makes security consistent across accounts
Security Foundations and Governance contributes 14% of the blueprint. Multi-account AWS architecture is a responsibility model: foundational account isolation, landing zones, organization-level guardrails, delegated security administration, logging aggregation and exception handling. Service control policies restrict the maximum permissions available to affected principals; they do not grant permissions and cannot replace appropriately scoped IAM and resource policies.
Design an example organization with production, development, logging and security-tooling accounts. Decide who owns identity federation, who may change organization guardrails, where incidents are investigated and how an emergency exception is reviewed afterward. A security control must be operational: a team should know who receives the alert, who can respond, how to prove that the response was authorized and how the evidence is retained.
Governance is not only a compliance label. A convincing architecture has measurable guardrails: unauthorized public exposure is rejected, critical logs are retained as designed, encryption keys have accountable owners, risky changes are reviewed and exceptions expire rather than becoming permanent bypasses. State the desired control outcome first and then select the technical mechanism that proves it.
Prepare by testing decisions across domains
Begin by reading the exact current AWS SCS-C03 content outline. For every task statement, identify the likely service mechanisms, common constraints and evidence that would support a correct answer. Allocate study time according to both domain coverage and personal weaknesses. IAM has a 20% weight; it should not cause the other five domains to be neglected. A candidate strong in IAM but repeatedly wrong about incident containment needs incident-response practice, not another pass through IAM definitions.
A useful four-stage study cycle is: explain a scenario, implement a safe lab, introduce an intentional failure and document the observable result. For example, investigate why an encrypted object is unreachable even after a network change. Check the route, endpoint, object policy, role/session constraints and KMS authorization separately. Change one variable at a time; record both successful and failed attempts. Repeat the same discipline when studying suspicious API calls or cross-account logging.
Use realistic practice questions only after the underlying mechanisms are clear. Read the final sentence first to identify whether the task is prevention, detection, least-privilege access, containment, resilience or cost-sensitive design. Eliminate options that address the wrong failure domain. Multiple-answer questions require each selected choice to be individually justified; two plausible services do not necessarily form a sufficient security architecture without the missing policy or network control.
Before booking, verify the current AWS exam code, official guide, test-language availability, registration path and candidate rules. Archived SCS-C02 articles and courses can still explain useful services, but their old domain percentages and service names must be treated as historical. The strongest exam preparation leaves the learner able to explain not only which service to choose but why the observable evidence proves that it solves the stated security problem.