SCS-C03 is the current AWS Security Specialty target

The source article discussed AWS Security Specialty through identity and data protection, but the current exam is AWS SCS-C03. AWS published the SCS-C03 guide in March 2026. The exam includes six scored domains: Detection, Incident Response, Infrastructure Security, Identity and Access Management, Data Protection, and Security Foundations and Governance. Identity and Access Management represents 20% of scored content, while Data Protection represents 18%.

ExamSnap’s SCS-C03 preparation roadmap provides the broader exam context. This article focuses on two domains that are tightly connected in real systems: who can access a resource, under what conditions, and how the data remains protected before, during, and after that access.

Authentication answers who or what is making the request

Authentication in AWS involves human identities, workloads, federated users, roles, temporary credentials, and external identity providers. Candidates need to reason about IAM Identity Center, federation, role assumption, service identities, and the use of temporary credentials instead of long-lived access keys. The exam is not satisfied by knowing that a service exists; it asks whether the chosen pattern fits the trust boundary and operational model.

A strong lab compares human access and workload access. Configure a federated human path, then a service role for an application. Inspect the credentials actually issued, their duration, the trust policy, and where authentication failures appear. This teaches the difference between proving identity and granting authorization after identity has been established.

Authorization is where least privilege becomes concrete

Authorization combines identity policies, resource policies, permissions boundaries, service control policies, session policies, condition keys, and sometimes network or service-specific controls. Candidates should be able to trace an access decision through those layers and identify whether a deny is explicit, inherited, conditional, or the result of a missing allow.

The best preparation method is policy reasoning. Start with a specific request: principal, action, resource, context. Then evaluate which policy types apply. Change one condition at a time and observe the result. ExamSnap’s SCS-C03 objectives article is useful for mapping that reasoning to the current domain structure.

Cross-account access tests whether you understand trust in both directions

Multi-account AWS environments require candidates to distinguish identity permission from resource or role trust. A role may trust a principal while the principal still lacks permission to assume it. A resource policy may grant access while an organization-level service control policy restricts the action. External IDs, source identity, and conditions can further narrow delegated access.

Build a two-account lab and make the trust explicit. Document which account owns the principal, which owns the resource, which policy grants the action, and which policy could deny it. This turns cross-account access from a collection of IAM facts into a repeatable reasoning model.

Data protection begins with classification and ownership

Encryption is not the first question. The first question is what data exists, how sensitive it is, where it moves, who owns it, and what regulatory or business rules apply. Once the data flow is clear, candidates can choose encryption, access, logging, retention, backup, and monitoring controls that match the risk.

Practice mapping a workload from ingestion through processing, storage, replication, backup, and deletion. Identify where plaintext could exist, which service owns encryption, which identities can decrypt, and how evidence of access is recorded. Data protection is strongest when it is designed across the full lifecycle rather than attached only to the storage service.

KMS design is about control boundaries as much as cryptography

AWS Key Management Service is central to many exam scenarios. Candidates need to understand key policies, grants, IAM interaction, multi-Region keys, rotation, service integration, and the difference between AWS-owned, AWS-managed, and customer-managed keys. The decision often concerns governance and separation of duties rather than the encryption algorithm itself.

A useful exercise is to create a customer-managed key for an application, then separate administrators from users who can encrypt or decrypt. Test what happens when the IAM policy permits an action but the key policy does not, and vice versa. This exposes the dual control model that appears repeatedly in AWS security design.

Secrets, certificates, and data-in-transit controls complete the access story

Secrets Manager, Systems Manager Parameter Store, ACM, TLS, private connectivity, and service-specific encryption options all protect information that is not simply sitting in a database. Credentials should be rotated and retrieved through controlled identities. Certificates need lifecycle management. Network paths should minimize unnecessary exposure and use encryption where the threat model requires it.

The exam often combines these choices. A workload may need a secret, a KMS key, a private endpoint, and a role with narrowly scoped permissions. Treat the scenario as one trust chain: identity authenticates, policy authorizes, the network permits the path, encryption protects the data, and logging provides evidence.

Prepare by tracing access decisions end to end

