AWS Certified Security – Specialty SCS-C02

SCS-C02 routinely asks "in this scenario, who is responsible — AWS or you?". The answer changes by service category. Get the line wrong and you propose security controls AWS already owns (waste) or skip controls AWS doesn't own (breach).

• Infrastructure services (EC2, EBS, VPC): AWS manages physical infrastructure + hypervisor. You manage the OS, applications, network configuration, data encryption, IAM. The "most responsibility on you" tier.
• Container services (ECS, EKS, Fargate): AWS additionally manages the orchestration plane. With Fargate, AWS also manages the host OS. ECS/EKS on EC2 = you still patch the worker nodes.
• Abstracted/managed services (S3, DynamoDB, Lambda, SQS): AWS manages the OS, runtime, and infrastructure. You manage IAM, data classification, encryption configuration, and how the data flows. The "least operational responsibility" tier.
• Always YOUR job, every service: IAM users/roles, data classification, encryption key custody choices (when CMK matters), application-level access controls, regulatory compliance for YOUR data.
• Always AWS's job, every service: physical datacentre security, hardware lifecycle, hypervisor patches, AWS-side network DDoS protection (basic).
• Compliance inheritance: AWS holds certifications (SOC 2, PCI DSS, ISO 27001, FedRAMP) that your workloads can INHERIT for the AWS-side controls. But you still need to demonstrate YOUR controls for application/data layers.

Scenario: data breach via SQL injection. Question: did AWS or the customer fail? Answer: the customer — application-layer access controls (input validation, parameterised queries) are always customer-owned across every service tier. Compare: data breach via hypervisor escape exploit. Answer: AWS would have failed — hypervisor security is theirs. The first happens often; the second has never been publicly documented.

Multi-account is the SCS-C02 baseline. AWS Organizations + an opinionated OU structure with dedicated security accounts is the topology Microsoft expects you to design around.

• Management account: houses the Organizations root. Don't deploy workloads here. SCPs DO NOT apply to it — so break-glass + billing only.
• Security tooling account: houses delegated-admin instances of GuardDuty / Inspector / Security Hub / Macie / Access Analyzer. All findings aggregate here.
• Log archive account: dedicated immutable bucket for CloudTrail org trail + Config aggregator. Object Lock in Compliance mode. Cross-account SCP prevents anyone from deleting logs — only the management account can disable Organizations features.
• Network account: Transit Gateway / VPC IPAM / Direct Connect / shared services VPC. Workloads attach via TGW; perimeter inspection happens here.
• Sandbox + workload OUs: sandbox has relaxed SCPs for experimentation; workload OUs split into Prod / NonProd / Test with progressively stricter guardrails.
• Delegated admin pattern: for security services, delegate admin from management account to security tooling account. Lets the security team operate without management-account credentials.

Reference org structure used in exam scenarios: Root → Security OU (security-tooling + log-archive accounts) → Infrastructure OU (network + shared-services) → Sandbox OU → Workload OU (Prod / NonProd sub-OUs). Delegate admin to security-tooling for: GuardDuty, Inspector, Security Hub, Macie, Access Analyzer, Detective. Log Archive bucket has Object Lock Compliance, retention 7 years. SCPs on Workload/Prod: deny S3 BPA changes, deny region-outside-list, deny disable-GuardDuty.

The Well-Architected Security Pillar's seven principles are AWS's worldview. SCS-C02 scenarios are graded against them — "which solution aligns with the security pillar" almost always means picking the principle-aligned answer.

• 1. Strong identity foundation: least privilege, attribute-based access (ABAC), centralised identity (IAM Identity Center), zero standing privileged access.
• 2. Enable traceability: log everything, retain for the appropriate compliance window, enable integrity validation (CloudTrail signed digests), expose metrics + alerts.
• 3. Apply security at all layers: defence-in-depth — perimeter (WAF / Shield), network (NSG / NACL / firewall), host (Inspector / Defender / AV), data (KMS / S3 encryption / TLS).
• 4. Automate security best practices: IaC for security configuration, Config rules for drift, EventBridge + Lambda for auto-remediation, never let humans hand-modify production.
• 5. Protect data in transit + at rest: default-on encryption (S3 SSE, EBS default, RDS TDE), enforce TLS at endpoints, CMK for key custody, VPC endpoints to avoid public internet.
• 6. Keep people away from data: automation does the work; humans review / approve. Session Manager + JIT for VM access. Federated identities for break-glass.
• 7. Prepare for security events: incident response runbooks, tabletop exercises, immutable forensic data (Object Lock CloudTrail + EBS snapshots), Detective + SOC playbooks.

