SCS-C03 cheat sheet

Detection

Designing Security Monitoring and Alerting Across an AWS Organization

• Security Hub with a delegated administrator and cross-Region aggregation is the single pane of glass for findings across accounts and Regions, all normalized into ASFF.
• GuardDuty consumes CloudTrail, VPC Flow Log, and DNS telemetry directly from AWS infrastructure — you don't enable those logs for it, and disabling them doesn't blind it.
• GuardDuty auto-enable through the delegated administrator is how new accounts are protected from the moment they join the organization.
• Security Lake normalizes security data into OCSF as Parquet on S3 for analytics, SIEM integration, and retention — it stores and normalizes but never alerts; Security Hub triages.
• Route findings by severity with EventBridge rules in the aggregation Region: page on High/Critical, queue the rest.
• CloudWatch anomaly detection alarms on learned baselines catch drift that static thresholds miss; metric filters turn log patterns into alarmable metrics.
• Scheduled assessment maps by layer: Config conformance packs for resource configuration, Security Hub standards (FSBP/CIS) for account posture, State Manager for in-instance state.
• GuardDuty finds threats, Inspector finds vulnerabilities, Macie finds sensitive data, Detective investigates — distractors come from the wrong row of that table.

Designing Security Logging Solutions: CloudTrail, Flow Logs, Central Archives

• An organization trail from the management account logs every member automatically, and member accounts cannot modify, stop, or delete it — the answer to tamper-resistant org-wide logging.
• Management events record the control plane and are on by default; data events (S3 objects, Lambda invokes) are high-volume, off by default, and should be scoped with event selectors.
• CloudTrail log file integrity validation — hourly SHA-256 digest files, signed and chained — is how you prove logs were not modified or deleted.
• VPC Flow Logs capture metadata only, never payloads; custom-format fields like pkt-srcaddr and tcp-flags are what make them useful behind NAT and against scans.
• Centralize into a dedicated log archive account: service-delivery bucket policies with source conditions, SSE-KMS (key policy must grant the logging service GenerateDataKey and readers Decrypt), versioning, deny-delete, and Object Lock compliance mode for WORM.
• S3 is the durable, Athena-queryable archive; CloudWatch Logs is the operational store with metric filters and Logs Insights; subscription filters into Kinesis or Firehose are the SIEM bridge.
• Security Lake is the managed alternative to a hand-built pipeline: org-wide collection normalized to OCSF Parquet, consumed by SIEMs through subscribers.
• Set lifecycle transitions and explicit retention everywhere — CloudWatch Logs groups default to never expiring.

Troubleshooting Security Monitoring, Logging, and Alerting on AWS

• Triage every broken pipeline in order — source, delivery, destination permissions, consumer — because downstream stages fail silently with no error anywhere.
• A trail that reports it is logging can still deliver nothing: check LatestDeliveryError, then the S3 bucket policy and KMS key policy for cloudtrail.amazonaws.com — an aws:SourceArn condition with a wrong value severs delivery invisibly.
• CloudTrail records management events by default; S3 object-level and Lambda invoke data events only exist if event selectors enabled them — check selectors before suspecting tampering.
• GuardDuty is enabled per Region per account; suppression rules auto-archive findings, trusted IP lists stop them being generated, and each protection plan gates its own finding types.
• GuardDuty and Security Hub events emit in the finding's Region — an EventBridge rule in another Region matches nothing, and patterns are exact about types, casing, and values.
• A KMS-encrypted SNS topic needs a customer managed key whose policy grants the publishing service kms:GenerateDataKey* and kms:Decrypt; the aws/sns managed key cannot grant this, so alarms publish into a void.
• Metric filters are case-sensitive and never retroactive; alarms fail on wrong statistic, period, or missing-data treatment; subscriptions deliver nothing until confirmed.
• Stale compliance data means a stopped Config recorder or a broken delivery channel before it means anything else.

Incident Response

Design and Test an AWS Incident Response Plan (SCS-C03)

