AWS Certified Security - Specialty (SCS-C03) Ultimate Cheat Sheet
Your Quick Reference Study Guide
This cheat sheet covers the core concepts, terms, and definitions you need to know for the AWS Certified Security - Specialty (SCS-C03). We've distilled the most important domains, topics, and critical details to help your exam preparation.
💡 Note: While this study guide highlights essential concepts, it's designed to complement—not replace—comprehensiv e learning materials. Use it for quick reviews, last-minute prep, or to identify areas that need deeper study before your exam.
About This Cheat Sheet: This study guide covers core concepts for AWS Certified Security - Specialty (SCS-C03). It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
AWS Certified Security - Specialty (SCS-C03)
Cheat Sheet •
About This Cheat Sheet: This study guide covers core concepts for AWS Certified Security - Specialty (SCS-C03). It highlights key terms, definitions, common mistakes, and frequently confused topics to support your exam preparation.
Use this as a quick reference alongside comprehensive study materials.
Detection
16%AWS Config — Record, Evaluate, Remediate
Central recorder + rules + aggregators; automated remediation via SSM Automation or Lambda using a configured execution/
Key Insight
Config only detects and records; remediation must be explicitly configured (SSM/Lambda), runs asynchronously, and uses a remediation execution role.
Often Confused With
Common Mistakes
- Believing Config auto-remediates — you must attach SSM Automation or Lambda runbooks.
- Thinking Config blocks changes — it records/evaluates only; prevention needs IAM/SCPs or guardrails.
- Assuming aggregators work by default — create an Aggregator and grant cross-account/region permissions.
GuardDuty — Managed Threat Detection
Agentless continuous threat detection using CloudTrail, VPC Flow Logs and DNS logs; findings delivered to EventBridge/SB
Key Insight
GuardDuty classifies findings with severity and confidence but does not remediate; route findings to EventBridge/Security Hub to trigger automated run
Often Confused With
Common Mistakes
- Installing agents on EC2 — GuardDuty is agentless and uses AWS telemetry.
- Expecting GuardDuty to fix issues — it detects only; use EventBridge -> Lambda/SSM for remediation.
- Assuming all findings are high-confidence — validate severity/confidence before taking disruptive action.
CloudTrail — API Audit Trail (Mgmt vs Data Events)
Records AWS API & account activity for audit/forensics; management events default, data events are opt‑in.
Key Insight
Mgmt (control‑plane) events are logged by default; resource/data events (S3, Lambda) must be enabled and deliver to encrypted S3/CloudWatch with log‑+
Often Confused With
Common Mistakes
- Assuming data events (e.g., S3 GetObject) are logged by default — they must be explicitly enabled.
- Expecting CloudTrail to block or prevent attacks — it only records activity for audit/forensics.
- Relying on CloudTrail alone for detection — combine with VPC Flow Logs, CloudWatch, Config and SIEM for coverage.
Centralized Logging & Monitoring — Detect, Alert, Correlate
Centralize multi‑region logs (CloudTrail, VPC Flow, CloudWatch Logs), parse and correlate events, then tune alerts and自动
Key Insight
Centralize logs to a protected cross‑account S3/CloudWatch store, enable integrity/retention, parse+correlate, and tune metric filters to avoid noise.
Often Confused With
Common Mistakes
- Thinking log volume equals detection — without parsing/correlation you still miss threats.
- Enabling CloudTrail in one region only — use multi‑region trail for complete account activity.
- Centralizing logs to S3 without encryption, strict access controls, or integrity (Object Lock/log file validation).
EventBridge Rules & Delivery (CloudWatch Events)
Routes matching events to targets; failures almost always come from pattern, bus, or permission issues.
Key Insight
Event patterns use JSON pattern language (not regex); publish-to-bus + rule + target permissions together determine delivery.
Often Confused With
Common Mistakes
- Assuming event patterns accept regex — they use JSON pattern types (exact, prefix, anything‑but, arrays).
- Publishing to the wrong event bus (default vs custom) — rules won't match events on another bus.
- Missing target resource/role permissions — cross-account Lambdas, SQS, Kinesis need resource policies or invoke roles.
Log→Metric Filters & Alarm Evaluation
Extract counts/values from logs into CloudWatch metrics; alarms act on those metrics using period/statistic rules.
Key Insight
Filters emit metrics only when patterns match; alarms evaluate aggregated datapoints (period/statistic), so short spikes or wrong namespaces cause 'No
Often Confused With
Common Mistakes
- Expecting immediate raw-log alerts — alarms fire on metrics after the configured period/datapoints, not on each log line.
- Believing filters auto-create alarms/dashboards — filters only publish metrics; alarms and dashboards must be created separately.
- Using wrong namespace/name or dimensions — alarms evaluate the wrong (or non‑existent) metric, yielding 'Insufficient Data'.
AWS Config — Record, Evaluate, Remediate
Central recorder + rules + aggregators; automated remediation via SSM Automation or Lambda using a configured execution/
Key Insight
Config only detects and records; remediation must be explicitly configured (SSM/Lambda), runs asynchronously, and uses a remediation execution role.
Often Confused With
Common Mistakes
- Believing Config auto-remediates — you must attach SSM Automation or Lambda runbooks.
- Thinking Config blocks changes — it records/evaluates only; prevention needs IAM/SCPs or guardrails.
- Assuming aggregators work by default — create an Aggregator and grant cross-account/region permissions.
GuardDuty — Managed Threat Detection
Agentless continuous threat detection using CloudTrail, VPC Flow Logs and DNS logs; findings delivered to EventBridge/SB
Key Insight
GuardDuty classifies findings with severity and confidence but does not remediate; route findings to EventBridge/Security Hub to trigger automated run
Often Confused With
Common Mistakes
- Installing agents on EC2 — GuardDuty is agentless and uses AWS telemetry.
- Expecting GuardDuty to fix issues — it detects only; use EventBridge -> Lambda/SSM for remediation.
- Assuming all findings are high-confidence — validate severity/confidence before taking disruptive action.
CloudTrail — API Audit Trail (Mgmt vs Data Events)
Records AWS API & account activity for audit/forensics; management events default, data events are opt‑in.
Key Insight
Mgmt (control‑plane) events are logged by default; resource/data events (S3, Lambda) must be enabled and deliver to encrypted S3/CloudWatch with log‑+
Often Confused With
Common Mistakes
- Assuming data events (e.g., S3 GetObject) are logged by default — they must be explicitly enabled.
- Expecting CloudTrail to block or prevent attacks — it only records activity for audit/forensics.
- Relying on CloudTrail alone for detection — combine with VPC Flow Logs, CloudWatch, Config and SIEM for coverage.
Centralized Logging & Monitoring — Detect, Alert, Correlate
Centralize multi‑region logs (CloudTrail, VPC Flow, CloudWatch Logs), parse and correlate events, then tune alerts and自动
Key Insight
Centralize logs to a protected cross‑account S3/CloudWatch store, enable integrity/retention, parse+correlate, and tune metric filters to avoid noise.
Often Confused With
Common Mistakes
- Thinking log volume equals detection — without parsing/correlation you still miss threats.
- Enabling CloudTrail in one region only — use multi‑region trail for complete account activity.
- Centralizing logs to S3 without encryption, strict access controls, or integrity (Object Lock/log file validation).
EventBridge Rules & Delivery (CloudWatch Events)
Routes matching events to targets; failures almost always come from pattern, bus, or permission issues.
Key Insight
Event patterns use JSON pattern language (not regex); publish-to-bus + rule + target permissions together determine delivery.
Often Confused With
Common Mistakes
- Assuming event patterns accept regex — they use JSON pattern types (exact, prefix, anything‑but, arrays).
- Publishing to the wrong event bus (default vs custom) — rules won't match events on another bus.
- Missing target resource/role permissions — cross-account Lambdas, SQS, Kinesis need resource policies or invoke roles.
Log→Metric Filters & Alarm Evaluation
Extract counts/values from logs into CloudWatch metrics; alarms act on those metrics using period/statistic rules.
Key Insight
Filters emit metrics only when patterns match; alarms evaluate aggregated datapoints (period/statistic), so short spikes or wrong namespaces cause 'No
Often Confused With
Common Mistakes
- Expecting immediate raw-log alerts — alarms fire on metrics after the configured period/datapoints, not on each log line.
- Believing filters auto-create alarms/dashboards — filters only publish metrics; alarms and dashboards must be created separately.
- Using wrong namespace/name or dimensions — alarms evaluate the wrong (or non‑existent) metric, yielding 'Insufficient Data'.
Incident Response
14%Incident Response (IR) Playbook
Six-stage IR lifecycle for AWS: prepare, detect/analyze, contain, eradicate, recover, post‑incident — restore service &證
Key Insight
Containment limits impact; eradication removes root cause. Preserve artifacts and start staged recovery after safe containment.
Often Confused With
Common Mistakes
- Treating containment as eradication — stopping spread isn't removing the root cause.
- Waiting for 100% eradication before any recovery; you can stage recovery after containment.
- Relying only on CloudTrail — miss VPC Flow, ELB logs, EBS snapshots and memory artifacts.
Lambda Auto‑Remediation
Automated remediation via Lambda triggered by EventBridge/CloudWatch/Security Hub; requires correct triggers, least‑priv
Key Insight
Auto-remediation is a control, not a cure — design idempotent functions with least‑privilege, retries, DLQs and post‑action verification.
Often Confused With
Common Mistakes
- Deploying remediation Lambdas without testing (no canaries or runbook dry-runs).
- Attaching broad IAM permissions to remediation Lambdas instead of least‑privilege.
- Assuming invocation == success; skip verification, retries, and idempotence.
Incident Response (IR) Playbooks & Runbooks
Map detection → triage → evidence collection → containment; design safe, testable automation.
Key Insight
Playbooks pick actions by incident class/severity; runbooks give the step‑by‑step, evidence‑preserving procedures.
Often Confused With
Common Mistakes
- Treating playbooks and runbooks as interchangeable
- Automating remediation without validating triggers, scope, and safety
- Executing remediation before collecting volatile evidence/chain‑of‑custody steps
Log Forensics: Timeline & Correlation
Normalize timestamps, correlate multi-source telemetry, and build evidence-based timelines to validate compromise.
Key Insight
Normalize clocks and enrich across sources; single-field matches or raw volume spikes are NOT proof of compromise.
Often Confused With
Common Mistakes
- Trusting raw timestamps—ignore clock skew, time zones, and NTP failures
- Assuming identical IPs/events mean the same actor—NAT, proxies, and shared addresses exist
- Declaring compromise from a single anomalous event without cross-source correlation
Infrastructure Security
18%AWS WAF — Web App Firewall (Edge vs Regional)
HTTP/S request filter at CloudFront, ALB, or API Gateway to block and monitor application‑layer threats.
Key Insight
WAF inspects traffic only where TLS is terminated (CloudFront or regional endpoints); it doesn't mitigate volumetric L3/L4 DDoS by itself.
Often Confused With
Common Mistakes
- Expecting WAF to mitigate volumetric L3/L4 DDoS — that's Shield's domain.
- Assuming a Web ACL on CloudFront automatically protects ALBs or API Gateway.
- Thinking WAF can inspect encrypted TLS without terminating TLS at the WAF point.
AWS Shield — DDoS Protection (Standard & Advanced)
DDoS mitigation for AWS endpoints: Standard covers common L3/L4 attacks; Advanced adds visibility, DRT, app mitigation &
Key Insight
Shield Standard auto-defends common network/protocol attacks; robust L7 (HTTP) protection requires WAF and/or Shield Advanced plus tuned rules and/or架
Often Confused With
Common Mistakes
- Believing Shield Standard protects application‑layer (HTTP) attacks.
- Assuming Shield Advanced removes the need for WAF or rule tuning for L7 mitigation.
- Expecting unconditional cost protection — only validated DDoS-related scaling costs qualify.
Security Groups (SG) — Instance‑Level Firewall
Stateful VPC virtual firewall attached to ENIs/instances; use role/tier SGs to enforce least privilege.
Key Insight
SGs only allow traffic (no explicit DENY); they attach to ENIs/instances and rules are ORed (no ordered evaluation).
Often Confused With
Common Mistakes
- Expecting explicit DENY rules in SGs
- Thinking SGs attach to subnets and auto‑apply to all instances
- Believing rule order stops evaluation (rules are effectively ORed)
Cloud Vulnerability Lifecycle (CVE/CVSS → Remediate)
Integrate scanning, CVE/CVSS‑based triage, exploitability & asset prioritization, orchestration, and verification intoCI
Key Insight
Prioritize by exploitability + asset criticality, orchestrate patches/mitigations with responsibility mapping, and always verify fixes (shared‑respons
Often Confused With
Common Mistakes
- Treating scans as remediation — scan ≠ fix
- Relying on CVSS score alone without exploitability or asset context
- Assuming the cloud provider will patch all vulnerabilities (ignore shared responsibility)
VPC — Virtual Private Cloud (Isolated AWS Network)
Logically isolated AWS network where you define IP ranges, subnets, routing, gateways and security controls for segmenta
Key Insight
VPC provides isolation and routing only—use security groups (stateful), NACLs (stateless), endpoints and Transit Gateway for controls; VPC doesn'tauto
Often Confused With
Common Mistakes
- Treating security groups as stateless (they're stateful).
- Assuming a VPC auto-encrypts in-transit traffic between instances.
- Using route tables to filter by port/protocol (they only route by CIDR).
NACLs — Stateless Subnet Packet Filters
Subnet-level, stateless ACLs that explicitly allow or deny traffic; return traffic requires matching explicit rules.
Key Insight
NACLs act at the subnet boundary and are stateless—every direction of traffic needs its own rule; rule order (lowest first) matters for evaluation.
Often Confused With
Common Mistakes
- Expecting NACLs to allow return traffic automatically (they're stateless).
- Thinking security groups can do explicit DENY rules (they're allow-only).
- Configuring NACLs as if they apply to individual instances (they apply to subnets).
Identity and Access Management
20%AWS IAM — Identities, Roles & Policies
Central authn/authz: users, groups, roles, federation, MFA and STS temporary creds to enforce least privilege.
Key Insight
Access is evaluated across identity, resource, SCP, session and boundary policies — an explicit Deny anywhere wins.
Often Confused With
Common Mistakes
- Thinking SCPs grant permissions to member accounts
- Assuming enabling MFA blocks all API calls unless used every time
- Believing roles issue permanent credentials instead of temporary STS sessions
IAM Policy JSON — Allow/Deny Rules
JSON statements that Allow or Deny actions on resources with conditions; evaluated together with boundaries and SCPs.
Key Insight
Explicit Deny always overrides Allow; wildcard/NotAction forms and ARN distinctions can silently broaden access.
Often Confused With
Common Mistakes
- Assuming policies are permissive by default — default is Deny
- Believing an Allow can override an explicit Deny
- Using NotAction/NotResource thinking it's safer — it often expands scope
Least Privilege — No Wildcards
Grant principals only the exact actions/resources required; avoid '*' and vague ARNs to limit blast radius.
Key Insight
Some actions ignore resource ARNs—service or Resource='*' can still permit dangerous ops; prefer explicit ARNs + conditions.
Often Confused With
Common Mistakes
- Using '*' in Action or Resource for convenience
- Assuming '*' on Resource is safe if Actions are limited
- Relying on AWS-managed policies to guarantee least privilege
KMS Key Policies & Grants
KMS key policy is the gatekeeper for CMKs; IAM policies and grants only work when the key policy permits them.
Key Insight
Key policy is authoritative—IAM can allow access but the key policy can still block it; grants are temporary scoped exceptions.
Often Confused With
Common Mistakes
- Assuming an IAM policy alone permits CMK use
- Believing the account root automatically has unrestricted CMK access
- Treating grants as permanent replacements for key policies
Data Protection
18%Encryption-in-Transit (TLS/mTLS & VPN)
Protects data moving between hosts/services using TLS/mTLS, VPNs or secure endpoints to ensure confidentiality and tampr
Key Insight
Encryption only counts if it's end-to-end and validated — TLS termination, weak ciphers, or missing cert validation breaks protection.
Often Confused With
Common Mistakes
- Assuming internal VPC traffic is safe and skipping TLS
- Thinking server-side (at-rest) encryption protects transit
- Believing any TLS version/cipher suite meets strong requirements
ACM (AWS Certificate Manager) — Certs & Limits
Manages TLS certs for AWS services; public certs auto-renew; private, imported, and regional use have limits and costs.
Key Insight
Public ACM certs do NOT expose private keys or export; CloudFront requires certs in us-east-1; ACM PCA/imported certs change export/renew behavior and
Often Confused With
Common Mistakes
- Expecting to export private keys from public ACM certificates
- Assuming ACM PCA or imported certs are free
- Believing ACM will auto-renew imported or improperly validated certs
At‑Rest Encryption — SSE vs CSE & Envelope Keys
Encrypt objects, volumes and backups with SSE (S3/KMS), client‑side, or envelope patterns; enforce key lifecycle and RB‑
Key Insight
Who holds keys (SSE vs CSE) dictates control/attack surface; envelope encryption reduces KMS ops while keeping key separation.
Often Confused With
Common Mistakes
- Assuming 'enable default encryption' retroactively encrypts existing objects
- Assuming provider‑managed keys satisfy all compliance or key‑separation requirements
- Believing encryption removes need for IAM/audit controls or that backups/snapshots inherit encryption automatically
AWS Data Integrity — Checksums, HMACs & Signatures
Use checksums for accidental corruption, HMACs for authenticated integrity inside a trust domain, and signatures for non
Key Insight
Checksums detect random corruption; HMACs authenticate within shared‑secret domains; digital signatures prove origin to third parties.
Often Confused With
Common Mistakes
- Treating plain checksums (MD5/CRC) as authenticated integrity
- Thinking HMACs provide non‑repudiation equivalent to digital signatures
- Reusing HMAC/signing keys across systems or purposes, enabling cross‑context forgery
AWS KMS — CMKs, Grants & Multi‑Region Keys
Regional, HSM-backed key service for creating/using CMKs, grants, rotation and envelope encryption.
Key Insight
CMK material is non‑exportable; KMS is regional — use multi‑Region keys or replicate CMKs; key policies, grants and IAM all interact.
Often Confused With
Common Mistakes
- Assuming CMK key material can be exported from KMS HSMs
- Expecting automatic rotation for imported key material
- Treating KMS keys as global — forgetting region or multi‑Region setup
Data Encryption — SSE, CSE, Envelope & TLS
Select server/client-side and transport encryption patterns with explicit key control, rotation and end‑to‑end design.
Key Insight
Encryption is layered — key lifecycle and access control matter as much as algorithm; storage and transport are configured separately.
Often Confused With
Common Mistakes
- Relying on encryption alone and ignoring IAM/key access controls
- Assuming provider default encryption removes your key lifecycle duties
- Believing TLS at ELB guarantees end‑to‑end encryption without backend TLS
Security Foundations and Governance
14%Security Hub — Org‑wide Findings Hub
Central aggregator that normalizes findings, runs compliance checks, and triggers automations across accounts/regions.
Key Insight
Security Hub is region‑scoped and requires org auto‑enable or a delegated admin per region to centralize findings.
Often Confused With
Common Mistakes
- Assuming enabling Security Hub in the management account auto‑enables member accounts
- Thinking enabling Security Hub in one region covers all regions
- Expecting Security Hub to auto‑remediate findings (it only alerts/triggers automations) or incur no extra cost
Core AWS Security Principles
Practical rules: shared responsibility, least privilege, defense‑in‑depth, secure defaults, automation, and threat‑model
Key Insight
Map controls to who (AWS vs you) is responsible and apply layered, continually refined least‑privilege across identity, network, data, and deployments
Often Confused With
Common Mistakes
- Assuming AWS is responsible for all security (ignores shared responsibility)
- Relying on one strong control (skip defense‑in‑depth)
- Treating least privilege as a one‑time action instead of ongoing refinement
Container Security Lifecycle (Image → Runtime → Retire)
Secure containers across build, supply‑chain, registry, deployment, runtime, and decommissioning.
Key Insight
Treat images as code + supply‑chain: continuous scanning, SBOM/attestation, strict registry policy, runtime EDR, and host hardening.
Often Confused With
Common Mistakes
- Assuming a single build-time image scan protects runtime forever.
- Believing a one-time image signature prevents all tampering at deploy/runtime.
- Treating containers like VMs and skipping host hardening or runtime EDR.
CI/CD Security Gates: SAST/DAST/SCA/IaC/SBOM/Attestation
Embed SAST/DAST/SCA, IaC checks, SBOM generation, image scans and artifact signing/attestation to gate unsafe builds.
Key Insight
Shift-left + continuous re-scans + enforce policy gates and attestations — signing blocks tampered artifacts, but runtime detection is required for un
Often Confused With
Common Mistakes
- Assuming automated pipeline scans make the app fully secure.
- Relying only on static/IaC scans and skipping runtime detection/monitoring.
- Thinking artifact signing/attestation alone guarantees safe runtime behavior.
CloudWatch — Logs & Metrics for Audit Evidence
Collects metrics, logs, events and alarms as queryable, retained telemetry used to produce audit evidence for compliance
Key Insight
CloudWatch supplies tamper‑evident telemetry and retention — it's audit evidence, not automatic compliance; KMS, retention, integrity and control‑mapp
Often Confused With
Common Mistakes
- Turning CloudWatch on =/= compliance; it's an evidence source, not a compliance fix
- Retention ≠ GDPR erasure; you must implement deletion/PII workflows and proof
- Assuming logs are KMS‑encrypted and access‑restricted by default
ABAC vs RBAC — Attribute vs Role Controls
ABAC uses attributes (tags/claims) for dynamic policies; RBAC uses predefined roles — choose by scale, governance, and审计
Key Insight
ABAC scales but requires strict attribute governance and provenance; RBAC is simpler to audit but risks role bloat—validate with permission reports
Often Confused With
Common Mistakes
- Believing ABAC is intrinsically more secure; weak attributes = weak controls
- Assuming RBAC guarantees least privilege; poorly scoped roles still overprivilege
- Trusting tags automatically; enforce tag provenance and reference them explicitly in policies
Certification Overview
Cheat Sheet Content
Similar Cheat Sheets
- CCNA Exam v1.1 (200-301) Cheat Sheet
- AWS Certified Cloud Practitioner (CLF-C02) Cheat Sheet
- AWS Certified AI Practitioner (AIF-C01) Cheat Sheet
- Exam AI-900: Microsoft Azure AI Fundamentals Cheat Sheet
- Google Cloud Professional Cloud Architect Cheat Sheet
- Google Cloud Security Operations Engineer Exam Cheat Sheet