Scenario: "Which approach to credential rotation aligns with the security pillar?" Wrong: scheduled human-driven password rotation. Right: Secrets Manager auto-rotation via Lambda. Reason: principle 4 (automate) + principle 6 (keep humans out of the data path) + principle 1 (least privilege — Lambda rotates with a scoped role).

GuardDuty finds anomalies; Detective lets you investigate them without running custom queries. They're designed to work together. SCS-C02 tests both the finding categories and the right tool for "given this alert, find blast radius".

• GuardDuty data sources: VPC Flow Logs, DNS logs, CloudTrail management + S3 data events, EKS audit logs, RDS login events, Lambda Runtime, Malware Protection scans. Enable per-source per-account.
• Finding categories: Reconnaissance, UnauthorizedAccess, Stealth (impossible travel), Trojan, CryptoCurrency, Discovery, Exfiltration, Impact, Policy. 300+ finding types under these umbrellas.
• Severity: Low / Medium / High. Tune to your environment — what's Medium for AWS might be Critical for your regulated workload. EventBridge rules can re-route based on severity + finding type.
• Trusted IP / Threat IP lists: custom IP lists in S3 — Trusted suppress findings; Threat increase. Use for known partner IPs (trusted) and known-bad IPs from threat intel (threat).
• Amazon Detective: automatically ingests GuardDuty + CloudTrail + VPC Flow Logs + EKS audit, builds entity behavior graphs. Click a GuardDuty finding → jump to the entity's full activity timeline.
• Cross-account aggregation: delegate GuardDuty + Detective admin to the security tooling account. Single pane across the org.

Alert: UnauthorizedAccess:EC2/MaliciousIPCaller.Custom with High severity on an EC2 instance. Investigation in Detective: select the EC2 → entity profile shows API calls in the last 1h (which roles assumed, which APIs called) + network activity (which IPs connected). Spot a lateral-movement attempt to another EC2. Workflow: isolate both instances (quarantine SG via Lambda automation), snapshot EBS for forensics, revoke roles via STS TokenIssueTime condition.

Detection without response is just a dashboard. SCS-C02 expects you to wire automated containment for the highest-severity findings — every minute of manual response is dwell time.

• EventBridge rules on GuardDuty findings: match by severity (≥ 7) and finding type. Targets: Lambda for custom logic, Step Functions for orchestrated runbooks, SNS for paging.
• EC2 quarantine pattern: Lambda receives the finding, modifies the instance's SG to a quarantine SG (deny all egress, allow forensic-tooling SSH), takes EBS snapshot, tags instance "compromised", notifies SOC.
• Compromised IAM credentials pattern: Lambda calls IAM UpdateAccessKey to disable the key, OR adds a Deny-all policy with aws:TokenIssueTime < now to invalidate all sessions issued before the response.
• S3 public-access remediation: Config rule s3-bucket-public-read-prohibited + SSM Automation document that re-enables Block Public Access on the offending bucket.
• SSM Automation runbooks: declarative multi-step workflows. AWS-provided: AWSSupport-RestrictIncomingTrafficOnPort, AWSSupport-MigrateXenToNitroLinux. Custom for your runbooks.
• Step Functions for complex workflows: when response has branching logic (e.g., "if instance is in prod-vpc, snapshot; else terminate"), Step Functions encodes the runbook visually.

Runbook: "compromised EC2 instance via GuardDuty Backdoor finding". EventBridge rule filter: { "source": ["aws.guardduty"], "detail-type": ["GuardDuty Finding"], "detail": { "severity": [{ "numeric": [">=", 7] }], "type": [{ "prefix": "Backdoor:" }] } }. Target: Step Functions state machine — (1) get EC2 instance ID from finding detail, (2) tag InvestigationStatus=Active, (3) snapshot all attached EBS, (4) replace SG with quarantine SG, (5) post message to Slack with details.

Three less-glamorous but exam-tested IR topics: Macie for sensitive-data discovery, EC2 forensic capture, and STS credential revocation for compromised keys.