• Preparation is the heavily tested phase: pre-provisioned IR roles, break-glass procedures, cross-account access, and a dedicated forensics account must exist before any incident.
• Deactivate an exposed access key first — it is immediate, reversible, and preserves the investigation trail; deletion is a later eradication step.
• Temporary credentials cannot be deactivated: revoke a compromised role's sessions with an inline deny conditioned on aws:TokenIssueTime (the AWSRevokeOlderSessions pattern).
• Register alternate security contacts — AWS reaches you through Health events and Trust & Safety notifications, and those signals must route to responders.
• Write runbooks as Systems Manager Automation documents orchestrated by Step Functions, with approval gates before high-impact actions; the Automated Forensics Orchestrator for Amazon EC2 automates evidence acquisition.
• Test the plan with tabletop exercises, GuardDuty sample findings, and Fault Injection Service game days — and end every test with playbook updates.
• Analysis capability is a preparation decision: CloudTrail data events, Detective, and Security Hub only help if they were enabled before the incident.

Responding to AWS Security Events: Compromised EC2, Credentials, and S3

• Order of operations is everything: validate the finding, isolate, preserve evidence (snapshots, memory), and only then eradicate and rebuild from a clean AMI.
• Security-group changes do not cut established tracked connections — use network ACL denies to sever an attacker's live session; the empty isolation security group remains the per-instance containment standard.
• Detach a compromised instance from its Auto Scaling group and load balancer before anything else — the ASG can terminate it (destroying evidence) regardless of termination protection.
• Snapshot EBS volumes before any change, and capture memory before any shutdown — stopping an instance destroys RAM and instance-store evidence.
• Deactivate exposed access keys; temporary credentials can only be killed with a deny policy conditioned on aws:TokenIssueTime — then hunt CloudTrail for persistence (new users, keys, roles, policy changes).
• For S3 exposure, Block Public Access is the containment switch; knowing what was read depends on CloudTrail data events or server access logs having been enabled beforehand.
• Share snapshots to the forensics account with a customer managed KMS key — snapshots encrypted with the default aws/ebs key cannot be shared.
• Automate containment with GuardDuty findings → EventBridge → Lambda or SSM runbooks, with Security Hub custom actions as the analyst-triggered path.

Infrastructure Security

Edge Security on AWS: WAF, Shield, and CloudFront as Controls

• Web ACLs attach to CloudFront (global scope, created in us-east-1), ALBs, API Gateway REST stages, and AppSync — never to EC2 or NLBs; wrong scope or no association is why "WAF isn't working."
• Rules run in priority order and the first terminating Allow or Block ends evaluation; Count is non-terminating and is the safe deployment mode for new rules and managed groups.
• Rate-based rules answer "block over X requests per window" — aggregate on the forwarded IP behind a proxy, and use scope-down statements to count only the traffic that matters.
• False-positive triage = WAF logs → terminatingRuleId → override that single rule to count or add a targeted exception, never delete the whole managed group.
• Shield Standard is free, automatic L3/4 protection; Shield Advanced adds cost protection, health-based detection, SRT access with proactive engagement, and L7 auto-mitigation via an associated WAF web ACL.
• Origin cloaking for an ALB needs both layers: the CloudFront origin-facing managed prefix list in the security group and a secret custom header verified by a listener rule — the prefix list alone still admits other customers' distributions.
• Use OAC with an AWS:SourceArn bucket-policy condition for S3 origins; signed URLs cover one object, signed cookies cover many.
• WAF is L7 at the edge; Network Firewall is stateful L3–L7 inside the VPC with Suricata rules and domain egress filtering — defense in depth uses both.

Securing Compute Workloads: EC2, Containers, and Lambda

• IMDSv2 defeats SSRF credential theft by requiring a token from a custom-header PUT; enforce it with HttpTokens=required, AMI ImdsSupport v2.0, account-level metadata defaults, and the ec2:MetadataHttpTokens IAM condition — and raise the hop limit to 2 only for containers on EC2.
• Golden AMIs come from EC2 Image Builder pipelines with hardening (STIG) and test components; running fleets stay compliant via Patch Manager baselines, patch groups, and maintenance windows, with EBS encryption on by default.
• Amazon Inspector is continual: SSM-based EC2 scanning, ECR enhanced scanning on push and again when new CVEs publish, and Lambda dependency plus code scanning — findings flow to Security Hub and EventBridge for automated remediation.
• Prioritize by the Inspector score, which adjusts CVSS for context like network reachability and exploit availability.
• ECR hardening = enhanced scanning, immutable tags (no silent overwrite of prod tags), least-privilege repository policies for cross-account pulls, and KMS encryption.
• Execution role acts at task startup (pull image, write logs, inject secrets); task role serves the running application's API calls — startup failures implicate the execution role, runtime AccessDenied implicates the task role.
• On EKS, grant AWS access per pod with IRSA or EKS Pod Identity, never by inflating the node instance role; enable control-plane audit logs and prefer a private API endpoint.
• Lambda's execution role decides what the function can do; its resource-based policy decides who can invoke it — scope service grants with aws:SourceArn and aws:SourceAccount to kill the confused deputy.

