SCS-C03 — AWS Certified Security – Specialty Exam Blueprint

How to Use This Exam Blueprint

Use this checklist as a practical study map for the AWS Certified Security – Specialty (SCS-C03) exam from AWS. It is designed to help you confirm whether you can apply AWS security concepts in realistic scenarios, not just recognize service names.

For each topic area:

1. Read the “ready means” column.
2. Check whether you can explain the decision path without notes.
3. Practice with scenarios where more than one AWS service looks plausible.
4. Revisit weak areas until you can justify the secure, least-privilege, operationally realistic choice.

This is an independent exam blueprint for SCS-C03 preparation. It does not claim affiliation with AWS and does not state official exam weights.

SCS-C03 readiness map

Identity and access management checklist

Core IAM readiness

You should be able to reason through access decisions across multiple policy types.

• Explain the difference between an IAM user, group, role, and federated identity.
• Choose IAM roles over long-term access keys for workloads whenever possible.
• Explain how STS temporary credentials are issued and used.
• Compare identity-based policies and resource-based policies.
• Identify when a trust policy is required and what it controls.
• Distinguish a role trust policy from a role permissions policy.
• Explain explicit deny precedence.
• Explain how permission boundaries limit maximum permissions.
• Explain how Organizations SCPs limit maximum permissions for accounts or organizational units.
• Explain why SCPs do not grant permissions by themselves.
• Use IAM policy conditions for source IP, VPC endpoint, principal ARN, organization ID, MFA, tags, or requested Region when appropriate.
• Recognize when session policies or session tags affect access.
• Identify when a resource policy is needed for cross-account access.
• Troubleshoot “access denied” using all relevant policy layers, not just the visible IAM policy.

Policy evaluation decision path

    flowchart TD
	    A[Request made to AWS service] --> B{Any explicit deny?}
	    B -->|Yes| Z[Deny]
	    B -->|No| C{Allowed by identity or resource policy?}
	    C -->|No| Z
	    C -->|Yes| D{Within permission boundary if present?}
	    D -->|No| Z
	    D -->|Yes| E{Allowed by SCP or account guardrail?}
	    E -->|No| Z
	    E -->|Yes| F{Service-specific conditions satisfied?}
	    F -->|No| Z
	    F -->|Yes| G[Allow]

IAM decision checks

IAM artifacts you should be able to read

You do not need to memorize every condition key, but you should be comfortable interpreting common policy structure.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RequireTLS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::example-bucket",
        "arn:aws:s3:::example-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Can you identify:

• The effect is an explicit deny.
• The policy applies to both the bucket and objects.
• The condition denies requests not using secure transport.
• The statement does not grant access; it only blocks a risky path.

Logging, detection, and monitoring checklist

Logging source readiness

Detection and monitoring tasks

• Choose CloudTrail when the question asks “who called which AWS API, from where, and when.”
• Distinguish CloudTrail management events from data events.
• Know when S3 object-level activity or Lambda invocation activity may require data event logging.
• Recognize that CloudTrail must be protected from tampering using restrictive access, encryption, validation, and ideally separate log archive patterns.
• Use CloudWatch metric filters and alarms for near-real-time alerting from logs.
• Use EventBridge rules to route findings or API events to automated response.
• Use GuardDuty for managed threat detection, not as a firewall.
• Use Inspector for vulnerability and exposure management, not for sensitive data classification.
• Use Macie for sensitive data discovery in S3.
• Use Security Hub to aggregate and prioritize findings across services and accounts.
• Use AWS Config for compliance with configuration rules and historical state review.
• Know when centralized logging should be cross-account to reduce risk from a compromised workload account.

“Can you investigate this?” prompts

Infrastructure and network security checklist

VPC and network controls

Network scenario checks

• Design private subnets that access AWS services without traversing the public internet when appropriate.
• Explain when to use an S3 bucket policy condition to require access through a specific VPC endpoint.
• Troubleshoot why a private workload cannot reach an AWS API: route table, DNS, endpoint policy, IAM policy, security group, NACL.
• Choose WAF for HTTP request filtering and Network Firewall for VPC traffic inspection.
• Choose Route 53 Resolver DNS Firewall for domain-based DNS filtering.
• Explain that security groups are stateful and network ACLs are stateless.
• Recognize that VPC Flow Logs show metadata, not packet payloads.
• Secure load balancer front ends using TLS policies, certificates, WAF association, security groups, and logging where relevant.
• Identify when hybrid connectivity requires coordinated controls across AWS and on-premises networks.
• Protect administrative access using Systems Manager Session Manager patterns instead of broad inbound SSH/RDP exposure when appropriate.

Compute and workload security

Data protection and cryptography checklist

KMS readiness

KMS is a frequent decision point because access depends on both identity permissions and key permissions.