• Amazon Macie: ML-driven PII / PHI / financial-data discovery in S3. Sample-based scan or full bucket scan. Findings include sensitive-data type + sensitivity score per bucket.
• Macie + S3 remediation: finding "S3 bucket contains credit card numbers AND is publicly readable" → EventBridge → Lambda removes public access, notifies data classifier.
• EC2 forensic capture: the canonical sequence — (1) take EBS snapshot of all attached volumes (preserves evidence), (2) attach snapshot copies to a forensic analysis VM in an isolated VPC, (3) capture memory dump via SSM if the instance is still running, (4) quarantine SG on the original.
• Snapshot encryption: if the source EBS is encrypted with a CMK, the snapshot is too — make sure your forensic analysis VM's role can decrypt with that CMK.
• STS credential revocation: aws:TokenIssueTime condition key in an IAM Deny policy invalidates all sessions issued before a timestamp. Pattern: when compromise detected, attach Deny policy to the role with "aws:TokenIssueTime": {"DateLessThan": "${now}"}.
• Access key rotation: if a key is leaked, generate new key, deploy to using systems, deactivate old key (don't delete — leaves audit trail), wait for usage to drop to zero, then delete.

Scenario: GitHub bot reports an IAM access key committed to a public repo. Response runbook: (1) immediately add a Deny-all policy to the user with aws:TokenIssueTime < now to invalidate any session minted from the key, (2) deactivate the key via IAM API, (3) audit CloudTrail for use of the key (Athena query on CloudTrail Lake), (4) rotate any secrets the key had access to, (5) post-mortem to find why the key existed in the first place — usually replace with managed identity / IAM Roles Anywhere.

CloudTrail is THE audit source-of-truth on AWS. SCS-C02 routinely contrasts management vs data events, asks about organization trails, and tests log-file integrity validation for forensic admissibility.

• Management events: free, default on (last 90 days in event history). Record CreateBucket, DeleteVolume, AssumeRole, etc. Cover control-plane operations.
• Data events: paid, opt-in per trail. S3 object reads/writes, Lambda invocations, DynamoDB operations. Required for "who read this S3 object" forensics.
• Insights events: ML-detected anomalies in API call rates. Free but separately enabled. Useful for "billing operations are 100× normal" alerts.
• Organization trail: single trail at management/delegated-admin scope that records every event in every member account. Members CAN'T disable. The exam-canonical multi-account audit pattern.
• Log file integrity validation: CloudTrail signs digest files hourly. aws cloudtrail validate-logs verifies the chain. Required for legal-admissibility / chain-of-custody.
• Delivery to S3 + Lock down the bucket: Object Lock Compliance mode on the bucket; bucket policy denies non-CloudTrail principals. SCP at organization level forbids any account from modifying the bucket. The triple-lock pattern.

A bank needs 7-year tamper-evident audit retention for compliance. Design: organization trail in the management account, delivering to a bucket in the log archive account. Bucket configured with Object Lock Compliance mode, retention 7 years. Log file integrity validation ON. Data events enabled for the customer-data S3 prefix. SCP on every member account: Deny "cloudtrail:StopLogging", Deny "cloudtrail:DeleteTrail". Validation runs quarterly to confirm no tampering.

Once events are stored, you need to query them. CloudTrail Lake (purpose-built, SQL) vs Athena over S3-delivered logs (DIY, cheap) are two valid approaches.

• CloudTrail Lake: AWS-managed event data store. SQL queries via the console / API. Up to 7-year retention. Organization event data store aggregates events from all member accounts automatically.
• Pricing model: Lake bills for INGEST (per GB of events stored) + per-query scanned data. Cheaper than Athena for ad-hoc forensic queries; pricier than S3 for long-term cold retention.
• Athena on CloudTrail S3: use Glue catalog table mapping the CloudTrail S3 prefix. Query in standard SQL. Cheaper for cold/archival; needs Glue setup; doesn't auto-aggregate across accounts.
• Common forensic queries: "who deleted EC2 instance X?" — find eventName='TerminateInstances' with that instance ID. "What did role Y do in the last 24h?" — filter by userIdentity.arn.
• CloudWatch Logs Insights on CloudTrail: deliver CloudTrail to a CloudWatch log group + use Logs Insights. Real-time queries but more expensive than Lake / Athena for large volumes.
• EventBridge from CloudTrail: for real-time alerting on specific events (root account login, IAM policy change), use CloudTrail → EventBridge rules. Don't poll the trail.

Investigation: "an admin role was used to disable GuardDuty across 3 accounts last Tuesday — who initiated it?" CloudTrail Lake query: SELECT userIdentity.arn, recipientAccountId, eventTime FROM organization_trail_lake WHERE eventName = 'DisableGuardDuty' AND eventTime BETWEEN '2026-05-10' AND '2026-05-13' ORDER BY eventTime. Returns the three events with the calling principal ARN, source IP, and exact timestamps. Cross-reference with the principal's access log in Identity Center for the human behind the role.

Three managed governance services that close the monitoring picture: Security Hub for aggregated posture, Audit Manager for compliance evidence, IAM Access Analyzer for over-share detection.

• Security Hub: aggregates findings from GuardDuty / Inspector / Macie / Config / 3rd-party. Runs standards: AWS Foundational Security Best Practices (FSBP), CIS, PCI DSS. Computes a Security Score (% of passing controls). Cross-account aggregation via delegated admin.
• Security Hub Custom Insights: saved filters that show findings matching a criteria. Pre-built insights cover common questions ("S3 buckets without encryption"). Custom Insights for your environment-specific patterns.
• Audit Manager: pre-built frameworks (HIPAA, PCI DSS, SOC 2, GDPR, FedRAMP) that auto-collect evidence as your environment runs. Maps each control to the AWS service findings that satisfy it. Export evidence packages for auditors.
• Audit Manager + custom frameworks: build internal control framework as a custom Audit Manager framework. Reuse the evidence-collection automation.
• IAM Access Analyzer: two flavours — external access finds resources (S3, KMS, Lambda, IAM roles) accessible from outside your trust zone (account / org). Unused access finds roles + permissions not used in N days.
• Access Analyzer policy generation: reads CloudTrail (last 90 days) for a principal + generates a least-privilege IAM policy from observed usage. Use to right-size over-broad policies.

A regulated org needs to demonstrate PCI DSS 4.0 compliance. Design: enable Security Hub at the security tooling account with delegated admin, enable PCI DSS standard. Audit Manager with the PCI DSS 4.0 framework — auto-collects evidence (config snapshots, CloudTrail events, IAM policies) mapped per control. Quarterly reviews export the evidence package for the assessor. Access Analyzer external access runs continuously; findings of cross-account S3 / KMS access auto-create Security Hub findings. Access Analyzer unused access flags zombie roles for cleanup.

AWS WAF inspects HTTP/HTTPS at L7. SCS-C02 tests rule type selection and the rule-evaluation order — the single biggest source of WAF misconfiguration in production.

• Web ACLs: attach to CloudFront, ALB, API Gateway, AppSync, App Runner, Cognito User Pool. One Web ACL per resource. Contains rules in priority order + a default action (allow/block).
• Managed rule groups: AWS-managed (Core Rule Set, Known Bad Inputs, IP Reputation, Bot Control, ATP), Marketplace (3rd-party), custom. Bot Control + ATP are extra-cost; Core Rule Set is free.
• Custom rules: rate-based (X requests / 5 min per source IP), regex pattern match, IP/CIDR match, geographic match, label match (output from earlier rules).
• Rule priority + evaluation order: rules evaluated in priority order (lowest number first). FIRST rule that returns allow/block wins. Allow rules MUST have lower priority numbers than block rules they should override.
• Rate-based rules: tracks rolling 5-minute window per source IP. Best as the LAST rule before the default action — wraps everything in a per-IP rate limit.
• WAF logs: deliver to Kinesis Firehose → S3 / Athena / OpenSearch. Cost-controlled by sampling — start at 100% during tuning, drop to 10% steady state.

A SaaS API needs: (1) block known-bad IPs, (2) allow a partner CIDR even if it'd match a managed rule, (3) rate-limit per source. Priority order in the Web ACL: P1 = Allow rule for partner CIDR (must beat the AWS managed rules below). P2 = AWS managed Core Rule Set + Known Bad Inputs (block OWASP attacks). P3 = AWS managed IP Reputation List (block known-bad IPs). P4 = Rate-based rule, 1000 req/5min per IP. Default action: Allow. If the partner allow rule had a higher priority number than the managed rules, partner requests would be incorrectly blocked.

DDoS protection (Shield), org-wide WAF policy enforcement (Firewall Manager), and stateful VPC perimeter inspection (Network Firewall) are the three additional infrastructure-security services SCS-C02 expects.

• Shield Standard: free, always on, protects every AWS-allocated public IP. Mitigates common volumetric + state-exhaustion attacks.
• Shield Advanced: ~$3000/month + per-organization. Adds cost protection (refund of scale-out costs during attack), DDoS Response Team (DRT) access, advanced metrics + dashboards, Global threat dashboard. Protects CloudFront + Route 53 + ALB + NLB + Elastic IP + Global Accelerator.
• Firewall Manager: centralised policy for WAF, Shield Advanced, Network Firewall, security groups, Route 53 Resolver DNS Firewall across all accounts in the org. Single delegated admin.
• AWS Network Firewall: stateful + stateless deep packet inspection at the VPC level. Suricata-compatible rules. Use for egress filtering (allow only known FQDNs), east-west traffic inspection.
• Gateway Load Balancer: transparent insertion of 3rd-party IDS/IPS / firewall appliances via the GENEVE protocol. Use when you need a specific 3rd-party tool (Palo Alto VM-Series, Check Point, etc.) in the traffic path.
• Route 53 Resolver DNS Firewall: filter outbound DNS queries from your VPCs against allow/deny lists. Block C2 callbacks at the DNS layer.

Org with 50 accounts, regulated workloads in 10 of them. Design: Firewall Manager at the security tooling account, delegated admin. Policies: (1) WAF Web ACL applied to all CloudFront distributions in regulated OUs (managed rule groups + rate-based). (2) Shield Advanced enrolment for all regulated OU accounts. (3) Network Firewall in the egress VPC of regulated OUs with Suricata rules denying outbound to known-bad domains. (4) Route 53 Resolver DNS Firewall blocking the threat-intel domain list. One configuration, applied across the org.

Keep traffic off the public internet. VPC endpoints, PrivateLink, and segmented VPCs are the SCS-C02-tested approaches.

• Gateway endpoints (S3, DynamoDB only): route-table entries that redirect subnet traffic to AWS service over the AWS backbone. Free. Add to route table; the prefix list resolves to S3/DDB endpoints.
• Interface endpoints (PrivateLink): ENI in your subnet with a private IP. Per-hour + per-GB cost. Used for all other AWS services (Secrets Manager, KMS, SSM, etc.) AND for 3rd-party / cross-account services.
• Endpoint policies: resource-based policy on the endpoint restricting which actions / which principals can use it. Restrict S3 endpoint to "only allow access to buckets in this org" — defeats data exfiltration via attacker-owned bucket.
• Service control on the consumer side: SCP aws:SourceVpce condition key forces a principal's API calls to come through a specific endpoint — combined with bucket policy aws:SourceVpc, prevents data egress to non-org buckets.
• VPC segmentation for PCI DSS: dedicated VPC for the in-scope cardholder-data environment, TGW with route-table separation from other VPCs, dedicated NACLs + SGs. Auditable boundary.
• Resource Access Manager (RAM): share subnets / TGWs / Route 53 Resolver rules with other accounts in the org. Avoids the "each account has its own everything" sprawl.

A regulated workload must never reach the public internet. Design: every needed AWS service exposed via VPC endpoint — Gateway endpoints for S3 + DynamoDB, Interface endpoints for KMS, Secrets Manager, SSM, STS, CloudWatch Logs, ECR. Endpoint policies restrict S3 endpoint to in-org bucket ARNs. Removed NAT Gateway entirely; subnets have no IGW route. SCP "aws:SourceVpce": "vpce-xxx" condition on bucket policies prevents access from outside the VPC.

The IAM policy evaluation flow is the most-tested concept on SCS-C02. Understanding which policy type wins at which stage decides every "did this request succeed" question.

• Evaluation order (simplified): SCPs → Resource-based policy → Identity-based policy → Permission boundary → Session policy. An explicit Deny at ANY stage wins. The request must be ALLOWED at every applicable stage.
• SCPs: applied at OU / account scope, evaluated FIRST. Even root and AdministratorAccess are bounded. SCPs are deny-lists in practice ("don't allow region X") rather than allow-lists ("only allow region Y" — risky, breaks on every new AWS service).
• Identity-based policy: attached to user / group / role. Standard IAM policy. Allow + Deny statements.
• Resource-based policy: attached to the resource (S3 bucket policy, KMS key policy, Lambda resource policy). Enables CROSS-ACCOUNT access without role chaining.
• Permission boundary: ceiling on what an IAM principal can do. Effective permissions = INTERSECTION of identity policy AND boundary. Used to safely delegate IAM-role creation (DevOps can create roles; boundary caps them).
• Session policy: attached at AssumeRole time. Can only further restrict — never expand — the role's identity policy. Used by federation + temporary session tightening.

Question: "User has AdministratorAccess. SCP on the account denies iam:DeleteRole. User attempts to delete a role. What happens?" Answer: Denied. SCPs evaluate before IAM; explicit Deny at the SCP wins regardless of identity policy. Question: "Role's identity policy allows s3:GetObject on any bucket. Permission boundary allows only buckets in account 123. Cross-account S3 bucket in account 456 has a resource policy allowing the role. What happens?" Answer: Denied. The boundary doesn't include account 456 buckets — intersection is empty.

Attribute-Based Access Control (ABAC) replaces "one role per project" with "tag-based access". Identity Center centralises workforce access. SCS-C02 favours both for any scenario at non-trivial scale.

• ABAC pattern: tag the user (or session) with Project=alpha; tag the resource with Project=alpha; IAM policy condition "aws:PrincipalTag/Project": "${aws:ResourceTag/Project}". One policy serves all projects.
• aws:PrincipalTag: a condition key matching tags on the calling principal (user / role / session). Tags can come from IAM, from IdC session, or from SAML attributes.
• Resource tag condition keys: aws:ResourceTag/<key> (general), ec2:ResourceTag/<key> (EC2-specific), etc. Available where the service supports them — check docs per service.
• IAM Identity Center: centralised workforce identity. Identity source: AWS-managed users, Active Directory (Managed AD or AD Connector), or external IdP via SAML/SCIM. Federates SSO to AWS accounts in the org.
• Permission sets: Identity Center's equivalent of IAM roles. Each permission set is replicated as an IAM role in each assigned account. Users sign in via Identity Center → choose account + permission set → get temporary creds.
• Eliminate long-lived IAM users: for human access, Identity Center is the SCS-C02-canonical answer. For machine-to-machine, managed identities (Lambda execution role, EC2 instance profile) or IAM Roles Anywhere for non-AWS workloads.

An org with 60 projects needs per-project access for engineers. Bad: create 60 IAM roles. Good: ABAC pattern. Identity Center user attribute Project set per engineer; permission set policy: { "Effect": "Allow", "Action": ["ec2:*", "s3:*"], "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}" } } }. One permission set covers all 60 projects. New project = tag resources with project name; new engineer = set their Project attribute. Zero policy edits.