Network Security Controls: SGs, NACLs, Network Firewall, and Egress

• Security groups are stateful and allow-only; referencing SGs as rule sources gives micro-segmentation that survives IP churn. NACLs are stateless, ordered, subnet-wide, and the only layer with an explicit deny — remember ephemeral return ports.
• Removing an SG rule does not cut existing tracked connections; a NACL deny does — NACLs are the subnet-level kill switch during containment.
• Gateway endpoints (S3/DynamoDB, route-table based, free) and interface endpoints (PrivateLink ENIs with security groups) keep traffic off the internet; endpoint policies with aws:PrincipalOrgID / aws:ResourceOrgID make them data-perimeter checkpoints.
• Network Firewall inspects only what routing steers through its endpoints: stateless 5-tuple rules plus Suricata-compatible stateful rules, including SNI/Host-based domain allow and deny lists for egress filtering.
• For "block egress except approved destinations": Network Firewall domain allow list in the routed path, DNS Firewall for the resolution layer — DNS Firewall controls lookups, not packets, so direct-to-IP traffic needs Network Firewall.
• Centralized inspection = spoke TGW route tables defaulting to an inspection VPC running Network Firewall, with appliance mode enabled to keep flows symmetric; TGW route-table association and propagation are the segmentation controls.
• Direct Connect is not encrypted by default — MACsec or a VPN over the connection are the encryption-in-transit answers; Verified Access is the VPN-less identity-based access answer.
• Troubleshoot with Flow Logs signatures (inbound ACCEPT + outbound REJECT = stateless NACL return block; single REJECT = SG), route-table tracing for bypassed inspection, and Reachability Analyzer to name the blocking component.

Identity and Access Management

AWS Authentication Strategies: MFA, STS, and Federation

• Enforce MFA with an explicit deny on aws:MultiFactorAuthPresent using BoolIfExists — plain Bool exempts long-term access-key requests because the key is absent from their context.
• Prefer phishing-resistant FIDO2 keys for privileged users; protect root with MFA and no access keys, and use centralized root access management to remove member-account root credentials entirely.
• Design for roles everywhere: temporary STS credentials expire on their own, while every long-term access key is a standing liability audited via the credential report and last-used data.
• Choose the STS API by caller: AssumeRole for AWS principals, AssumeRoleWithSAML for IdP assertions, AssumeRoleWithWebIdentity for OIDC tokens, GetSessionToken to mint MFA-bearing sessions.
• Third-party cross-account access requires sts:ExternalId in the trust policy — it binds the vendor's customer record to your role and defeats the confused deputy.
• IAM Identity Center with permission sets and SCIM provisioning is the default workforce answer at multi-account scale; direct SAML federation to IAM is the legacy/single-account pattern.
• Cognito user pools authenticate app users and issue JWTs; identity pools exchange those tokens for temporary AWS credentials — one without the other grants no AWS access.
• AssumeRole AccessDenied is two-sided: the caller's policy must allow sts:AssumeRole and the role's trust policy must match the caller and every condition, including external ID and MFA.

IAM Policy Evaluation and Authorization Strategies on AWS

• Evaluation order: explicit deny first, then SCPs, RCPs, resource-based policies, identity-based policies, permissions boundaries, session policies — with implicit deny for anything never allowed.
• Only identity-based and resource-based policies grant access; SCPs, RCPs, boundaries, and session policies are ceilings that can only take away.
• Same-account access needs an allow from either the identity policy or the resource policy; cross-account access needs both sides — 'works same-account but not cross-account' means a side is missing its grant.
• Permissions boundaries are the delegated-admin control: condition iam:CreateRole on the boundary's presence and teams can self-serve roles that never exceed the ceiling.
• aws:PrincipalOrgID restricts a resource to your organization; aws:SourceArn and aws:SourceAccount pin service principals and defeat the confused deputy.
• ForAllValues matches vacuously when the key is absent — never use it alone in an Allow; pair it with a Null presence check.
• ABAC matches aws:PrincipalTag against aws:ResourceTag so access follows tags instead of policy edits, but only with strict control over who can tag.
• KMS key policies are the root of trust — IAM policies are powerless for a key unless its key policy enables them; S3 Block Public Access overrides any policy that would grant public access.

