Security, Identity & Compliance
Identity and access control, encryption and key management, threat detection, and compliance tooling.
Amazon Cognito
Managed authentication and authorization for your app's users — sign-up, sign-in, and temporary AWS credentials.
- User Pools = authentication (who are you) — a user directory that handles sign-up, sign-in, MFA, and returns JWT tokens
- Identity Pools = authorization (what can you access) — swaps an identity for temporary AWS credentials via STS, including unauthenticated guest access
- Federation: sign in with Google, Facebook, Apple, Amazon, or corporate SAML 2.0 / OIDC providers — Cognito is the broker so your app only speaks one token format
- For app users (customers), not workforce — employees logging into AWS itself is IAM Identity Center, not Cognito
Exam triggers
Phrases and scenarios that point here.
- "Sign-up / sign-in for a web or mobile app", "user directory", "social login" → User Pools
- "App users need direct access to S3 / DynamoDB", "temporary AWS credentials", "guest access" → Identity Pools
- "Millions of users" + "minimal operational overhead" for auth → Cognito over building on EC2/DynamoDB
- "MFA", "adaptive authentication", "compromised credential detection" for app users → Cognito threat protection
Not this service
- Workforce/employee SSO into AWS accounts and business apps → IAM Identity Center
- Service-to-service or AWS-resource permissions without human users → IAM roles/policies
- Managed Microsoft AD or domain-joined workloads → AWS Directory Service
Use cases
- Mobile app login: think hotel front desk (User Pool checks you in and hands you a keycard/JWT) vs. the keycard itself opening specific doors (Identity Pool grants scoped AWS access)
- Photo-sharing app where each signed-in user uploads directly to their own S3 prefix — Identity Pool issues per-user temporary credentials, no backend proxy needed
- SaaS product offering "Continue with Google" alongside email/password, with one consistent token your API validates regardless of how the user signed in
- B2B app where enterprise customers demand login via their own corporate IdP — federate their SAML provider into your User Pool without rebuilding auth per customer
- Guest mode: let unauthenticated users browse with read-only AWS access via Identity Pools, then upgrade to full access after sign-up
Commonly confused with
Verified against AWS documentation · 2026-08-28
Amazon Detective
Security investigation service that builds a behavior graph from your logs so you can trace a finding back to its root cause.
- Answers "what happened and why" AFTER a finding exists — GuardDuty detects, Detective investigates
- Auto-ingests CloudTrail, VPC Flow Logs, EKS audit logs, GuardDuty findings, and Security Hub findings — no pipelines, no queries to write
- Uses ML, statistical analysis, and graph theory to build a behavior graph linking accounts, resources, and IP addresses over time
- Retains up to 1 year of aggregated data for analysis
- Prerequisite: GuardDuty must be enabled at least 48 hours before enabling Detective
Exam triggers
Phrases and scenarios that point here.
- "Root cause analysis" of a security finding → Detective
- "Investigate" or "analyze" suspicious activity across accounts and time → Detective
- "Visualize relationships" between resources, users, and IPs during an incident → behavior graph
- Detect vs. investigate distinction: GuardDuty raises the alarm, Detective works the case
Not this service
- Detecting threats in the first place → GuardDuty
- Aggregating findings and compliance posture in one dashboard → Security Hub
- Scanning EC2/containers for software vulnerabilities → Inspector
- Finding sensitive data in S3 → Macie
Use cases
- An engineer's access key shows up in a GuardDuty finding — Detective's behavior graph shows every API call, resource touched, and IP involved, so you know if it was a leaked key or the engineer on hotel Wi-Fi
- Tracing a compromised EC2 instance backwards: which role launched it, what it talked to, and whether the traffic pattern is new or normal for that instance
- Post-incident scoping across an AWS Organization — one behavior graph over member accounts instead of grepping CloudTrail in each one
- Deciding if a spike in failed logins is an attack or a misconfigured cron job, by comparing against up to a year of baseline behavior
Commonly confused with
Verified against AWS documentation · 2026-08-26
Amazon GuardDuty
Managed threat detection that continuously analyzes account and network activity for malicious behavior — no agents, no rules to write.
- Foundational sources: CloudTrail management events, VPC Flow Logs, DNS query logs — analyzed directly by GuardDuty, you don't need to enable or pay for those logs separately
- Detects with threat intelligence feeds + ML anomaly detection: compromised credentials, crypto mining, unusual API calls, C2 traffic
- Optional protection plans bolt on per source: S3, EKS, RDS, Lambda, Runtime Monitoring, Malware Protection — toggle independently; foundational detection can't be disabled while GuardDuty is on
- Regional service — enable per Region; org-wide rollout via AWS Organizations with a delegated administrator account
- Findings are read-only detections routed to EventBridge / Security Hub — GuardDuty detects, it never blocks or remediates by itself
Exam triggers
Phrases and scenarios that point here.
- "Continuously monitor for malicious activity / compromised instances / unusual API calls" → GuardDuty
- "Threat detection with no agents or infrastructure to manage" → GuardDuty
- "EC2 instance mining cryptocurrency" or "credentials used from an unusual location" → classic GuardDuty finding scenarios
- "Automatically respond to a finding" → GuardDuty finding → EventBridge rule → Lambda/SNS (GuardDuty itself takes no action)
Not this service
- Scanning workloads for software vulnerabilities/CVEs → Inspector
- Discovering sensitive data (PII) in S3 → Macie
- Deep-dive investigation of a finding's root cause → Detective
- Aggregating security findings across services into one dashboard → Security Hub
Use cases
- A leaked access key starts making API calls from an IP range your team has never touched — GuardDuty flags the anomaly before the bill does
- An EC2 instance quietly joins a mining pool at 2 a.m.; the crypto-mining finding fires into EventBridge and a Lambda isolates the instance's security group
- Fresh AWS Organization with 40 accounts: one delegated admin enables GuardDuty everywhere in minutes — the fastest path to baseline threat visibility without deploying anything
- Compliance requires continuous threat monitoring evidence; GuardDuty findings piped to Security Hub become the audit trail
Commonly confused with
Verified against AWS documentation · 2026-08-26
Amazon Inspector
Automated, continuous vulnerability scanning for EC2 instances, ECR container images, and Lambda functions.
- Continuous, not scheduled — new instances, pushed images, and deployed functions are discovered and scanned automatically, then rescanned when new CVEs drop
- Scans three resource types: EC2 (via SSM Agent or agentless EBS-snapshot scanning), ECR images (enhanced scanning), Lambda functions and layers
- Finds two problem classes: software vulnerabilities (CVEs in OS and language packages) and unintended network exposure
- Each finding gets a risk score contextualized by environment — an internet-reachable vulnerable instance ranks above the same CVE on a private one
- Organization-wide: enable once via delegated admin, findings roll up to Security Hub
Exam triggers
Phrases and scenarios that point here.
- "Software vulnerabilities", "CVEs", "unpatched packages" on EC2 or containers → Inspector
- "Continuously scan container images in ECR" → Inspector enhanced scanning
- "Network reachability" / "unintended network exposure" assessment → Inspector
- Automated security assessment of workloads (not accounts, not data) → Inspector
Not this service
- Threat detection from logs/behavior (compromised credentials, crypto mining) → GuardDuty
- Finding sensitive data (PII) in S3 → Macie
- Aggregating findings across security services → Security Hub
- Account-level best-practice checks (open ports in SGs, IAM hygiene) → Trusted Advisor
Use cases
- A log4j-style zero-day lands overnight — Inspector rescans your whole fleet against the new CVE and surfaces every affected instance and image by morning, no scan jobs to kick off
- CI/CD pushes a container image to ECR and it's scanned on push, so a vulnerable base layer is flagged before the deploy pipeline promotes it
- A team quietly launches EC2 instances for a side project — Inspector auto-discovers them and they show up in findings without security ever knowing the instances existed
- Compliance audit asks 'how do you manage vulnerabilities?' — continuous scanning plus Security Hub findings history is the evidence trail
Commonly confused with
Verified against AWS documentation · 2026-08-26
Amazon Macie
Managed service that discovers sensitive data in Amazon S3 and flags risky bucket configurations.
- Amazon S3 only — general purpose buckets; nothing for RDS, EBS, DynamoDB, or EFS
- Two discovery modes: automated (daily sampling, sensitivity score per bucket) and discovery jobs (targeted, one-time or scheduled)
- Detects using managed data identifiers (PII, financial, credentials) plus custom regex identifiers; allow lists suppress known-safe matches
- Two finding types: policy (bucket public, unencrypted, shared outside the org) and sensitive data (what's inside the object)
- Limits: findings and discovery results kept 90 days, 10,000 buckets inventoried per account, 15 detection locations per finding, regional — enable per Region
Exam triggers
Phrases and scenarios that point here.
- "Discover PII", "find credit card numbers", "detect credentials" in S3 → Macie
- "GDPR / HIPAA / PCI-DSS" + "where does our sensitive data live" → Macie, not Config
- Alert when a bucket holding customer data becomes public → Macie policy finding → EventBridge → Lambda
- Sensitive data sitting outside S3 → export it to S3 first, then Macie
Not this service
- Threat detection from CloudTrail, VPC Flow, or DNS logs → GuardDuty
- Resource configuration drift and compliance rules → AWS Config
- OS, package, and CVE scanning for EC2/ECR/Lambda → Inspector
- Redacting PII from text at request time → Comprehend
Use cases
- Pre-handoff audit — scan a legacy bucket before shipping the data dump to a partner, so you find out you're exporting customer PII before they do
- Credential leak sweep — dev exports, CloudFormation outputs, and .env backups that a CI job quietly pushed to S3
- Data lake landing zone guardrail — a scheduled job on the raw ingest prefix so a new upstream feed can't silently start writing SSNs into the lake
- Inherited-account triage — enable Macie org-wide after an acquisition and use bucket sensitivity scores to decide which of 400 unknown buckets to open first
- Automated containment — policy finding on a bucket going public routes through EventBridge to a Lambda that re-applies Block Public Access and pages the owner
Commonly confused with
Verified against AWS documentation · 2026-08-24
AWS Certificate Manager
Provisions, manages, and auto-renews SSL/TLS certificates for AWS services.
- Public certificates for ACM-integrated services (ALB, CloudFront, API Gateway) are free — you never touch the private key
- DNS validation → auto-renewal forever; email validation → someone must click a link before expiry, or the cert lapses
- Regional service: the cert must live in the same Region as the resource using it — except CloudFront, which only reads certs from us-east-1
- Limits: 2,500 certs per Region per account, 10 domain names per cert (raisable to 100), wildcard covers one subdomain level only (*.example.com, not a.b.example.com)
Exam triggers
Phrases and scenarios that point here.
- "HTTPS on the load balancer / CloudFront / API Gateway" → ACM public cert, free
- "Certificate expired and the site went down" → email validation was used; switch to DNS validation for auto-renewal
- "Custom domain on CloudFront" → cert must be requested in us-east-1, regardless of where anything else lives
- "TLS on an EC2 instance directly" → exam convention: ACM public certs can't be exported, so use a third-party cert or Private CA. Reality since June 2025: exportable public certs exist, but they're paid — expect the exam to lag here
Not this service
- Certificates for internal-only apps and devices with your own CA hierarchy → AWS Private CA
- Storing arbitrary secrets, API keys, or database credentials → Secrets Manager
Use cases
- Terminating HTTPS at an ALB fronting a fleet of instances — traffic is encrypted to the edge, plain HTTP inside the VPC, and nobody ever files a renewal ticket again
- One wildcard cert (*.shop.example) covering every tenant subdomain of a SaaS storefront, attached to a single ALB listener
- CloudFront distribution with a custom domain — the one architecture where the us-east-1 rule bites teams deploying everything in ap-southeast-1
- Killing the annual 2 a.m. outage caused by a certificate someone bought manually three years ago and forgot about — DNS-validated ACM certs renew themselves
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS CloudHSM
Dedicated, single-tenant hardware security modules in your VPC — you own the keys, AWS can't touch them.
- Single-tenant hardware in your VPC — FIPS 140-3 Level 3 validated (hsm2m.medium); older hsm1.medium is deprecated
- You control keys end-to-end: AWS has zero visibility and zero recovery — lose your crypto credentials and the keys are gone forever
- Cluster of 1–28 HSMs; HA is YOUR job — run at least 2 HSMs across 2 AZs, keys sync automatically within the cluster
- Talks industry-standard APIs: PKCS#11, JCE (Java), CNG/KSP (Windows) — apps integrate directly, not via AWS APIs
- Can back KMS as a custom key store when you need KMS integration but keys must live in dedicated hardware
Exam triggers
Phrases and scenarios that point here.
- "FIPS 140-3 Level 3" or "dedicated/single-tenant hardware" → CloudHSM, not KMS
- "Contractual or regulatory requirement that AWS must have no access to keys"
- Migrating an on-prem HSM workload (PKCS#11 app, Oracle TDE, SSL/TLS offload) to AWS
- "Full control over key hierarchy, algorithms, and key export" — KMS keys can't leave KMS, CloudHSM keys can
Not this service
- Managed encryption integrated with AWS services (S3, EBS, RDS) → KMS
- Storing/rotating passwords, API keys, DB credentials → Secrets Manager
- Payment PIN/card workloads → AWS Payment Cryptography
Use cases
- A bank's contract says the cloud provider must never be able to read signing keys — CloudHSM's tamper-resistant hardware makes that a hardware guarantee, not a policy promise
- Lifting an on-prem PKCS#11 application (document signing, certificate authority) to AWS without rewriting its crypto layer
- Oracle database TDE where the compliance team requires master keys in a dedicated HSM, not shared infrastructure
- KMS custom key store: keep the convenience of KMS envelope encryption while auditors get their dedicated-hardware checkbox
- Monthly code-signing ceremony: spin HSMs up from backup, sign, delete them — pay only for the hours used
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Directory Service
Managed Microsoft Active Directory options in AWS — run a real AD in the cloud, or proxy to the one you already have.
- Three flavors: AWS Managed Microsoft AD (real Windows AD in AWS), AD Connector (proxy to on-prem AD, caches nothing), Simple AD (cheap Samba-based AD-compatible)
- Managed Microsoft AD: actual Windows Server AD, two DCs across two AZs, supports trusts, MFA, schema extensions, seamless EC2 domain join, RDS for SQL Server
- Managed Microsoft AD editions: Standard (~30,000 objects) vs Enterprise (~500,000 objects + multi-Region replication)
- AD Connector: identities stay on-prem, needs VPN or Direct Connect back to your AD — no trusts, no standalone directory
- Simple AD: ≤5,000 users, no trusts, no MFA — and AWS closed it to new customers, though exams still treat it as a live option
Exam triggers
Phrases and scenarios that point here.
- "Existing on-premises AD" + "don't want directory data in the cloud" → AD Connector
- "AD-aware workloads on AWS" (SharePoint, SQL Server, .NET) or "trust relationship with on-prem AD" → AWS Managed Microsoft AD
- "Lowest cost", "basic AD features", "under 5,000 users", no trust/MFA needs → Simple AD
- MFA with corporate credentials for WorkSpaces/AWS apps → Managed Microsoft AD or AD Connector (RADIUS), never Simple AD
Not this service
- Single sign-on into AWS accounts and SaaS apps → IAM Identity Center (it can *use* Directory Service as its identity source, but it's the SSO layer, not the directory)
- Sign-up/sign-in for your own web or mobile app's customers → Amazon Cognito
- Fine-grained permissions to AWS APIs and resources → IAM
Use cases
- Lifting SharePoint or a legacy .NET intranet into AWS without rebuilding auth — Managed Microsoft AD gives it the same domain it had in the server room
- A company rolling out WorkSpaces for 2,000 staff who already log in via corporate AD — AD Connector lets them keep one password and zero cloud-side directory
- Joining fleets of EC2 Windows instances to a domain so group policies apply the moment they boot, instead of hand-configuring each box
- Two-way trust between on-prem AD and Managed Microsoft AD, so cloud resources authenticate corporate users without migrating or syncing a single account
- Enabling Windows Authentication on RDS for SQL Server — one of the exam's favorite Managed-Microsoft-AD-only tricks
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS Firewall Manager
Central control plane that pushes firewall and DDoS protections across every account in your organization.
- Not a firewall itself — it deploys and enforces WAF, Shield Advanced, Network Firewall, DNS Firewall, security groups and NACLs
- Prerequisites: AWS Organizations with all features, a designated Firewall Manager admin account, AWS Config on in every account
- Policies auto-apply to new accounts and new resources in scope — scope by account, OU, resource type, or tag
- Policies are per-Region (CloudFront uses Global); audit mode reports violations, remediation mode fixes them automatically
Exam triggers
Phrases and scenarios that point here.
- "Centrally", "across all accounts", "organization-wide" + firewall or DDoS → Firewall Manager
- Protection must apply automatically to accounts and resources created in the future
- Find and fix security groups left open to 0.0.0.0/0 across the whole org
- Turn on Shield Advanced for every account in the organization in one action
Not this service
- Writing rules for one app in one account → AWS WAF, Shield, or Network Firewall directly
- Org-wide compliance across all resource types, not just firewalls → AWS Config + Security Hub
Use cases
- A security team with 40 accounts wants every internet-facing ALB behind the same managed rule baseline — without asking 40 app teams to do it
- New accounts get spun up weekly by different teams; the WAF and DNS Firewall policies land the moment an account joins the OU
- Auditing every security group for SSH open to the internet in report-only mode first, then flipping the same policy to auto-remediate
- Rolling Shield Advanced across all production accounts ahead of a launch, instead of subscribing resources one at a time
- Letting app teams add their own WAF rules in the middle of a web ACL while the security team's rules stay pinned first and last
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS IAM
Global service controlling who (identities) can do what (policies) on which AWS resources.
- Global, not regional — users, roles, and policies exist once per account and apply everywhere
- Identities: users (people), groups (bundles of users), roles (temporary credentials assumed by anyone/anything)
- Policies are JSON documents; evaluation rule: explicit deny > explicit allow > implicit deny (default)
- Roles > access keys — services (EC2, Lambda) assume roles for temporary credentials, never store keys on instances
- Root user: full unrestricted access; lock it down with MFA and never use it for daily work
Exam triggers
Phrases and scenarios that point here.
- "Grant EC2/Lambda access to S3" → IAM role attached to the service, never access keys in code
- "Cross-account access" → role in the target account, trust policy allowing the source account to assume it
- "Temporary credentials" or "federated access" → roles via STS, not new IAM users
- "Least privilege" → start from nothing, grant only required actions
- "Enforce MFA" / "password policy" → IAM account settings, condition keys like aws:MultiFactorAuthPresent
Not this service
- Workforce SSO across many accounts → IAM Identity Center
- Customer-facing app sign-ups and logins → Amazon Cognito
- Managed Microsoft AD → AWS Directory Service
Use cases
- A deploy pipeline assumes a short-lived role to push to production instead of a shared 'ci-user' with permanent keys sitting in a config file
- A reporting Lambda in the analytics account assumes a read-only role in the production account to pull billing data — cross-account without credential sharing
- New hires land in a 'developers' group and instantly inherit the team's permissions; offboarding is one group removal, not a policy audit
- An EC2 instance profile grants a web server write access to exactly one S3 bucket — a leaked server can't touch anything else
- Permissions boundary on a sandbox role lets junior engineers create resources freely but caps what any role they create can ever do
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS IAM Identity Center
Centralized workforce sign-on: one login, one identity source, access to all AWS accounts and apps in your organization.
- Formerly AWS SSO (renamed 2022) — CLI commands, API namespaces, and console URLs still say `sso`
- Deployed in the AWS Organizations management account; permission sets are provisioned into member accounts as IAM roles
- Identity source options: built-in directory, Active Directory, or external IdP (Entra ID, Okta) via SAML 2.0 + SCIM sync — one identity source per organization
- Users sign in once at the AWS access portal and see every account and app assigned to them
Exam triggers
Phrases and scenarios that point here.
- "Single sign-on across multiple AWS accounts" → Identity Center, not IAM users per account
- "Centrally manage workforce access" with AWS Organizations in the question → Identity Center
- "Connect existing corporate directory / Active Directory for AWS access" → Identity Center with AD or external IdP
- "Temporary credentials, no long-lived access keys for employees" → Identity Center permission sets
Not this service
- Customer-facing app logins (sign-up/sign-in for your users) → Amazon Cognito
- Fine-grained policies, roles, and service permissions inside one account → IAM
- Running an actual Microsoft AD in the cloud → AWS Directory Service
Use cases
- New hire joins the platform team: add them to one group in your IdP, and SCIM sync plus group assignments give them dev access in three accounts by lunch — no per-account IAM user creation
- Replacing the spreadsheet of shared IAM access keys: everyone signs in through the access portal and gets short-lived credentials, so offboarding is deleting one user, not hunting keys across 12 accounts
- Standardizing job-function access: define an 'auditor' permission set once, provision it to every account, and every auditor gets identical read-only access everywhere
- CLI and IDE access without stored keys: `aws configure sso` gives engineers temporary credentials tied to their real identity, so CloudTrail shows who did what
- One federation point for AWS managed apps (Amazon Q Developer, Redshift, QuickSight) instead of wiring your IdP to each app separately
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS KMS
Managed service for creating and controlling encryption keys used across AWS services and your own apps.
- Keys never leave KMS unencrypted — you send data to the key, not the key to your data
- Direct Encrypt/Decrypt caps at 4 KB; anything bigger uses envelope encryption (KMS encrypts a data key, the data key encrypts your data)
- Three key types: AWS owned (invisible, free), AWS managed (aws/service, free storage), customer managed (you control policy, rotation, deletion)
- Regional service — keys don't cross Regions; multi-region keys are replicas billed separately
- Deletion is never instant: 7–30 day mandatory waiting period, and a deleted key means permanently unreadable data
- Every key use is logged in CloudTrail — this is the audit answer, not an add-on
Exam triggers
Phrases and scenarios that point here.
- "Encryption at rest", "manage encryption keys", "control who can decrypt" → KMS
- "Encrypt data larger than 4 KB" → envelope encryption with data keys, not direct Encrypt
- "Audit key usage" → KMS + CloudTrail
- Compliance requires customer-controlled keys → customer managed key, not AWS managed
- "Dedicated single-tenant hardware" / FIPS 140-2 Level 3 → CloudHSM (or KMS custom key store), not plain KMS
Not this service
- Storing/rotating database passwords or API keys → Secrets Manager
- Dedicated single-tenant HSM you fully control → CloudHSM
- SSL/TLS certificates for load balancers and CloudFront → ACM
Use cases
- One customer managed key per environment (prod/staging) so a leaked staging credential can never decrypt production S3 objects
- Cross-account key policy letting an analytics account decrypt a data lake bucket without copying data or sharing credentials
- Envelope encryption in an app storing signed contracts — KMS wraps one data key per document, so revoking the KMS key revokes everything at once
- Meeting an auditor's 'prove who decrypted customer records and when' requirement purely from CloudTrail KMS events
- Disabling (not deleting) a key during an incident to instantly cut off all decryption while keeping the option to recover
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Resource Access Manager
Share resources you own with other AWS accounts instead of building a copy in each one.
- Create once, share many — the owning account keeps full ownership and control, consumers just get access
- A resource share = the resources + the principals (accounts, OUs, whole org, some IAM roles/users) + a managed permission
- Inside your organization sharing is automatic once enabled; outside it, the other account must accept an invitation
- Limits: shares are Region-scoped (global resources live in us-east-1); subnets share only inside your own org, and default subnets can't be shared at all
Exam triggers
Phrases and scenarios that point here.
- "Share across accounts", "without duplicating resources", "centrally managed", "create once, use everywhere"
- Many accounts need to launch into one central VPC → RAM-shared subnets, not a VPC per account
- One Transit Gateway, Resolver rule, or private CA used org-wide → RAM
- Sharing with an account outside the organization → invitation must be accepted first
Not this service
- Grouping accounts, consolidated billing, SCP guardrails → AWS Organizations
- Letting a person or app in another account act with your permissions → IAM cross-account role + STS
Use cases
- A central networking account owns the VPC and shares subnets — each app team launches EC2, RDS, and Lambda from their own account into one VPC the network team patches once
- One Transit Gateway shared org-wide, so a brand-new account gets on-prem and inter-VPC connectivity on day one without its own VPN or Direct Connect
- Route 53 Resolver rules shared from a DNS account, so every account resolves internal hostnames the same way instead of each keeping a copy that quietly drifts
- A private CA in the security account shared to app accounts, so teams issue their own internal TLS certs without anyone passing around root key access
- EC2 Capacity Reservations or Dedicated Hosts bought in one account and shared, so whichever team needs the capacity this week can actually launch into it
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS Secrets Manager
Managed storage and automatic rotation for credentials, API keys, and other secrets.
- Secrets encrypted at rest with KMS (default aws/secretsmanager key or your own CMK) — never stored or returned in plaintext at rest
- Automatic rotation via Lambda; managed rotation templates exist for RDS, Redshift, and DocumentDB — anything else needs a custom rotation function
- Versioning with staging labels (AWSCURRENT / AWSPENDING / AWSPREVIOUS) so apps never read a half-rotated credential
- Limits: 64 KB max secret size, 500,000 secrets per Region per account, cross-Region replication supported
Exam triggers
Phrases and scenarios that point here.
- "Automatic rotation", "rotate database credentials" → Secrets Manager, full stop — Parameter Store can't rotate natively
- "Hardcoded credentials in code / config files" → move them to Secrets Manager, retrieve at runtime via IAM
- "Share credentials across accounts" → Secrets Manager resource policy + KMS CMK (the default key can't cross accounts)
- Free option acceptable + no rotation needed → Parameter Store Standard tier, not Secrets Manager
Not this service
- Static config values, feature flags, plain parameters → SSM Parameter Store (Standard tier is free)
- Managing the encryption keys themselves → KMS
- Certificates for load balancers / CloudFront → ACM
Use cases
- Rotating an RDS password every 30 days without a deploy — the app fetches the secret at runtime, so the credential changes and nothing ships
- Killing the .env file: a Lambda or ECS task pulls its third-party API keys at startup via IAM role instead of baked-in environment secrets
- One database secret shared by staging services across two accounts through a resource policy, instead of copy-pasting the password into both
- Cross-Region replication of secrets so a DR failover in the second Region starts with working credentials, not a manual re-entry step
- Storing a full DB connection bundle (host, port, user, password) as one JSON secret so rotation updates everything atomically
Commonly confused with
Verified against AWS documentation · 2026-08-27
AWS Security Hub
Central dashboard that aggregates security findings from AWS services and runs automated compliance checks against security standards.
- Aggregator, not a detector — it collects findings from GuardDuty, Inspector, Macie, and partner tools into one place
- Runs continuous automated checks against standards: AWS Foundational Security Best Practices, CIS, PCI DSS, NIST
- All findings normalized into one JSON schema: AWS Security Finding Format (ASFF)
- Regional service — enable per Region, but a designated aggregation Region can consolidate cross-Region and cross-account (Organizations) findings
- Requires AWS Config running — security checks are built on Config's recorded resource state
- Naming update: AWS now calls this 'Security Hub CSPM'; exams still say 'Security Hub'
Exam triggers
Phrases and scenarios that point here.
- "Single pane of glass" / "centralize security findings across accounts" → Security Hub
- "Check compliance against CIS / PCI DSS benchmarks automatically" → Security Hub standards
- Automated remediation of findings → Security Hub + EventBridge + Lambda/SSM Automation
- Aggregate GuardDuty + Inspector + Macie results → Security Hub, not any single one of them
Not this service
- Detect actual threats (malware, compromised credentials, crypto mining) → GuardDuty
- Scan EC2/containers for software vulnerabilities → Inspector
- Find sensitive data in S3 → Macie
- Audit who did what via API history → CloudTrail
- Central security incident investigation across accounts → Detective
Use cases
- A company with 40 accounts in Organizations pipes every GuardDuty and Inspector finding into one delegated admin account, so the two-person security team stops logging into accounts one by one
- Proving PCI DSS posture to an auditor with a live compliance score per control instead of a quarterly spreadsheet exercise
- Auto-remediation loop: a public S3 bucket finding fires an EventBridge rule that triggers a Lambda to block public access and post to Slack — no human in the path
- New-account guardrail: every account vended by the platform team gets Security Hub + FSBP standard enabled by default, so misconfigurations surface on day one, not at audit time
Commonly confused with
Verified against AWS documentation · 2026-08-26
AWS Shield
Managed DDoS protection for AWS applications — Standard is free and always on, Advanced is a paid subscription with expert support.
- Standard: free, automatic, every AWS customer — nothing to enable, defends layer 3/4 (network and transport) attacks
- Advanced: paid subscription — adds layer 7 (application) protection via AWS WAF, 24/7 Shield Response Team, and DDoS cost protection
- Advanced protects a fixed list: CloudFront, Route 53, Global Accelerator, ELB, and EC2 — that's the whole list
- SRT engagement requires a Business or Enterprise Support plan on top of the Advanced subscription
- Reality check: AWS now markets Shield as two capabilities — Shield Advanced and network security director (posture analysis, still in preview). CLF-C02 only tests Standard vs. Advanced.
Exam triggers
Phrases and scenarios that point here.
- "DDoS", "flood of traffic", "layer 3/4 attack", "protect availability" → Shield
- "Already included", "no additional cost", "automatic" → Shield Standard (Advanced is the trap answer)
- "24/7 expert help during an attack" or "credits for attack-driven scaling costs" → Shield Advanced
- SQL injection, XSS, bad bots, block by IP or country → AWS WAF, not Shield
Not this service
- Blocking malicious request content — SQLi, XSS, rate limiting → AWS WAF
- Detecting compromised instances or unusual API activity → GuardDuty
- Filtering traffic inside your VPC at subnet or instance level → security groups, NACLs, Network Firewall
Use cases
- A ticketing site on sale day — Standard already absorbs SYN floods and reflection attacks at the edge, and nobody on the team ever knew it happened
- A gaming company whose tournament weekends attract paid DDoS-for-hire from rivals — Advanced with the SRT pre-authorized and on standby
- A lender behind CloudFront + WAF hit by a layer 7 flood of expensive search queries, where the damage lands on Lambda and RDS bills rather than bandwidth — Advanced's automatic L7 mitigation
- A news site during a breaking story, where a legitimate traffic spike and an attack look identical — Advanced's attack diagnostics tell you which one you're having before you scale into it
- Any public endpoint fronted by Auto Scaling — Advanced's cost protection is the difference between a bad afternoon and a five-figure surprise invoice
Commonly confused with
Verified against AWS documentation · 2026-09-09
AWS STS
Issues temporary, limited-privilege credentials so nobody has to hold long-term keys.
- Returns three things: access key ID, secret access key, session token — all requests using them must include the session token
- AssumeRole: default 1 hour, up to 12 hours depending on the role's max session duration setting
- Role chaining (assumed role assumes another role) is hard-capped at 1 hour — not configurable
- Once issued, credentials cannot be revoked — but permissions are re-evaluated on every request, so changing the role's policy effectively cuts them off
- Global endpoint (sts.amazonaws.com) by default; regional endpoints exist and AWS recommends them for lower latency and resilience
- Temporary access keys start with ASIA; long-term IAM user keys start with AKIA
Exam triggers
Phrases and scenarios that point here.
- "Temporary credentials", "short-lived access", "no long-term keys" → STS
- Cross-account access → role in target account + AssumeRole, never a duplicate IAM user
- Corporate directory / SAML login to AWS → AssumeRoleWithSAML
- Mobile app users via Google/Facebook/Cognito → AssumeRoleWithWebIdentity
- Third party assuming a role in your account → require ExternalId (confused deputy defense)
- "Who am I authenticated as?" in a script → GetCallerIdentity
Not this service
- Defining users, roles, and policies themselves → IAM (STS only vends credentials against them)
- Full user directory with sign-up/sign-in for your app → Amazon Cognito
- Centralized workforce access across many accounts → IAM Identity Center
Use cases
- Cross-account access: an auditor or partner assumes a role in your account instead of you creating and babysitting an IAM user for them — like a visitor badge that expires at the end of the day
- CI/CD pipelines (Jenkins, GitHub Actions) assuming a deploy role per run, so no permanent keys sit in pipeline config waiting to leak
- EC2 instance profiles, ECS task roles, and Lambda execution roles — all of these are STS under the hood, auto-refreshing credentials so your code never touches a key file
- Federating an existing corporate directory into AWS via SAML, so employees use one login and zero IAM users get created
- MFA-protected CLI sessions: GetSessionToken with an MFA code before sensitive operations
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS WAF
Layer 7 firewall that inspects and filters HTTP(S) requests before they reach CloudFront, ALB, or API Gateway.
- A web ACL holds your rules, evaluated in priority order — first match wins, and a default action (allow or block) catches everything else
- Attaches to CloudFront, ALB, API Gateway REST, AppSync, Cognito user pools, App Runner, Amplify, Verified Access — never directly to an EC2 instance
- AWS Managed Rules cover the common attacks out of the box (SQLi, XSS, known-bad inputs, bad IP reputation) — writing rules from scratch is the exception
- Rate-based rules count requests per IP over a 1- or 5-minute window; Count mode lets you dry-run a rule in production before it blocks anyone
- Naming note: the new AWS WAF console calls a web ACL a "protection pack" — the exam still says web ACL
Exam triggers
Phrases and scenarios that point here.
- "SQL injection", "cross-site scripting", "OWASP Top 10", "common web exploits" → WAF
- "Block requests from specific countries or IP ranges" → WAF geo-match rule or IP set
- "Layer 7", "HTTP flood", "filter requests before they reach the application" → WAF, not Shield and not security groups
- "Throttle requests to the login page" / "limit requests per IP" → rate-based rule
Not this service
- Network/transport layer (L3/L4) DDoS protection → Shield (Standard is automatic and free; Advanced adds the response team and cost protection)
- Filtering by IP and port at the instance or subnet level → security groups and network ACLs
- Inspecting all VPC traffic, not just HTTP → Network Firewall
- Pushing one firewall policy across every account and every new resource → Firewall Manager
Use cases
- Shielding a legacy app you can't safely patch — WAF blocks SQLi and XSS at the edge while the real fix works its way through the release cycle
- Geo-blocking for a regional business: a store that only ships to two countries drops everything else at CloudFront, shrinking both attack surface and origin load
- Rate-limiting login and password-reset endpoints so credential-stuffing bots get throttled per IP without a single line of application code changing
- Stopping competitor scraping on a listings site (jobs, property, tickets) — Bot Control plus a CAPTCHA action on the search endpoint
- Incident response: add an IP set to the existing web ACL and block a hostile range in minutes, no deployment required
Commonly confused with
Verified against AWS documentation · 2026-09-09