Cross-account access mechanics, the most-useful condition keys, and Cognito basics for customer-facing identity.

• Cross-account roles: account A creates a role with a trust policy allowing account B's principal. B calls STS AssumeRole targeting that role; gets temporary creds. Account B's identity policy must also allow sts:AssumeRole. Both ends required.
• External ID: third-party use of AssumeRole — your customer creates a role for the SaaS provider; trust policy requires the customer's chosen sts:ExternalId. Defeats confused-deputy attacks.
• Condition keys you must know: aws:SourceIp, aws:SourceVpc, aws:SourceVpce, aws:RequestTag, aws:ResourceTag, aws:PrincipalTag, aws:MultiFactorAuthPresent, aws:MultiFactorAuthAge, aws:TokenIssueTime, aws:ViaAWSService (true when call is from a service, not a principal directly), aws:PrincipalOrgID.
• aws:ViaAWSService: useful for "allow this only when CloudFormation / a service is calling on the principal's behalf, not when the principal calls directly". Lambda accessing Secrets Manager via SDK has aws:CalledVia.
• Cognito User Pools: consumer identity. JWT trio (ID / Access / Refresh). AdminUserGlobalSignOut API revokes all of a user's refresh tokens — emergency-revoke pattern.
• Cognito Identity Pools: swap a JWT (Cognito User Pool, SAML, third-party OIDC) for temporary AWS creds via STS. Used for browser/mobile apps making direct AWS calls.