Data Protection

Data in Transit on AWS: TLS, ACM, and End-to-End Encryption Design

• Public ACM certificates auto-renew only while the DNS validation CNAME stays published and the certificate is in use; imported certificates never auto-renew.
• ACM certificates attach to integrated services — ELB, CloudFront (us-east-1), API Gateway — never directly to EC2; use exportable or Private CA certificates when a host needs key material.
• Enforcement is server-side: aws:SecureTransport denies on S3, ELB security policies plus HTTP-to-HTTPS redirects, CloudFront viewer and origin protocol policies, and rds.force_ssl or require_secure_transport on databases.
• An ALB always terminates TLS and can re-encrypt via HTTPS target groups without validating target certificates; an NLB TCP listener is passthrough and preserves true end-to-end encryption — the listener type decides.
• Direct Connect is private but not encrypted by default: use MACsec on supported dedicated connections or run an IPsec VPN over DX; Site-to-Site VPN is IPsec by definition.
• Inter-Region VPC peering and Transit Gateway peering traffic is encrypted by AWS on its global backbone, and supported Nitro instances encrypt traffic between themselves automatically.
• Diagnose TLS breakage from evidence: ALB access logs record the negotiated ssl_protocol and ssl_cipher per request — inventory clients before raising a minimum TLS version.

Encryption at Rest on AWS: KMS Keys, Key Policies, and Service Integration

• Customer managed keys are the only key type with editable key policies, controllable rotation, grants, deletion, and cross-account use — AWS managed (aws/service) keys can do none of that across accounts.
• The key policy is the root of trust: the default kms:* account-root statement is what enables IAM policies to work on the key, and removing it can make the key unmanageable.
• Cross-account KMS access needs both halves — the key policy allows the external account, and the external account's IAM policies allow the key ARN; aws:PrincipalOrgID scales this to an Organization.
• Envelope encryption is the universal pattern: GenerateDataKey for anything over the 4 KB Encrypt limit, with encryption context as auditable AAD that must match exactly on decrypt.
• Rotation never re-encrypts existing data and retains old key material; imported key material cannot auto-rotate; multi-Region keys decrypt across Regions without re-encryption.
• S3 Bucket Keys are the answer to KMS request costs and throttling under SSE-KMS; a bucket policy on s3:x-amz-server-side-encryption enforces the method and key.
• Encrypt-existing means snapshot-copy for both EBS and RDS, and sharing an encrypted snapshot requires a customer managed key — the default aws/ebs key cannot be shared.
• Disable a key and watch CloudTrail before scheduling deletion: the 7–30 day pending window is recoverable, but deletion makes every ciphertext under the key permanently unrecoverable.

Protecting Secrets, Confidential Data, and Cryptographic Key Material

• Secrets Manager earns its cost with rotation, resource-policy cross-account sharing, and multi-Region replication; Parameter Store SecureString is the free answer for encrypted configuration that never rotates.
• Rotation is a four-step Lambda contract — createSecret, setSecret, testSecret, finishSecret — with AWSCURRENT/AWSPENDING/AWSPREVIOUS staging labels; managed rotators cover RDS, Redshift, and DocumentDB, custom Lambdas cover everything else.
• Cross-account secret access always needs two grants: the secret's resource policy and the customer managed KMS key's policy — the default aws/secretsmanager key can never be shared.
• Leaked credentials are remediated rotate-first, then migrated to Secrets Manager — moving a still-valid credential fixes nothing.
• Macie automated discovery samples broadly and scores bucket sensitivity for org-wide PII hunts; scoped classification jobs scan exhaustively when you need a definitive answer for specific buckets.
• Masking (CloudWatch Logs data protection, SNS message data protection) and tokenization are the answers when regulators require values never to appear — encryption alone is reversible by design.
• The custody ladder trades operations for control: AWS-generated KMS material → imported BYOK material (your copy, your expiry, no auto-rotation) → CloudHSM-backed custom key stores → external key stores where material never enters AWS.
• ACM-managed certificate private keys are non-exportable; take an exportable or Private CA-issued certificate and the private key's custody — storage, rotation, exposure — becomes yours.