SCS-C03 includes multiple-choice, multiple-response, ordering, and matching questions. The best preparation is therefore structured reasoning rather than memorizing service descriptions. For each scenario, identify principal, resource, action, policy layers, data sensitivity, encryption owner, logging evidence, and failure mode. Then choose the smallest architecture that satisfies the requirement.

Identity and data protection are high-weight domains because they touch almost every secure AWS design. Candidates who can trace a request from authentication through authorization to protected data—and explain where the decision would fail—are far better prepared than candidates who only recognize IAM and KMS terminology.

Logging closes the loop between IAM and data protection. CloudTrail, service logs, access logs, KMS events, and detective services help answer who attempted an action, what resource was affected, whether a key was used, and which control blocked or permitted the request. A secure design that cannot reconstruct sensitive access is difficult to investigate and difficult to prove compliant. Candidates should therefore connect preventive controls with the evidence they produce.

Design scenarios should also include recovery from credential or key compromise. Ask how access is revoked, how sessions and temporary credentials behave, how affected keys or secrets are rotated, what dependent services break, and how the organization proves that the new state is safe. This transforms IAM and encryption from static configuration topics into incident-response decisions. It also reinforces why SCS-C03 separates domains for identity, data protection, detection, and incident response even though real incidents cross all four.

Multi-account boundaries and policy testing

Service control policies and multi-account governance are especially important in SCS-C03 because security at scale is different from securing one account. An SCP does not grant permission; it defines the maximum available permission inside an AWS Organization. Candidates should practice scenarios where an identity policy allows an action but an SCP denies it, and where central account structure is used to enforce logging, security services, or deployment guardrails consistently.

Data protection also includes backup and recovery. Encryption protects confidentiality, but resilience requires protected copies, appropriate retention, access controls on backups, and confidence that data can be restored. A ransomware-resilient design may use separate accounts, immutability features, tightly controlled recovery roles, and tested restoration procedures. Exam questions can combine data protection with incident response because a protected backup is only valuable when the organization can recover it without reintroducing the compromise.

Macie and data-discovery capabilities add another layer. Sensitive-data discovery helps organizations identify where regulated or confidential information exists so that access and encryption decisions can be prioritized. Candidates should understand the difference between discovering sensitive data, preventing access, encrypting it, and monitoring its use. No single AWS service performs all of those functions.

For exam review, create an access-and-data matrix. Across several services—S3, KMS, Secrets Manager, RDS, DynamoDB, and workloads—record the resource owner, authentication path, authorization controls, encryption mechanism, logging source, backup method, and compromise response. This exposes gaps quickly and mirrors the cross-service reasoning expected at Specialty level.

Combining IAM and data controls in AWS scenarios

S3 scenarios are a useful place to combine identity and data-protection reasoning. A candidate should separate identity-based policies from bucket policies, understand how Block Public Access changes the effective exposure of a bucket, and recognize that encryption does not repair an over-permissive authorization model. The useful question is not “which feature secures S3?” but which principal needs which action on which resource, through which policy path, under which organizational constraints. Logging and access-analysis evidence should then show whether the intended boundary is actually holding.

Permission boundaries and AWS Organizations service control policies add another layer. A permissions boundary limits the maximum permissions an identity-based policy can grant to an IAM principal, while an SCP limits the permissions available within member accounts of an organization; neither is simply an extra allow policy. Exam scenarios become easier when you calculate the effective permission set instead of reading one policy in isolation. IAM Access Analyzer, CloudTrail, and policy simulation can provide evidence for troubleshooting unexpected access or validating a least-privilege design.

KMS questions should be approached the same way. Separate who can administer a key, who can use it for cryptographic operations, which service is calling KMS, and what resource policy or grant participates in the decision. Rotation, deletion controls, multi-Region design, and separation of duties are governance choices as much as encryption settings. During an incident, teams also need to know how to contain compromised credentials without destroying the evidence required to understand what was accessed and whether encrypted data was exposed.

Finally, prepare recovery scenarios rather than only prevention scenarios. Assume an access key is leaked, a role trust policy is changed, a bucket becomes exposed, or a KMS permission is abused. Work through detection, containment, credential replacement, policy correction, log review, impact analysis, and follow-up hardening. SCS-C03 rewards the ability to connect security services into an operating response, so practice should end with a defensible recovery path rather than a list of isolated AWS controls.