A SaaS provider needs to access customer AWS accounts to perform automated audits. Bad: hand them an IAM user with access keys. Good: cross-account role with external ID. Customer creates role auditor-role with trust policy: {"Principal": {"AWS": "arn:aws:iam::SAAS_ACCOUNT:root"}, "Condition": {"StringEquals": {"sts:ExternalId": "CUSTOMER_CHOSEN_GUID"}}}. SaaS code AssumeRoles with that external ID. Each customer picks their own external ID — even if the SaaS is compromised, the attacker can't pivot between customers without knowing each external ID.

KMS is the cryptographic substrate for every encrypted thing on AWS. SCS-C02 expects you to know envelope-encryption mechanics, the key-policy-first access model, and the role of grants.

• Envelope encryption: KMS doesn't encrypt large payloads directly. Call GenerateDataKey → returns plaintext data key + encrypted data key. Encrypt your large blob with the plaintext, discard the plaintext, store the encrypted blob + encrypted data key together.
• Key types: AWS-managed (free, AWS-controlled key policy), Customer-Managed (you control everything), AWS-owned (in AWS-internal accounts, free, no audit). CMK is the only one for compliance-mandated key custody.
• Key policy = primary: KMS does NOT fall back to IAM for permissions. The key policy must EITHER grant the principal directly OR include "Principal": {"AWS": "arn:aws:iam::123456789012:root"} + delegate to IAM. Best practice: the latter.
• Symmetric vs asymmetric: symmetric (default, AES-256, used by service integrations). Asymmetric (RSA, ECC, sign/verify or encrypt/decrypt). HMAC keys for MAC operations.
• Key rotation: automatic annual rotation for symmetric CMKs (free, transparent — old material kept to decrypt old data). Asymmetric / HMAC require manual rotation.
• Grants: short-lived programmatic permissions used by AWS services. EBS at volume creation creates grants to use the CMK. Visible in CloudTrail. Use list-grants to audit.
• Multi-region keys: replicate a CMK to another region with the same key ID + material — needed when DR pattern requires the secondary region's services to decrypt with the SAME key.