Security Foundations and Governance

AWS Organizations, SCPs, and Control Tower: Multi-Account Security Strategy

• The AWS account is the strongest isolation boundary — cross-account access is denied by default, so account separation is the blast-radius control that survives misconfiguration inside an account.
• The reference layout: a Security OU holding the log-archive account (immutable org-wide logs) and the audit account (delegated admin for security services), plus Workloads, Sandbox, and Suspended OUs.
• SCPs do not apply to the management account and never grant permissions — so keep the management account empty of workloads and delegate every security service to a member account.
• Memorize the SCP guardrail patterns: Region deny, root-user deny, deny leaving the organization, deny unencrypted uploads, and denying the APIs that disable CloudTrail, GuardDuty, and AWS Config.
• RCPs are the resource-side guardrail: a perimeter denying access unless aws:PrincipalOrgID matches your org stops external access even when a resource policy is misconfigured; they cover S3, STS, KMS, SQS, and Secrets Manager.
• Control Tower controls map to implementations: preventive = SCPs, detective = Config rules, proactive = CloudFormation hooks evaluated before provisioning; Account Factory vends pre-governed accounts.
• Workforce access goes through IAM Identity Center permission sets — no per-account IAM users; member-account root credentials are centrally removed, with MFA-protected break-glass procedures for what remains.

Secure IaC Deployment: CloudFormation, StackSets, and Service Catalog

• IaC makes security consistent: templates are versioned, peer-reviewed security artifacts, and drift detection flags out-of-band changes — with CloudTrail supplying who made them.
• Protect deployed security resources in layers: stack policies block risky updates, DeletionPolicy: Retain preserves log buckets and keys through stack deletion, and service roles scope who can deploy what.
• "Every current and future account" → service-managed StackSets with automatic deployment targeting OUs; self-managed StackSets need an execution role hand-built in every target account.
• Shift validation left: cfn-lint for template correctness, CloudFormation Guard rules for policy-as-code, cdk-nag for CDK, and reviewed change sets as the production approval gate.
• Never put secrets in templates — NoEcho only masks display; the answer is dynamic references that resolve from Secrets Manager (with rotation) or SSM SecureString parameters at deploy time.
• Service Catalog launch constraints let users launch approved products under a launch role without holding the underlying permissions; AWS RAM shares live resources like subnets across accounts; Firewall Manager centrally enforces WAF, security group, Shield, and Network Firewall policies.
• Enforce tags at deploy time with tag policies and tagged baseline templates, backed by a detective required-tags Config rule.
• Pipelines get least privilege: per-environment cross-account deploy roles, OIDC federation instead of stored keys, and approval gates on production change sets.

Evaluating AWS Resource Compliance: Config, Security Hub, Audit Manager

• AWS Config is the continuous technical-compliance engine: recorder produces configuration items, rules evaluate them (change-triggered or periodic), remediation configurations fix them.
• A stopped recorder kills change-triggered rules and leaves unfillable gaps in the resource timeline; periodic rules keep running, so the breakage is easy to miss.
• Auto-remediation = Config rule + SSM Automation runbook + AutomationAssumeRole; failures are almost always role permissions, manual-mode, or a missing rule-to-remediation association.
• Conformance packs deploy framework-mapped rule sets org-wide with a per-pack compliance score; aggregators provide the single org-wide compliance view — individual-account sources must authorize it.
• Security Hub standards (FSBP, CIS, PCI DSS) score posture as the percentage of passing controls; most controls are backed by Config rules, so Security Hub inherits Config's health.
• Audit Manager collects and organizes evidence for YOUR audit (SOC 2, PCI, HIPAA assessments with daily evidence folders); Artifact downloads AWS's own reports — the provider side of shared responsibility.
• Config answers 'what state is it in and was it compliant'; CloudTrail answers 'who did what, when' — state versus events, and the exam tests the distinction directly.
• A compliance program maps each framework requirement to a detective control, an auto-remediation or ticket, and an evidence trail — continuous, not point-in-time.