• Explain the role of a KMS key policy.
• Recognize that IAM permission alone may not be enough if the key policy does not allow the access path.
• Distinguish AWS managed keys, customer managed keys, and service-managed encryption patterns conceptually.
• Know when to use customer managed keys for more control over policy, rotation settings, auditability, and separation of duties.
• Explain KMS grants and why services may use them for delegated cryptographic operations.
• Use aliases for operational reference, not as the security boundary.
• Understand encryption context as additional authenticated context used in cryptographic operations.
• Troubleshoot encrypted resource access failures involving the principal, resource policy, key policy, grants, and service integration.
• Know when CloudHSM is a better fit for dedicated HSM control requirements.
• Know when ACM is used for TLS certificates and where certificates are attached.

Data protection by service

Encryption troubleshooting prompts

Governance, compliance, and multi-account security checklist

Preventive, detective, and responsive controls

Multi-account readiness

• Explain why security teams often centralize logging in a dedicated account.
• Explain why workload accounts should not be able to alter central security logs.
• Use AWS Organizations and organizational units conceptually to apply guardrails.
• Know that SCPs limit maximum permissions but do not grant permissions.
• Use delegated administrator patterns conceptually for services such as Security Hub, GuardDuty, Config, Macie, Inspector, or Firewall Manager where appropriate.
• Understand how IAM Access Analyzer helps identify unintended external or cross-account access.
• Use AWS Config aggregators or organization-level views to assess compliance across accounts.
• Recognize when Control Tower concepts may be relevant to account governance and guardrails.
• Choose resource policies carefully for cross-account access to S3, KMS, Secrets Manager, SNS, SQS, Lambda, or other resources.
• Avoid solving every governance problem with IAM; use SCPs, Config, Security Hub, and service-specific controls where they fit better.

Incident response checklist

Response phases you should be able to apply

Incident scenario cues

Service selection quick checks

Configuration and artifact checks

IAM policy reading checklist

When reviewing a policy snippet, ask:

• What is the principal?
• Is this an identity policy, resource policy, trust policy, key policy, or SCP?
• Is the statement allow or deny?
• What actions are included?
• What resources are included?
• Are wildcards present, and are they justified?
• Which conditions must match?
• Are there organization, account, tag, MFA, source IP, VPC endpoint, or encryption-related conditions?
• Is another policy layer likely to override or restrict this one?

CloudTrail investigation fields

Be able to interpret common fields conceptually:

Example CloudWatch Logs Insights-style investigation pattern

Use concise queries to narrow events. Exact fields depend on log format and destination.

fields @timestamp, eventSource, eventName, userIdentity.type, sourceIPAddress, errorCode
| filter eventSource = "iam.amazonaws.com"
| sort @timestamp desc
| limit 50

Can you explain what this query is trying to find and what you would do next?

Common weak areas and traps

Final-week checklist

Knowledge review

• Rebuild your own one-page matrix of AWS security services and their primary purpose.
• Review IAM policy evaluation until you can troubleshoot access denied scenarios quickly.
• Review KMS access paths, especially cross-account and service-integrated encryption.
• Review CloudTrail, CloudWatch, Config, GuardDuty, Security Hub, Inspector, Macie, and Detective differences.
• Review VPC security groups, NACLs, endpoints, WAF, Shield, Network Firewall, DNS Firewall, and Firewall Manager.
• Review S3 security controls: Block Public Access, bucket policies, access points, object ownership, encryption, replication, and logging.
• Review incident response playbooks for compromised keys, public buckets, suspicious compute, and unauthorized policy changes.
• Review multi-account governance: Organizations, SCPs, delegated administration, central logging, and Config/Security Hub aggregation.

Scenario practice

For each missed practice question, write the reason in this format:

Exam-readiness self-test

You are close to ready when you can confidently answer “yes” to most of these:

• Can I explain an AWS access decision from request to final allow or deny?
• Can I choose the right AWS detection service from a short incident description?
• Can I troubleshoot encrypted access involving S3 and KMS?
• Can I design a secure cross-account access pattern?
• Can I protect CloudTrail logs from tampering?
• Can I decide between WAF, Shield, Network Firewall, DNS Firewall, and security groups?
• Can I explain how to isolate a compromised EC2 instance without losing evidence?
• Can I identify when a service needs a resource policy, key policy, or trust policy?
• Can I explain why a private VPC endpoint still needs IAM and endpoint policy controls?
• Can I map Security Hub, GuardDuty, Inspector, Macie, Config, and Detective to different operational needs?
• Can I reason through least privilege without relying on broad wildcards?
• Can I distinguish prevention, detection, response, and governance controls?

Practical next step

Use this checklist to drive a timed mixed-practice session for AWS Certified Security – Specialty (SCS-C03). After each question, do not only mark right or wrong: identify the AWS security objective, the controlling policy layer, the best-fit service, and the reason each close distractor fails. This is the fastest way to turn topic familiarity into exam-ready judgment.