A 500 MB file needs encryption: call GenerateDataKey(KeyId='alias/myapp-data', KeySpec='AES_256') → returns plaintext 32-byte key + encrypted key. Use plaintext key with local AES-GCM to encrypt the file. Store the encrypted file alongside the encrypted data key. To decrypt: read encrypted data key, call Decrypt on it (with the same context), get plaintext, decrypt file locally. KMS never sees the 500 MB.

When you need stronger guarantees than KMS (CloudHSM), public certificates (ACM), or rotated secrets (Secrets Manager), AWS has purpose-built services. SCS-C02 tests when each is correct.

• CloudHSM: FIPS 140-2 Level 3 single-tenant HSM hardware. AWS has zero access to your keys (you own the keystore). Used for stringent compliance (FedRAMP High, FIPS workloads) or BYOK to KMS.
• CloudHSM-backed KMS keys: create a Custom Key Store in KMS backed by your CloudHSM cluster — get KMS API ergonomics + CloudHSM key custody. Best of both for compliance-mandated key custody.
• ACM (AWS Certificate Manager): free public TLS certs, auto-renewed. Issue certs for CloudFront, ALB, API Gateway. ACM-issued certs can NOT be exported (only used on AWS services).
• ACM Private CA: private CA + cert issuance for internal mTLS / service mesh. Cost: ~$400/month per CA. Use for in-VPC service-to-service TLS.
• Secrets Manager: $0.40/secret/month + API calls. Built-in automatic rotation for RDS / DocumentDB / Redshift / Redshift Serverless. Custom rotation via Lambda for anything else.
• Secrets Manager vs SSM Parameter Store SecureString: Parameter Store free up to 4 KB, no rotation. Use Parameter Store for static config secrets; Secrets Manager when rotation matters.

A regulated workload needs (1) FIPS 140-2 Level 3 key custody, (2) auto-rotated DB credentials, (3) internal mTLS between microservices. Design: CloudHSM cluster with KMS Custom Key Store backed by it for all CMK operations. Secrets Manager with native RDS rotation (30-day rotation, MultiUser strategy). ACM Private CA issuing short-lived certs (24h) to each microservice via the AWS SDK; certs renewed automatically by sidecar agent.

The data-protection topics that come up on every SCS-C02: S3 Object Lock for tamper-proof storage, EBS-encryption defaults, and data-residency / sovereignty enforcement.

• S3 Object Lock Compliance mode: once set, retention period CANNOT be shortened or removed — not even by the root account. The only AWS protection root can't bypass. Required for SEC 17a-4 / FINRA WORM compliance.
• S3 Object Lock Governance mode: same WORM behaviour but a role with the s3:BypassGovernanceRetention permission CAN override. Use when you need "almost-WORM" but want an emergency-bypass option.
• Legal hold: orthogonal to retention modes — adds another lock that prevents deletion until removed. Use for active litigation hold; not time-based.
• S3 bucket policy enforcement: bucket policy Deny PutObject without "s3:x-amz-server-side-encryption": "aws:kms" + KMS key ARN forces all uploads to use the specific CMK. Catches misconfigured clients.
• EBS encryption by default: account-level setting that auto-encrypts every new EBS volume with the default CMK. Config rule encrypted-volumes checks compliance; SSM Automation can re-encrypt non-compliant volumes via snapshot copy.
• Data residency: SCP Deny "*" Resource "*" Condition "StringNotEquals": "aws:RequestedRegion": ["eu-west-1", "eu-central-1"] blocks API calls outside approved regions. Some global services (IAM, Route 53, CloudFront) bypass this — exclude their actions via NotAction.

A financial firm must store trade records for 7 years tamper-proof. Design: S3 bucket with Object Lock Compliance mode, default retention 7 years, in eu-central-1. Bucket policy denies non-KMS uploads + denies non-bucket-owner access. SCP at the OU level: deny operations outside eu-* regions. KMS CMK in eu-central-1 with key policy granting only the trade-recording role. Quarterly audit verifies retention configuration via Config rules. CloudTrail records every Object Lock + KMS event in the log archive account.

Control Tower is the opinionated landing-zone deployment. SCS-C02 expects you to know the three guardrail types and when each fires.

• Preventive guardrails: SCPs that BLOCK actions before they happen. Examples: deny disable-CloudTrail, deny region outside list, deny IAM-user creation (force Identity Center). API call denied at request time.
• Detective guardrails: Config rules that DETECT non-compliance after the fact. Examples: encrypted-volumes, s3-bucket-public-read-prohibited, iam-password-policy. Findings into Security Hub.
• Proactive guardrails: CloudFormation Hooks that VALIDATE templates pre-deployment. Reject deploys that would create non-compliant resources. The newest guardrail type; catches issues before they exist.
• Mandatory vs strongly-recommended vs elective: mandatory always on, strongly-recommended toggleable, elective opt-in per OU. Production OUs typically enable all strongly-recommended.
• Account Factory: Control Tower's account vending. New account requests provision an account in the right OU with the guardrails inherited. Replaces manual Organizations account creation.
• Customizations for Control Tower (CfCT): deploy custom resources alongside the Control Tower baseline — your additional SCPs, custom Config rules, regional CloudFormation StackSets.

An org rolls out Control Tower. Mandatory guardrails apply to all OUs (CloudTrail enabled, IAM password policy). Strongly-recommended on Workload OUs: deny disable-Config, deny disable-GuardDuty, deny region outside us-east-1, eu-west-1. Proactive: CloudFormation Hook denies any S3 bucket creation without encryption. Custom SCP for the PCI OU: deny KMS key deletion. Account Factory provisions new accounts with the right OU + guardrail set automatically.

AWS Config is the detective backbone. Conformance packs bundle rules; aggregators give you org-wide visibility; SSM Automation closes the loop with auto-remediation.

• Managed vs custom Config rules: 200+ managed rules from AWS cover common controls. Custom rules in Lambda or Guard policy-as-code (CloudFormation Guard DSL).
• Conformance packs: YAML bundle of multiple Config rules + remediation actions. AWS publishes packs for HIPAA, PCI DSS, CIS, FedRAMP, etc. Deploy via StackSets to every account in the org.
• Aggregator: a Config aggregator in the security tooling account pulls compliance status from every member account. Single dashboard of "which resources are non-compliant with which rule across the org".
• Auto-remediation: Config rule + SSM Automation document. Non-compliance triggers the runbook (e.g., re-enable S3 BPA, encrypt unencrypted volume). Runs under a remediation role.
• Resource recorder: Config records configuration history of resources for change tracking. Must be enabled per region; cost scales with the number of resources + frequency of changes.
• Notification: Config → EventBridge → SNS / Lambda / Step Functions. Catch compliance state changes in real time for SecOps response.

An org needs continuous PCI DSS compliance monitoring. Setup: deploy the PCI DSS 4.0 conformance pack via StackSets to every account in the org. Config aggregator in security tooling account collects compliance data. For each non-compliant rule, an SSM Automation document attempts auto-remediation — e.g., a public S3 bucket gets BPA re-enabled. EventBridge rule on compliance state changes posts critical findings to PagerDuty. Quarterly evidence pack auto-generated for QSA review.

Service Catalog enforces approved infrastructure patterns; AWS Backup supports legal-hold for litigation; long-term audit-evidence retention is the final compliance pillar.

• Service Catalog: approved product portfolio that end users can self-service deploy. Products are CloudFormation templates. Constraints (launch role, template limits, tag) enforce policy. Replaces "free for all to deploy anything".
• Service Catalog launch constraint: the role used to deploy the product. Lets you grant users the ability to launch a product without giving them the underlying IAM permissions.
• AWS Backup legal holds: flag on a recovery point that prevents deletion until removed. Use for active litigation hold — retains backup beyond the configured policy retention.
• AWS Backup Vault Lock: WORM-style lock on a backup vault preventing deletion + retention shortening. Compliance mode is unbypassable; Governance mode allows IAM-permissioned override.
• Evidence retention for forensics: CloudTrail + Config + VPC Flow Logs delivered to S3 in the log-archive account, Object Lock Compliance mode, retention years. Triple-locked by SCPs at the org level.
• Subpoena response: the canonical pattern. Object Lock on CloudTrail + Backup vault lock + immutable Config snapshots = chain-of-custody-grade evidence. Audit Manager + CloudTrail Lake queries produce the discovery output.

A bank receives a subpoena for activity in account X between specific dates. Response: (1) AWS Backup apply legal hold on all recovery points in the date range to prevent expiration. (2) Backup Vault Lock already in Compliance mode — vault unbypassable. (3) CloudTrail Lake SQL query returns every event in the date range; export to S3 with Object Lock for the legal team. (4) Config snapshot history exported. (5) Chain-of-custody documented; Audit Manager evidence pack compiled. The legal hold removed only after court closure.