SCS-C03 Cheat Sheet

GuardDuty detects threats from activity, Macie discovers sensitive data in S3, Security Hub aggregates findings and grades posture, Security Lake centralizes raw logs, Detective investigates a finding, and Config tracks resource compliance. Each does exactly one job, so a question stem that describes a job points to one service. Match the symptom in the stem to the job rather than recalling marketing names, and the lookalike answers fall away.

Trap Picking Security Hub when the stem asks to detect a brand-new threat from network or DNS activity; Security Hub only ingests findings others created, it never analyzes that telemetry itself.

GuardDuty analyzes telemetry and produces findings, while Security Hub consumes findings from GuardDuty, Macie, Inspector, and partners into one normalized list and adds control-based posture scores. The exam confuses them because both surface findings, but only GuardDuty creates them from raw activity. Reach for Security Hub when the requirement is a single prioritized view across many accounts plus compliance grading, and GuardDuty when the requirement is finding the threat in the first place.

GuardDuty's foundational data sources are AWS CloudTrail management events, VPC Flow Logs, and Route 53 Resolver DNS query logs; they need no agents, no setup, and carry no extra ingestion cost. CloudTrail S3 data events are not foundational, they are covered only by the optional S3 Protection plan, and other optional plans add EKS Runtime Monitoring, RDS login activity, Lambda network activity, and Malware Protection. Knowing which sources are built in tells you what GuardDuty catches before you enable anything else.

Trap Listing 'CloudTrail management and data events' as foundational; S3 data-event monitoring requires turning on the S3 Protection plan.

Each GuardDuty finding gets a severity value on a 1.0 to 10.0 scale, bucketed as Low 1.0-3.9, Medium 4.0-6.9, High 7.0-8.9, and Critical 9.0-10.0. That number is the field your EventBridge alerting filters on, for example paging only on findings of 7.0 and above. Critical means an attack sequence may be in progress, so it is the band you wire to immediate response rather than a daily digest.

Macie scans Amazon S3 objects and raises sensitive-data findings when it matches managed or custom data identifiers for PII, credentials, and financial data, plus policy findings when a bucket's settings weaken. It does not scan databases, EBS volumes, or network traffic, and it does not detect threats. When a scenario is 'where is our regulated data sitting,' that is Macie; when it is 'is someone attacking us,' that is GuardDuty.

Trap Choosing Macie to scan an RDS database or EBS volume for sensitive data; Macie's discovery is scoped to S3 objects.

Macie sends findings to Security Hub through a native integration and, separately, to EventBridge as its own destination; the Security Hub delivery does not route through EventBridge. By default only new and updated policy findings are published to Security Hub, while sensitive-data findings must be opted in through the publication settings. So if sensitive-data findings are missing from Security Hub, the fix is the publication setting, not an EventBridge rule.

Trap Assuming sensitive-data findings reach Security Hub automatically; only policy findings do by default, sensitive-data findings need opt-in.

Security Hub runs security controls grouped into standards such as the AWS Foundational Security Best Practices (FSBP) and CIS, producing a posture score per account on top of the findings it aggregates. The recommended configuration enables FSBP and all of its controls, including new ones as they ship. When a question wants continuous benchmarking of accounts against a best-practice standard, that scoring is Security Hub's job, distinct from GuardDuty's threat findings.

Detective is the investigation layer, not a detector: it pulls CloudTrail, VPC Flow Logs, and GuardDuty findings into a behavior graph using machine learning and graph analysis so an analyst can trace root cause and blast radius across up to about a year of history. You open it after a finding fires to answer 'what else did this principal touch.' It does not create findings and it is not a place to run ad-hoc SQL over raw logs.

Trap Treating Detective as a detector that raises its own findings; it visualizes and correlates existing telemetry, it does not generate findings.

Detection services do not notify anyone on their own; a finding is published to the default EventBridge bus, an EventBridge rule matches it by source and a field like severity, and targets such as SNS, Lambda, or Step Functions carry out notification or automated response. Build the alerting once at the EventBridge layer and every detector inherits it. A rule filtering severity at 7.0 and above, for instance, pages on-call only for High and Critical GuardDuty findings.

Trap Wiring each detection service to its own SNS topic separately; the reusable pattern centralizes matching in one EventBridge rule that all detectors feed.

An EventBridge archive captures matching events for later replay, and its retention is configurable in days but defaults to indefinite, not 24 hours. Use it when you need to retain or re-drive detection events rather than just page on them live. The replay lets you reprocess past findings through a new rule or target without the original events being gone.

GuardDuty, Macie, Security Hub, Detective, and Config each let the Organizations management account designate one member as the delegated administrator, which then enables, configures, and views findings for every member across Regions from one place. AWS guidance, and the exam answer, is to put that role in a dedicated security or audit account, not the management account, keeping detection authority separate from billing and account creation. This is how you avoid logging into hundreds of accounts to see findings.

Trap Making the Organizations management account the delegated administrator for detection; best practice delegates to a separate security account.

After integrating Security Hub with AWS Organizations, the delegated admin uses central configuration to write configuration policies from one home Region that declare whether Security Hub is on and which standards and controls run, taking effect in the home Region and all linked Regions. Targets (an account, OU, or root) are centrally managed, so only the delegated admin can change them, which blocks configuration drift, or self-managed, so the account configures itself per Region. An applied policy always wins over an inherited one.

Trap Expecting a centrally managed account to change its own standards locally; central configuration removes that, only the delegated admin can, which is the point.

In Security Hub central configuration the home Region is both where the delegated admin authors configuration policies and the aggregation Region that receives findings, insights, and data from all linked Regions. Pick it deliberately, because an opt-in Region (any introduced on or after March 20, 2019) cannot be the home Region, though it can be a linked Region. Cross-Region aggregation is what gives you a single multi-Region view of posture.

A conformance pack is a collection of AWS Config rules and remediation actions packaged as a single YAML template, optionally stored as a Systems Manager document, and deployed in one account-and-Region or across the whole organization from the delegated admin. It is how you assess compliance against a baseline like PCI or operational best practices in one deployable entity instead of wiring rules one at a time. Config tracks resource configuration over time; the pack turns that into a graded compliance result.

AWS Config and conformance packs detect and report noncompliant resource configuration, but they do not by themselves keep a setting in place. AWS Systems Manager State Manager enforces a desired configuration on a schedule, reapplying it when something drifts. Reach for State Manager when the requirement is automatic correction of drift rather than a finding that a human or separate remediation must act on.

Trap Expecting an AWS Config rule on its own to fix a drifted setting; a rule evaluates compliance, enforcement comes from a remediation action or State Manager.

Amazon Inspector continuously scans EC2 instances, container images in ECR, and Lambda functions for software vulnerabilities (CVEs) and unintended network exposure, then publishes its findings into Security Hub alongside GuardDuty and Macie. Inspector is the vulnerability detector; Security Hub is where its findings are aggregated and prioritized. When a stem asks which service finds unpatched CVEs on workloads, that is Inspector, with Security Hub as the place you review them.

GuardDuty pushes a brand-new finding (unique finding ID) to EventBridge in near real time, but it aggregates subsequent occurrences of the same finding type into a single event on a notification frequency that defaults to 6 hours (configurable to 15 minutes or 1 hour). Only the administrator account can change this frequency for subsequent occurrences; a member account cannot, and the administrator's setting applies to all member accounts.

Trap Reading EventBridge firing only on a finding's first occurrence as a broken event pattern; it is the default 6-hour aggregation cadence for repeats.

Amazon Detective finding groups examine multiple related GuardDuty findings and the entities involved (such as IPs, users, and resources) that are likely part of the same event, and map the group's tactics, techniques, and procedures (TTPs) to the MITRE ATT&CK framework. A finding group offers a generative-AI natural-language summary of the attack narrative (powered by models on Amazon Bedrock) plus a graph-based visualization showing how the entities connect the findings.

Trap Reaching for a behavior-graph entity profile to see the cross-finding attack chain; the correlated, TTP-mapped view is the finding group, not an individual entity profile.

Security Hub auto-streams every new finding and finding update to EventBridge for automated rules, but to act on only specific findings on demand you create a custom action; when an analyst selects findings (or insight results) and chooses it, Security Hub emits an event carrying the custom action ARN that an EventBridge rule matches to invoke a Lambda or ticketing integration. This is the supported pattern for combining automatic remediation with manual, on-demand routing.

Trap Building a separate console button or polling job for manual routing; the on-demand path is a Security Hub custom action matched by its ARN in an EventBridge rule.

A Security Hub custom insight combines filters on different attributes with AND and filters on the same attribute with OR, so 'Product name is GuardDuty' plus 'Product name is Amazon Inspector' plus 'Resource type is AwsS3Bucket' means (GuardDuty OR Inspector) AND S3. A grouping attribute (such as AwsAccountId or ResourceId) defines the insight result, and the insight spans the home Region and all linked Regions unless you add a Region filter.

Trap Expecting two values of the same attribute to AND together; same-attribute filters OR, so listing two product names widens rather than narrows the insight.

Security Hub cross-Region aggregation is off until you explicitly enable it from the aggregation (home) Region. Setting RegionLinkingMode to ALL_REGIONS aggregates findings from every Region where Security Hub is enabled and automatically aggregates findings from new Regions as Security Hub supports them and you opt into them, which is what satisfies a requirement to include future Regions without reconfiguration.

Trap Listing specific linked Regions (SPECIFIED_REGIONS) when the requirement is to auto-include future ones; only ALL_REGIONS (or ALL_REGIONS_EXCEPT_SPECIFIED) adds new Regions automatically.

AWS structures incident response on the NIST SP 800-61 lifecycle: preparation, then detection and analysis, then containment, eradication, and recovery, then post-incident activity. Preparation is where you stage access, runbooks, tooling, and rehearsals so response is a procedure, not an improvisation. The phases loop, so post-incident lessons feed straight back into preparation.

Incident response needs broader permissions than daily work, so pre-create a dedicated IR IAM role that responders assume only during a declared incident, gated by MFA, a tight trust policy, and full CloudTrail logging. This gives auditable, time-boxed elevation without leaving powerful permissions lying around, and beats writing an emergency policy live under pressure.

Trap Granting responders standing administrator permissions so they are 'ready'; that is permanent excess privilege an attacker can ride, the opposite of least privilege.

Pre-stage a dedicated security or forensic account that is isolated from the workload accounts, and share evidence such as disk snapshots and memory captures into it. An attacker who controls a workload account then cannot reach the responders' tooling or tamper with collected evidence, which also preserves chain of custody because the evidence sits where the suspect identity has no access.

Trap Storing snapshots and analysis tools in the same compromised account; the attacker who owns that account can delete or alter the evidence.

Containment is easier when the architecture already limits how far an incident can spread, so preparation includes multi-account segmentation, scoped IAM, and network isolation boundaries. Consistent resource tagging is part of this because an isolation runbook can then target exactly the tagged in-scope resources instead of guessing.

Turn repeatable response steps such as snapshot a volume, swap an instance's security group, or disable an access key into a Systems Manager Automation runbook (an Automation-type document) that runs identically every time. A runbook can be invoked manually, on a schedule, or by an event, replacing a wiki page a stressed responder would otherwise transcribe by hand.

Systems Manager OpsCenter aggregates and deduplicates operational issues as OpsItems in one console and attaches the relevant Automation runbooks so a responder runs remediation from the item. It is wired to detection: a CloudWatch alarm entering ALARM, or an EventBridge event such as a Security Hub finding, can create an OpsItem automatically, pre-building the path from a finding to a one-click runbook.

Trap Treating OpsCenter as a detector; it organizes and remediates issues that other services detect, it does not generate the findings itself.

When response is more than a linear list, for example branch on whether the instance is production, capture memory only if flagged, or wait for human approval before terminating, orchestrate it as a Step Functions state machine rather than one Lambda. Standard workflows give exactly-once execution and run up to a year, and every state transition is recorded, giving a built-in audit timeline of what the automation did. Reach for a single SSM runbook instead when the flow is short and linear.

Trap Cramming a branching, approval-gated response into one large Lambda function; you lose the auditable per-step timeline and the long-running, exactly-once execution Standard workflows provide.

A finding from GuardDuty or Security Hub publishes to EventBridge, and an EventBridge rule then invokes the response: an SSM Automation runbook for the simple linear case or a Step Functions state machine for the complex one. Pre-building this rule means the response triggers automatically instead of waiting for a human to notice and start it.

A plan you have never executed is only a hypothesis, so rehearse it with a game day: a scheduled, controlled exercise that injects a realistic fault and confirms detection fires, automation runs, and responders follow the runbook. AWS Fault Injection Service (FIS) is the managed way to run these, built on chaos-engineering principles. The distractors here are services that check state rather than test response: Config evaluates configuration, Inspector scans for vulnerabilities, Trusted Advisor checks best practices.

Trap Choosing AWS Config, Inspector, or Trusted Advisor to 'test the incident response plan'; those assess configuration or vulnerabilities, none of them injects a fault to exercise the response.

An AWS FIS experiment template has three parts: actions (the disruption to inject), targets (the resources, selected by tag or state), and stop conditions (CloudWatch alarms that automatically halt and roll back the experiment if it crosses a threshold). The stop condition is the safety guardrail that keeps a controlled experiment from becoming a real outage.

Trap Running a FIS experiment with no stop condition; without the CloudWatch-alarm guardrail there is nothing to auto-halt and roll back the injected fault before it causes a real outage.

FIS performs real actions on real AWS resources, not a simulation, so AWS recommends running a new experiment in a pre-production environment before targeting production. This is why blast-radius controls and stop conditions matter even during a planned test.

Trap Assuming FIS only simulates faults; it injects genuine disruptions on live resources, so an untested experiment aimed straight at production can cause an actual incident.

AWS Resilience Hub evaluates an application against defined resiliency targets (RTO/RPO) and recommends where it is weak and what to test, but it does not itself inject faults. FIS is the service that actually runs the disruptive experiment, so the two pair up: Resilience Hub points at the gap, FIS exercises it.

Trap Picking Resilience Hub as the tool that 'tests by injecting faults'; it assesses and recommends, while FIS is the service that performs the fault injection.

Shield Advanced is a preparation decision for DDoS: it unlocks the AWS Shield Response Team (SRT) and, with proactive engagement enabled, lets the SRT contact your emergency contacts during an attack instead of waiting for you to open a case. Reaching the SRT also requires a Business or Enterprise Support plan, so that support tier is part of the pre-staging. Shield Standard is free and automatic but includes no response team, so the SRT is the differentiator when the question wants expert help available during the event.

Trap Answering Shield Standard or WAF rate-based rules when the stem asks for expert assistance during a DDoS; neither includes the Shield Response Team, which requires Shield Advanced.

Preparation can include deploying the Automated Forensics Orchestrator for Amazon EC2, an AWS solution built on Step Functions that automates isolation, plus memory and disk acquisition into a dedicated forensic account, ready to be triggered by a GuardDuty or Security Hub finding. Standing it up in advance means evidence capture follows a tested, repeatable workflow instead of manual snapshotting during the incident.

The post-incident phase exists to improve future response: a permission you lacked mid-incident becomes a new pre-staged role, and a slow manual step becomes an Automation runbook. Treating the lifecycle as a loop is what turns one painful incident into a stronger plan, rather than repeating the same gaps.

AWS Well-Architected (SEC10) frames the deliverable as an incident response plan plus a runbook for each recognizable scenario, such as an exposed credential or an instance beaconing to a known-bad IP. Scenario-specific runbooks are fast to execute because each one already knows its exact steps, where a single generic document forces decisions during the incident.

Transient failures such as API throttling or downstream network errors can drop automated remediation. Configure the EventBridge rule target with a retry policy (MaximumRetryAttempts / maximum event age) to retry transient failures, and attach an SQS dead-letter queue to capture events that exhaust all retries. DLQ messages carry ERROR_CODE / ERROR_MESSAGE metadata, and a separate consumer can reprocess them — so persistent failures are preserved for investigation rather than lost.

Trap Relying on Lambda's own retries alone: they do not capture events EventBridge could not deliver to the target, which is exactly what the rule-level DLQ preserves.

The console auto-adds the permission, but when you create an EventBridge rule with a Lambda target via CloudFormation, the CLI, or an SDK you must explicitly add a resource-based policy (lambda:AddPermission) on the function allowing the events.amazonaws.com service principal — ideally scoped to the rule ARN as SourceArn. Without it the rule looks correctly configured yet the function is never invoked; CloudWatch FailedInvocations / a DLQ confirm the missed deliveries.

Trap Assuming the Lambda execution role is the problem: the execution role governs what the function can do, while the missing resource-based policy is what blocks EventBridge from invoking it at all.

GuardDuty publishes findings to EventBridge with source 'aws.guardduty' and detail-type 'GuardDuty Finding', and severity is a number from 1.0-10.0 across four tiers: Critical 9.0-10.0, High 7.0-8.9, Medium 4.0-6.9, Low 1.0-3.9. To alert on the top of the range, match detail.severity at or above 7 (which spans High and Critical) — a numeric matcher such as detail.severity {'numeric':['>=',7]} is valid, though AWS examples typically enumerate the values (e.g. [7, 7.0, ... 10.0]). Combine it with a prefix matcher on detail.type (such as 'CryptoCurrency:EC2' or 'UnauthorizedAccess:IAMUser') to target a finding family.

Trap Matching detail.severity against the string 'HIGH': GuardDuty severities are numeric, so a string filter matches nothing and the rule never fires.

Designate a delegated administrator account for GuardDuty in AWS Organizations and findings from every current and future member account are automatically aggregated there and published to the administrator account's default EventBridge event bus. A single EventBridge rule in that account therefore captures organization-wide findings (the accountId field identifies the source) — no per-account event-bus forwarding is needed.

Trap Building per-member-account EventBridge cross-account forwarding rules: the delegated-admin aggregation already centralizes the finding events for you.

Conditional logic in a Systems Manager Automation runbook is implemented with the aws:branch action: it evaluates Choices (commonly StringEquals on a severity input variable) and routes execution to a NextStep, so HIGH findings can disable keys or isolate a resource while MEDIUM/LOW only notify or log. Set isEnd: true on the terminal step of each branch.

Trap Reaching for separate Step Functions states for simple in-runbook branching: aws:branch keeps the conditional severity routing inside one Automation document.

Add the aws:approve action to pause an Automation execution until designated IAM principals approve — the way to gate a production remediation (often combined with aws:branch on an environment tag so non-prod runs straight through). For organization-wide runs, multi-account/multi-Region execution (TargetLocations, aws:executeAutomation) uses MaxConcurrency to limit parallel targets and MaxErrors (a count or percentage) to stop the automation once failures exceed the threshold.

Trap Hard-coding a wait or a Lambda poll for approval: aws:approve is the built-in Automation action that suspends the run for named approvers.

An internet-facing app gets layered protection where each control works at a different OSI layer: CloudFront terminates TLS and caches, AWS WAF inspects HTTP/HTTPS requests for application-layer attacks, and AWS Shield absorbs L3/L4 DDoS floods. They stack on the same edge resource rather than compete, so one CloudFront distribution can carry both a WAF web ACL and Shield at once. Match the control to the layer the attack targets: a volumetric flood is absorption (Shield), a crafted request is inspection (WAF).

Trap Reaching for a security group or NACL to stop an OWASP-style web attack; those filter at L3/L4 inside the VPC and never inspect HTTP request content the way a WAF web ACL does.

AWS WAF defends against the OWASP Top 10 web risks (injection, broken access control, and the rest) through AWS Managed Rules, pre-built rule groups you enable instead of hand-writing signatures. The baseline Core rule set (CRS, AWSManagedRulesCommonRuleSet) covers the broad common attacks, while Known bad inputs and the SQL database group target specific classes. Managed groups are maintained by AWS and updated as new threats emerge, so they are the first reach for generic web protection.

Trap Writing custom string/regex rules to reproduce SQL-injection or XSS protection AWS already ships; the AWS managed Core rule set and SQL database group cover the OWASP classes and stay maintained for you.

A web ACL runs its rules from lowest to highest priority number and stops at the first rule whose action terminates evaluation. Each rule action is Allow, Block, Count, or Captcha/Challenge: Allow and Block are terminating, Count only tallies and lets evaluation continue (the safe tuning mode), and Challenge issues a token-backed test. If no rule matches, the web ACL's default action (Allow or Block) decides.

Trap Assuming Count blocks traffic; Count is observe-only, used to test a rule's match volume before switching it to Block, so a rule left on Count stops nothing.

A WAF rate-based rule counts requests per aggregation key over a trailing evaluation window of 60, 120, 300, or 600 seconds, defaulting to 300 (5 minutes), and acts on a key once it exceeds the limit. The lowest rate limit you can set is 10 requests, and WAF looks back over the window continuously rather than resetting on a fixed schedule. This is the standard defense against HTTP floods and brute-force bursts when no signature matches.

Trap Treating the evaluation window as a fixed bucket that resets every N seconds; WAF re-estimates the rate frequently over a rolling look-back, so a client cannot dodge it by timing requests to a window boundary.

A rate-based rule aggregates by source IP by default, but you can aggregate by an IP pulled from a forwarded header such as X-Forwarded-For (use this when CloudFront or a proxy fronts the app so the real client IP survives), or by custom keys built from headers, cookies, or query strings. Custom-key aggregation is the "client fingerprinting" the blueprint names: it lets you rate-limit per session token or per API key rather than per IP.

Trap Aggregating on source IP alone behind CloudFront, which collapses many clients onto the CDN's edge IPs; use IP-in-header (X-Forwarded-For) so the rate limit tracks the true viewer.

A geo-match statement blocks or allows requests by country code (CountryCodes), and an IP set is a reusable list of CIDR ranges a rule references to allow trusted sources or block known-bad ones. Both run in the same web ACL as your managed and rate-based rules, so you enforce geography and IP allow/deny lists at the edge before traffic reaches the origin. Geo-match reads the request's resolved country, not a self-declared header.

Trap Believing geo-match guarantees a user's location; it maps the connecting IP to a country, so a VPN or proxy in another country defeats it, making geo-blocking a coarse control rather than strong access enforcement.

A matching WAF rule can attach a label to the request instead of terminating, and a downstream rule can match that label to make a combined decision. This builds staged logic, for example letting the Bot Control group label a request as a verified or known bot, then a later rule decides whether that bot category is permitted. Labels turn a flat rule list into composable detection without duplicating match conditions.

Most AWS managed rule groups are free with WAF, but the intelligent threat mitigation tier carries additional fees because it fingerprints and challenges clients rather than matching signatures: Bot Control (automated traffic), account takeover prevention (ATP, credential-stuffing on login), and account creation fraud prevention (ACFP, fake-signup abuse). Reach for these when the threat is automation or credential abuse, not a payload pattern, and budget for the extra cost.

Trap Assuming every AWS managed rule group is free; Bot Control, ATP, and ACFP add per-request fees on top of base WAF charges, so enabling them blindly can surprise the bill.

Beyond Allow/Block/Count, WAF offers Captcha and Challenge actions that interrupt a suspicious request and require the client to prove it is a real browser. Captcha shows a puzzle to a human; Challenge runs a silent background check (a token-backed JavaScript challenge) with no user interaction. Both issue a token the client presents on later requests, which is why they pair with Bot Control to slow automated clients without blocking legitimate users outright.

AWS Shield Standard protects every customer at no cost and with no configuration, defending against the common, most frequent network and transport-layer (L3/L4) DDoS attacks. It applies automatically to CloudFront, Amazon Route 53, and AWS Global Accelerator, so an app fronted by CloudFront already has baseline DDoS coverage. Standard does not include the Shield Response Team, attack diagnostics, or cost protection.

Shield Advanced is a paid subscription priced at $3,000 per month per payer account in an AWS Organization, with a 1-year commitment, plus data-transfer-out fees for protected resources. Because the fee is per payer (the management/consolidated-billing account), you subscribe once and it is not multiplied across every member account under that payer. The cost is the same whether you protect one resource or many.

Trap Reading the price as $3,000 per organization or per protected resource; it is $3,000 per month per payer account, so consolidating accounts under one payer is what keeps the fee from multiplying.

Shield Advanced adds four things Standard lacks: 24/7 access to the Shield Response Team (SRT) for help during an active attack, near-real-time attack diagnostics and metrics, automatic application-layer DDoS mitigation where Shield deploys WAF rules on your behalf, and DDoS cost protection that refunds the scaling charges (extra data transfer, ALB capacity, EC2 scale-out) caused by a covered attack. It also extends coverage to Elastic IPs, ALB, CLB, and Route 53 hosted zones.

Trap Picking Shield Standard when the scenario needs human support during an attack or a refund for attack-driven scaling bills; only Advanced includes the SRT and DDoS cost protection.

AWS renamed the DDoS Response Team to the Shield Response Team (SRT), the experts a Shield Advanced subscriber can engage 24/7 during a DDoS event. Use SRT in current content; the old DRT name is retired and a distractor that says DRT is using stale terminology.

OAC signs each request CloudFront sends to an S3 origin with SigV4, and the bucket policy then permits only that distribution and denies direct access, so an attacker cannot bypass WAF by hitting the bucket URL. OAC is the current mechanism and supersedes the legacy origin access identity (OAI); unlike OAI it supports SSE-KMS encrypted objects and all Regions. Without it, a public bucket lets traffic skip the entire edge stack.

Trap Using the legacy origin access identity (OAI) for a new distribution serving SSE-KMS objects; OAI does not support KMS-encrypted origins, so OAC is the correct current choice.

A CloudFront response headers policy attaches security headers to every response without changing the origin: HSTS to force HTTPS, X-Content-Type-Options: nosniff to stop MIME sniffing, X-Frame-Options to block clickjacking, and a Content-Security-Policy. Centralizing them at the distribution means one policy hardens the browser side across all origins behind it, rather than re-implementing headers on each backend.

Cross-origin resource sharing (CORS) on an S3 bucket tells the browser which other origins may read responses via JavaScript, configured through AllowedOrigins, AllowedMethods, and AllowedHeaders. It only relaxes the browser's same-origin policy for the origins you list and grants no AWS-level access, so it never replaces IAM or a bucket policy. A wildcard * origin is a misconfiguration finding, not a convenience.

Trap Treating CORS as an access-control or authorization mechanism; it is a browser-side read-permission hint, so loosening it to * exposes responses to any site's scripts without changing who can authenticate to the bucket.

Amazon Security Lake centralizes security data, including AWS WAF logs, into a data lake in your own S3 and converts it to the Open Cybersecurity Schema Framework (OCSF) stored as Apache Parquet. OCSF is a vendor-neutral schema, so a third-party SIEM queries one normalized format and correlates a WAF block with a VPC Flow Log or CloudTrail event by shared field names. Subscribers read the data through Athena, Redshift, or Lake Formation rather than parsing each source's native log shape.

Trap Building a custom ETL pipeline to merge findings from many AWS and third-party tools into one schema; Security Lake already normalizes to OCSF in Parquet, which is the intended answer for unified, queryable security data.

You do not have to author every WAF rule: the AWS Marketplace offers managed rule groups from third-party vendors (such as F5, Fortinet, Imperva) that you subscribe to and reference in a web ACL exactly like an AWS managed group. They evaluate in priority order alongside AWS groups and your custom rules, so you can combine a vendor's specialized signatures with the AWS Core rule set in one policy.

Trap Re-implementing a commercial vendor's WAF signatures as custom AWS rules; subscribing to that vendor's Marketplace managed rule group is the supported path and keeps the signatures vendor-maintained.

AWS WAF is a web application firewall: it only inspects layer-7 HTTP and HTTPS requests on the resources a web ACL attaches to (CloudFront, ALB, API Gateway, AppSync). Raw TCP/UDP services, or attacks below L7, fall outside WAF entirely and rely on Shield for DDoS plus VPC controls like security groups and Network Firewall. Knowing this boundary keeps you from proposing a web ACL for a non-HTTP workload.

Trap Proposing a WAF web ACL to protect a non-HTTP service (such as a custom TCP listener on an NLB); WAF inspects only HTTP/HTTPS, so that traffic needs Shield and VPC-layer controls instead.

A WAF web ACL associates with CloudFront distributions (global scope), or with regional resources: an Application Load Balancer, an Amazon API Gateway stage, an AWS AppSync GraphQL API, a Cognito user pool, or an App Runner service. CloudFront web ACLs use the CLOUDFRONT scope in us-east-1; regional web ACLs are created in the resource's own Region. Front the app at the outermost internet-facing resource so WAF sees traffic before it fans in.

A Security Lake custom source must deliver OCSF-conformant Apache Parquet objects written under its assigned prefix with the partition layout region=/accountId=/eventDay=/ (eventDay has no separators). This partitioning is what lets the source's Glue crawler register partitions for Athena pruning. Deliver each distinct OCSF event class as its own custom source, and run the source's Glue crawler when the schema gains fields.

Trap Pushing raw JSON or a single mixed-class feed — each OCSF event class needs its own custom source in Parquet with the region/accountId/eventDay partitions.

A data-access subscriber reads OCSF Parquet objects directly from the Security Lake S3 bucket: Security Lake provisions a subscriber IAM role and an SQS queue (or HTTPS endpoint) so the consumer is notified of new objects and assumes the role to read them. You supply the partner account ID and a unique external ID, which Security Lake enforces as an sts:ExternalId condition on every AssumeRole.

Trap Choosing query (Lake Formation/Athena) access when the consumer must read raw S3 objects without Athena — that requires data access, not query access.

When the Security Lake bucket is encrypted with a customer-managed KMS key in the delegated-administrator account, any cross-account principal that reads or writes objects (a subscriber role on GetObject, a Glue crawler, or a collector on PutObject) must be granted kms:Decrypt and kms:GenerateDataKey in that key's policy, not just in its identity policy. ListBucket can succeed while GetObject fails with a KMS AccessDenied when this is missing; the key must be single-Region.

Trap Granting KMS actions only in the reader's identity policy — a cross-account customer-managed key also needs them in the key policy in the source account.

Shield Advanced proactive engagement (and faster health-based detection) requires Amazon Route 53 health checks associated with each protected resource so the Shield Response Team can correlate a detected event with real application impact, plus configured emergency contacts and Business or Enterprise Support. Without the health checks the SRT will not reach out even when proactive engagement is enabled.

Trap Enabling proactive engagement and adding emergency contacts but skipping the Route 53 health-check association the SRT depends on.

CloudFront's built-in geographic restriction (allowlist/blocklist) is the most efficient way to block whole countries because it rejects requests at the edge before they reach AWS WAF, so blocked requests never appear in WAF logs or counts. When you need geo decisions combined with conditions (e.g. restrict only /trading to the US), use a WAF web ACL that ANDs a geo-match statement with a URI-path match instead.

Trap Expecting requests blocked by CloudFront geo restriction to still be logged or counted by WAF — they are dropped before WAF runs.

An AWS Marketplace managed WAF rule-group subscription is scoped to the single account that subscribed, so each account (e.g. production vs sandbox) must subscribe separately before the rule group is selectable. To stop the charges you must remove the rule group from every web ACL and Firewall Manager policy that references it in addition to unsubscribing; pin a managed rule group to a static version so vendor updates require review before taking effect.

Trap Assuming an org-wide or another account's Marketplace subscription carries over, or that unsubscribing alone stops billing while a web ACL still references it.

AWS Firewall Manager is the least-overhead way to enforce a single security policy across all accounts and new resources in an AWS Organization: it can push WAF web ACLs (including AWS and Marketplace managed rule groups), Shield Advanced protections with automatic application-layer mitigation, and Route 53 Resolver DNS Firewall rule groups, auto-remediating onto in-scope and newly created resources.

Trap Scripting per-account web ACLs or rule-group associations for org-wide coverage when a Firewall Manager policy applies and auto-remediates everywhere.

Authentication establishes who a caller is and hands back a credential; authorization is the separate step that evaluates policies against that identity. Keep them apart when reading a stem: a failed sign-in, a federation trust, an MFA prompt, or a credential lifetime is an authentication problem, even if the wrong answers talk about permissions. The fix that issues or validates a credential is the authentication answer.

AWS gives each caller a canonical front door: human workforce uses IAM Identity Center, application and customer end users use Amazon Cognito, and machines or AWS services assume an IAM role and get credentials from STS. Naming the actor in the question normally names the service before any other detail matters, so read for who is signing in first.

IAM Identity Center (the service formerly named AWS SSO) federates your corporate IdP over SAML 2.0 or SCIM and grants access through permission sets, which it materializes as short-lived IAM roles in each account. That replaces creating a long-lived IAM user per employee, the legacy anti-pattern, and gives one sign-on across the whole organization.

Trap Provisioning an IAM user for each employee when the requirement is workforce SSO across many accounts; that is exactly what Identity Center and permission sets exist to avoid.

An organization-wide IAM Identity Center instance always resides in the AWS Organizations management account. You can assign a delegated administrator in a member account for day-to-day work, but that delegated admin cannot modify permission sets provisioned into the management account; only an Identity Center administrator working from the management account can change those.

Trap Assuming a delegated administrator can edit a permission set used for access to the management account; that change is reserved to an Identity Center admin in the management account.

A permission set is a template Identity Center deploys as an IAM role into each assigned account. After you change the permission set, you must re-provision it to those accounts or members keep assuming the stale role. A wave of access errors right after a permission-set edit is a provisioning gap, not a policy bug.

Trap Rewriting the underlying IAM policy to chase access errors that actually came from a permission set that was edited but never re-provisioned.

When you federate straight to IAM, a SAML 2.0 IdP drives sts:AssumeRoleWithSAML with a signed SAML assertion, while an OIDC provider (Google, GitHub Actions, any OIDC-compliant IdP) drives sts:AssumeRoleWithWebIdentity with a JWT. Match the protocol in the stem to the call: assertion means SAML, token means web identity.

Both federation calls are unsigned: the caller presents the SAML assertion or OIDC JWT as the proof of identity, so no pre-existing AWS access key is required to make the request. Plain sts:AssumeRole, by contrast, must be called with active AWS credentials.

Trap Requiring an IAM access key before a web-identity or SAML federation call; the assertion or token itself is the credential, so those calls are unsigned.

A Cognito user pool is a directory and OIDC provider that signs users in and issues JWT tokens. A Cognito identity pool takes a trusted token and exchanges it through STS for temporary AWS credentials so the client calls AWS services directly. Tokens-only is a user pool; needs-AWS-credentials adds an identity pool.

Trap Reaching for an identity pool just to authenticate app users and issue tokens; that is the user pool's job, and the identity pool only enters when the client must call AWS APIs itself.

On sign-in a Cognito user pool returns an ID token and an access token, both JWTs you verify against the pool's public JWKS, plus a refresh token. The refresh token is encrypted and opaque, readable only by the user pool and used only to mint new ID and access tokens, so it is not a JWKS-verifiable JWT.

Trap Treating all three Cognito tokens as JWTs you can verify against the JWKS; the refresh token is opaque and cannot be validated that way.

The ID token carries identity and profile claims and proves who the user is, while the access token carries OAuth scopes and authorizes calls to your API. Send the access token to authorize an API request; use the ID token when you need the user's attributes.

A Cognito identity pool chooses the IAM role two ways: role-based access control (a default authenticated role, a rules-based choice from claims, or a role from user-pool group membership) and attribute-based access control, where it maps claims to STS principal tags so IAM policies filter on aws:PrincipalTag. It can also issue limited credentials to unauthenticated guest identities when enabled.

Long-lived IAM user access keys leak easily and are hard to rotate, so the modern pattern replaces them with credentials that expire on their own: IAM roles plus STS for workloads, federation for workforce, and IAM Roles Anywhere for on-premises servers. The exam consistently rewards the option that removes a static key in favor of an STS-issued session.

Trap Embedding an IAM user access key on an EC2 instance or app server when an attached IAM role would supply auto-rotating temporary credentials with no stored secret.

An sts:AssumeRole session lasts one hour by default; the maximum is set by the role's MaxSessionDuration, which can be raised up to 12 hours. STS always returns an access key, a secret key, and a session token that must accompany every request made with the credentials.

When you use one role's temporary credentials to assume a second role (role chaining), the second session is limited to a maximum of 1 hour, regardless of that role's MaxSessionDuration. If a question needs a longer session, it cannot come from a chained assume-role.

Trap Expecting a chained AssumeRole session to honor a 12-hour MaxSessionDuration; chaining hard-caps the result at 1 hour.

sts:GetSessionToken lets an IAM user trade long-term keys for temporary credentials, optionally carrying MFA state when you pass SerialNumber and TokenCode, which is the standard way to require MFA before MFA-protected CLI or API calls. It defaults to 12 hours and ranges from 15 minutes to 36 hours for an IAM user.

Trap Using AssumeRole to satisfy an MFA-before-CLI requirement for an IAM user; GetSessionToken with SerialNumber and TokenCode is the operation that returns MFA-stamped credentials.

A token issued to the AWS account root user through GetSessionToken or GetFederationToken is restricted to a one-hour duration, even though an IAM user can request up to 36 hours. This is one more reason to avoid using the root user for routine work.

AWS STS is global, like IAM and CloudFront, so a Region-restriction SCP that denies on aws:RequestedRegion must exempt it or it would break authentication everywhere. You should still activate Regional STS endpoints for latency and resilience, but STS calls are not blocked by a data-residency Region deny.

IAM Roles Anywhere lets servers and containers outside AWS obtain temporary STS credentials by presenting an X.509 client certificate issued by a certificate authority you register as a trust anchor. It removes the last common reason to create a long-lived IAM user for an on-premises host.

Trap Creating a long-lived IAM user with static keys for each on-premises server when IAM Roles Anywhere can hand those hosts temporary role credentials from an X.509 trust anchor.

A presigned URL delegates one S3 operation to someone with no AWS account, and it acts with the permissions of the IAM principal who signed it, so it can never grant more access than the signer already has. Anyone holding the URL can use it until it expires, which is why it is treated as a bearer token.

Trap Assuming a presigned URL grants the recipient's own permissions or can exceed the signer's; it inherits exactly the signer's access and nothing more.

Signed with an IAM user's long-term key via the CLI or SDK, a presigned URL can last up to 7 days (the console allows 1 minute to 12 hours). Signed with temporary credentials, it expires when those credentials do, even if you asked for longer, so a URL signed by a default 1-hour role session lasts at most that hour and one from an EC2 instance profile at most its roughly 6-hour rotation.

Trap Setting a 7-day expiry on a presigned URL signed from an assumed role or instance profile and expecting it to last; the temporary credential expires first and the URL dies with it.

CloudTrail records console ConsoleLogin events and STS API calls with the userIdentity element and error fields, so it tells you who failed to authenticate and why, including root-user logins, MFA usage, and source IP. For organization-wide visibility, query an organization trail or CloudTrail Lake across every account.

Trap Reaching for VPC Flow Logs or GuardDuty to find who failed a console login or AssumeRole; the authoritative record of the sign-in event and its error is in CloudTrail.

AWS supports virtual TOTP authenticator apps, FIDO2 security keys and passkeys, and hardware TOTP tokens as MFA factors, and IAM Identity Center and Cognito user pools can require MFA at sign-in. FIDO2 keys and passkeys are the phishing-resistant choice because the credential is bound to the origin and cannot be replayed.

The root user cannot be deleted or scoped down by IAM policy, so the baseline control is to enable a strong MFA device on it, remove any root access keys, and reserve it for the few tasks that require it. Centralized root access for member accounts lets an organization manage member root credentials without each account holding its own.

Trap Trying to restrict the root user with an IAM policy or permission boundary; root is not constrained that way, so MFA plus locking the credentials away is the actual control.

AWS Managed Microsoft AD provides domain join, Kerberos, LDAP, and group policy, and you can establish a forest trust to on-premises AD so users sign in with existing domain credentials; Identity Center can use it as an identity source. Directory authentication failures usually trace to the trust relationship, DNS resolution between directories, or blocked AD ports.

Trap Blaming an IAM policy when domain users cannot authenticate through AWS Managed Microsoft AD; the cause is normally a broken forest trust, DNS, or a security-group rule blocking AD ports.

Secrets Manager single-user rotation changes one database user's password, so there is a short window where the old password is dead before the secret updates — the app must retry (exponential backoff) or stay stale. The alternating-users strategy keeps two users and rotates whichever is idle, so a valid credential is always available for high availability, but it clones a second user and needs a separate superuser secret with privileges to create/clone users.

Trap Reaching for alternating-users behind RDS Proxy, which only supports single-user rotation because the proxy never learns about the cloned user.

The rotation Lambda runs four steps — createSecret, setSecret, testSecret, finishSecret — staging the new value under the AWSPENDING label and moving AWSCURRENT to it only after a successful test. A successful rotation but a still-broken app usually means the app cached the old credentials; an orphaned AWSPENDING label left on a version other than AWSCURRENT makes Secrets Manager think a rotation is still running. For alternating-users, the superuser secret's ARN must be stored inside the rotating secret's JSON so the function can find it.

Trap Assuming a successful rotation with the new password under AWSCURRENT proves the app will reconnect, when the app is caching the old credentials and never refreshed.

When the rotation Lambda runs inside a private VPC with no internet path, it cannot reach the public Secrets Manager endpoint and times out (often at createSecret). Create an interface VPC endpoint for Secrets Manager so it can call the service privately. Alternating-users rotation against an RDS-managed superuser secret also needs an RDS API VPC endpoint, because the function calls the RDS API to fetch connection details.

Trap Blaming security groups or database connectivity for the timeout when the function actually cannot reach the Secrets Manager service endpoint at all.

A trust policy condition on aws:MultiFactorAuthPresent is satisfied only when the caller supplies a fresh MFA serial number and token code in the AssumeRole call; merely having MFA registered on the IAM user is not enough. Temporary credentials minted by a service such as Lambda can never carry an MFA context, so a Lambda execution role can never assume a role whose trust policy requires MFA to be present.

Trap Assuming MFA registered on the IAM user satisfies the condition, when the --serial-number and --token-code must be passed on the AssumeRole request itself.

An 'Invalid SAML response' or 'Invalid Destination' error usually means the IdP's updated metadata was never re-imported into the Cognito user pool, or the Assertion Consumer Service (ACS) URL on the IdP no longer matches the pool's https://.auth..amazoncognito.com/saml2/idpresponse endpoint. The first diagnostic step is to capture the SAML response in the browser, URL- and base64-decode it, and confirm the destination and mapped attributes.

Trap Mapping the SAML NameID to a mutable attribute like email, which spawns a brand-new profile whenever the user's email changes instead of recognizing the returning user.

For Session Manager to write logs to S3 the instance profile needs s3:PutObject, plus s3:GetEncryptionConfiguration whenever 'Enforce S3 log encryption' is on, and s3:PutObjectAcl when the bucket lives in a different account; private-subnet instances also need a network path to S3. Logs never appear for port-forwarding or SSH sessions because that traffic is tunneled and Session Manager cannot capture it.

Trap Expecting logs from an SSH-over-Session-Manager or port-forwarding session, which are tunneled and intentionally not logged.

When Session Manager is set to encrypt session data with a customer managed key, the IAM principal starting the session must hold kms:GenerateDataKey on that key to create the data key, and the instance profile must hold kms:Decrypt to read the stream. AmazonSSMManagedInstanceCore grants neither KMS permission, so both must be added explicitly.

Trap Granting kms:Decrypt to the user instead of kms:GenerateDataKey, leaving the session unable to encrypt even though the instance can decrypt.

A managed node needs an instance profile carrying AmazonSSMManagedInstanceCore for the SSM Agent to register; without it the instance is unmanaged. In a private subnet with no internet, sessions fail with TargetNotConnected unless interface VPC endpoints for ssm, ssmmessages, and ec2messages exist, because ssmmessages carries the Session Manager data channel.

Trap Adding only the ssm endpoint and omitting ssmmessages, which carries the actual session channel that Session Manager opens to the node.

A two-way trust is required for AWS Enterprise Apps (WorkSpaces, IAM Identity Center, FSx) because AWS Managed Microsoft AD must query users and groups in the other directory. A forest trust is transitive, so a single trust to the on-premises forest root authenticates users in every child domain with the least effort. Linux WorkSpaces (Amazon Linux, RHEL, Rocky, Ubuntu) use SSSD, which does not support forest trusts, so they require an external trust instead.

Trap Configuring a forest trust for Linux WorkSpaces, whose SSSD integration only works over an external trust.

Client-side LDAPS encrypts traffic from AWS Managed Microsoft AD acting as an LDAP client to self-managed on-premises domain controllers; you register the CA certificate that chains to the on-prem server certificates, and a chain mismatch is the usual cause of failures. Server-side LDAPS (for apps querying the AWS directory) requires certificates issued by a Microsoft Enterprise CA joined to the AWS Managed Microsoft AD domain — third-party CA certificates installed directly on the controllers are rejected.

Trap Trying to install a third-party CA's certificate straight onto the AWS Managed Microsoft AD domain controllers for server-side LDAPS, which only accepts a joined enterprise CA.

Enabling selective authentication on a two-way trust restricts cross-trust access to only the principals explicitly granted the 'Allowed to Authenticate' permission on the relevant computer objects in the trusting directory. If selective authentication is enabled on the on-premises side, AWS application service accounts (for WorkSpaces, FSx, and similar) must be granted that permission or provisioning fails.

Trap Leaving the AWS application service account without 'Allowed to Authenticate' after selective authentication is enabled, which silently blocks WorkSpaces provisioning.

Server-side encryption with S3-managed keys (SSE-S3) applies AES-256 automatically to all new buckets created on or after January 5, 2023, with no per-bucket action required. An exam answer claiming objects are unencrypted by default, or that you must turn encryption on, is outdated. SSE-S3 gives no per-use CloudTrail audit and no key-policy access control, which is why you upgrade to SSE-KMS when those are required.

SSE-KMS encrypts S3 objects with a KMS key, so every encrypt and decrypt is recorded in CloudTrail and gated by the key policy, giving auditability and fine-grained access control that SSE-S3 cannot. The cost is a KMS request per object operation unless you enable an S3 Bucket Key. Reach for SSE-KMS when a requirement names auditable key usage, key rotation control, or restricting decryption to specific principals.

Dual-layer server-side encryption (DSSE-KMS) applies two independent AES-256 layers to an object: the first uses a KMS data key, the second uses a separate S3-managed key, so it is not two KMS layers. Use it only when a requirement explicitly names dual-layer at-rest encryption, such as certain government mandates; ordinary key-managed encryption is fully served by SSE-KMS.

Trap Reading DSSE-KMS as applying two KMS keys; only the first layer is KMS-backed, the second uses an independent S3-managed key.

With server-side encryption using customer-provided keys (SSE-C), you pass the encryption key in each PUT and GET; S3 encrypts or decrypts and then discards the key, so AWS never stores it. The vendor term is customer-provided keys, not customer-supplied. Choose SSE-C when the key must stay outside AWS-managed storage but you still want S3 to do the encryption work; choose client-side encryption when even the ciphertext-to-plaintext step must happen before data reaches AWS.

Trap Calling SSE-C 'customer-supplied keys'; the AWS term is customer-provided keys, and a wrong-name distractor relies on that slip.

Client-side encryption encrypts data inside your application before upload, so AWS only ever handles ciphertext and cannot read the plaintext even in memory. All four server-side modes, including SSE-C, let S3 see plaintext momentarily during the operation. When a requirement says AWS must never be able to access the data in clear, the answer is client-side encryption, with you owning all key management.

Trap Assuming SSE-C hides plaintext from AWS; with SSE-C, S3 still decrypts server-side, so plaintext exists on the service momentarily.

Without a Bucket Key, S3 calls KMS once per object operation, so large SSE-KMS buckets rack up per-request KMS charges. An S3 Bucket Key is a short-lived bucket-level key S3 derives from your KMS key and reuses to wrap many objects, cutting KMS request traffic by up to 99 percent. It changes only cost and the CloudTrail encryption context, not which key protects your data, and the savings grow with object count and shared requesters.

Two limits define when a Bucket Key helps: it is not supported for DSSE-KMS at all, and enabling it affects only objects written afterward, so existing objects must be re-copied (CopyObject) to adopt it. Enabling a Bucket Key also switches the KMS encryption context from the object ARN to the bucket ARN, so any key policy that scoped access by object-ARN encryption context must be rewritten to the bucket ARN or access breaks.

Trap Expecting a newly-enabled Bucket Key to cover objects already in the bucket; it applies only to new writes until you re-copy the old ones.

S3 Object Lock makes object versions immutable for a retention period or under a legal hold, and it works only on a bucket with S3 Versioning enabled because the lock attaches to a specific version. It protects against accidental or malicious deletion and overwrite, which encryption alone does not. Object Lock can also serve as a fixed-period retention solution where records must persist for a legal duration.

Trap Assuming you can enable Object Lock on a non-versioned bucket; versioning is a prerequisite because the lock binds to an object version.

In compliance mode, no principal can overwrite, delete, or shorten the retention of a protected object version, including the AWS account root user; the only way to remove the object before its retain-until date is to close the AWS account. Governance mode, by contrast, lets a caller with s3:BypassGovernanceRetention and the bypass header override the lock. Choose compliance mode when a regulator demands true immutability with no escape hatch.

Trap Believing the root user can delete a compliance-mode object early; root cannot, which is exactly the property regulators rely on.

Governance mode protects objects from deletion by most users but lets an operator holding s3:BypassGovernanceRetention delete or shorten the lock when they also send x-amz-bypass-governance-retention:true. Use it when trusted admins must be able to correct mistakes, or to test retention settings before committing to compliance mode. The escape hatch is the whole difference from compliance mode.

A legal hold places WORM protection on an object version with no expiry, independent of any retention period, and is set or cleared with s3:PutObjectLegalHold. Even after a retention period expires, an active legal hold keeps the version immutable until someone removes the hold. Use it when you cannot predict how long the data must stay frozen, such as during litigation or an audit.

S3 Glacier Vault Lock enforces a vault-level policy such as 'deny deletes for five years' through a two-step process: you initiate the lock, then have 24 hours to validate it before completing the lock, after which the policy becomes immutable. It is a distinct feature from S3 Object Lock (object versions) and AWS Backup Vault Lock (recovery points), a separation the exam tests directly.

Trap Confusing S3 Glacier Vault Lock with S3 Object Lock or AWS Backup Vault Lock; they immutably protect different resources and are configured separately.

Integrity for executable artifacts comes from digital signatures, not WORM storage: AWS Signer produces a signature over a code package, and consumers like Lambda code signing verify it and refuse to deploy a package whose signature does not match. This protects the supply chain so an altered artifact is rejected at deploy time rather than running silently.

A lifecycle rule cannot transition objects to S3 Standard-IA or One Zone-IA until they are at least 30 days old, and the same 30-day floor applies to noncurrent versions. Transitions straight to Glacier classes can fire from day 0, though each Glacier class still bills its own minimum duration in full: 90 days for Glacier Instant and Flexible Retrieval, 180 days for Deep Archive. A claim of 'IA transition after 0 days' is wrong.

Trap Configuring a 0-day transition to Standard-IA; the IA classes require a 30-day minimum, unlike the Glacier classes which allow day-0 transitions.

Amazon EFS lifecycle management moves files to Infrequent Access or Archive storage classes after a configured idle period to cut cost on cold data, and FSx file systems carry their own backup-retention policies. These are the file-system analogs of S3 Lifecycle; the design pattern of tiering cold data to cheaper storage applies across object and file storage, not just S3.

AWS Backup Vault Lock enforces WORM on recovery points. In compliance mode you set a cooling-off grace time of at least 3 days (72 hours); during grace time you can still remove or change the lock, but once it expires neither the root user nor AWS can delete recovery points or the vault until their lifecycle completes. Governance mode, by contrast, can be removed any time by a principal with sufficient IAM permissions.

Trap Assuming a freshly-created compliance lock is immediately immutable; it stays changeable during the >= 3-day grace time before locking in.

Encryption does nothing against an admin who deletes backups, so resilience comes from immutability plus isolation. Combine an AWS Backup compliance-mode locked vault with cross-account copies into a separate, locked-down account to create a logically air-gapped backup that a single compromised account cannot erase, and add cross-Region copies for regional failure. The locked vault stops deletion; the separate account stops a credential-holder from reaching it.

AWS DataSync is a transfer service for migrating or replicating large datasets between on-premises, other clouds, and AWS storage, with in-transit encryption and integrity checks. AWS Backup is for scheduled, point-in-time backups with retention and Vault Lock immutability. If a stem says 'migrate or replicate file data,' choose DataSync; if it says 'scheduled, retained, immutable recovery points,' choose AWS Backup.

Trap Reaching for DataSync to satisfy a backup-retention or immutability requirement; DataSync transfers data and does not manage retained recovery points.

Amazon Data Lifecycle Manager (DLM) automates the creation, retention, and cross-account or cross-Region copy of EBS snapshots and EBS-backed AMIs on a schedule. It is the EBS-specific automation layer; for cross-service centralized backups with Vault Lock you use AWS Backup instead. Reach for DLM when the requirement is specifically scheduled EBS snapshot or AMI lifecycle management.

On a versioned bucket, the NoncurrentVersionExpiration lifecycle action deletes noncurrent versions after NoncurrentDays, and adding NewerNoncurrentVersions keeps that many of the most recent noncurrent versions before expiration applies. A Filter element is required when NewerNoncurrentVersions is set. Pair it with AbortIncompleteMultipartUpload to clean up stalled uploads.

Trap Using only NoncurrentDays (or current-version Expiration) when the requirement is to keep the N newest noncurrent versions regardless of age.

Enabling EBS encryption by default makes every new EBS volume in that Region encrypted even when no encryption parameters are supplied, and you can set a specific customer managed key as the default encryption key instead of aws/ebs. The setting is Region-scoped, so it must be enabled separately in each Region; volumes in Regions where it is not enabled stay unencrypted.

Trap Assuming enabling encryption-by-default in one Region applies account-wide across all Regions.

KMS keys are Regional and cannot be used outside their Region, so creating an encrypted cross-Region read replica requires you to specify a customer managed key that exists in the destination Region (via --kms-key-id). The replica is then encrypted with that destination-Region key; you can enable automatic rotation on it independently.

Trap Trying to reuse the source Region's KMS key for the replica instead of creating and specifying a key in the destination Region.

You cannot turn on encryption in place for an existing unencrypted RDS or Aurora instance, nor change the KMS key of an already-encrypted one. Snapshot the database, copy the snapshot specifying the customer managed key (which encrypts the copy), and restore a new encrypted instance/cluster; once encrypted, its storage, automated backups, read replicas, and snapshots are all encrypted. Logical replication minimizes cutover downtime.

Trap Looking for a 'modify instance to enable encryption' option instead of the snapshot-copy-with-key-then-restore path.

Encrypting a DynamoDB table with a customer managed key gives CloudTrail audit of key use, automatic rotation, and immediate revocation by disabling the key. Customer managed keys require Global Table Version 2019 (not 2017), and each replica uses a CMK in its own Region. If a replica's CMK becomes inaccessible (disabled or pending deletion), DynamoDB removes that replica from the replication group about 20 hours later without deleting the replica table.

Trap Expecting CMK encryption on a Global Table Version 2017, or assuming an existing on-demand backup re-encrypts when you rotate to a new key (it stays on the key used at backup time).

Encrypted EFS needs the CMK enabled with kms:Decrypt and kms:GenerateDataKeyWithoutPlaintext (plus kms:CreateGrant for the caller creating the file system, often scoped with kms:ViaService). If the key is disabled or scheduled for deletion, EFS mounts fail and an encrypted RDS instance enters an inaccessible state; re-enable the key (or cancel deletion) and, for RDS, restart the instance to recover.

Trap Scheduling a CMK for deletion or removing its EFS/RDS permissions while data encrypted under it is still in use, which silently locks out the storage.

A service control policy sets the maximum permissions for IAM users and roles in member accounts, so a principal can only do something an SCP allows AND an IAM policy grants. Because it is a ceiling and not a grant, attaching an SCP that allows an action does nothing on its own; you still need an identity-based or resource-based policy to actually permit it. Attach SCPs at the org root or an OU and inheritance covers every current and future account below.

Trap Treating an Allow in an SCP as if it granted the permission; the identity still has no access until an IAM policy grants it.

Service control policies apply to every principal in member accounts, including each member account's root user, but they have no effect on the management account or its root. This is why the management account is kept empty of workloads: anything running there sits above your own guardrails. The fix for a management-account risk is to move the workload into a member account, not to write a tighter SCP.

Trap Writing an SCP to restrict the management account; SCPs exempt it entirely, so the policy has no effect there.

A resource control policy caps the maximum permissions on resources in member accounts, closing a gap SCPs cannot: an over-permissive S3 bucket or KMS key policy could grant access to a principal outside your organization that no SCP governs. The canonical RCP requires that access to your S3, STS, KMS, SQS, or Secrets Manager resources come from a principal in your own org via an aws:PrincipalOrgID condition, or that connections use TLS. Like SCPs, RCPs only set a ceiling and need all features enabled in Organizations.

Trap Reaching for an SCP to stop a cross-account principal from reading your bucket; an SCP only governs your own identities, so it never sees the external principal, an RCP does.

Resource control policies apply to a defined list of services such as S3, STS, KMS, SQS, Secrets Manager, DynamoDB, and CloudWatch Logs, not every AWS service, so confirm the service is in scope before relying on one. Like SCPs, RCPs do not affect resources in the management account and do not restrict service-linked roles. An RCP on a member account that is a delegated administrator still applies to that account's resources.

Whether a request succeeds is the logical intersection of what the SCPs allow, what the RCPs allow, and what the identity-based and resource-based policies grant. Any explicit deny at any layer wins, and a missing grant means denied even when every guardrail allows. Guardrails set the outer boundary; IAM still has to open the door inside it.

Where SCPs and RCPs decide whether an API call is authorized, a declarative policy enforces a desired account-level setting in the service's control plane and keeps it there even when the service ships a new API that could change it. You declare intent once, such as EBS encryption-by-default on or VPC block-public-access on, and Organizations maintains it for current and future accounts. Detaching the policy rolls the attribute back to its previous state.

Trap Using an SCP to keep EBS encryption-by-default on; an SCP can only deny specific API calls, so it cannot guarantee the setting survives a new service feature the way a declarative policy does.

SCPs and RCPs do not restrict service-linked roles, but declarative policies do, because they enforce configuration at the service level rather than at API authorization. So when a requirement must hold even against service-managed behavior, a declarative policy is the right org-policy tool. This is also why declarative policies, unlike SCPs and RCPs, affect the management account where attached.

Trap Assuming an SCP can constrain a service-linked role; SCPs exempt SLRs, so only a declarative policy reaches them.

Beyond the authorization policies, the same Organizations machinery distributes backup policies, tag policies, and AI services opt-out policies inherited down the OU tree. The AI services opt-out policy stops AWS AI services such as Amazon Bedrock and Amazon Rekognition from storing or using your content to improve those services, applied org-wide instead of per account. Tag policies standardize tag keys and values; backup policies centrally enforce AWS Backup plans.

The standard way to confine an organization to approved Regions is an SCP that denies actions when aws:RequestedRegion is not an approved value, attached at the root or OU so future accounts inherit it. You must exempt global services such as IAM, STS, CloudFront, Route 53, and Organizations because they have no Regional endpoint, and you cannot deny access to your home Region. Control Tower's built-in Region deny control implements exactly this pattern.

Trap Applying the Region-deny SCP without exempting global services like IAM and STS; those calls have no Region and would be blocked, breaking the account.

Control Tower automates a multi-account landing zone: it provisions the shared accounts (management, log archive, audit), applies a baseline of controls, and vends new governed accounts through Account Factory. Reach for Control Tower when you want a governed baseline out of the box; use raw Organizations when you need fully custom control with no opinionated structure. Account Factory for Terraform (AFT) wraps Account Factory in a Terraform pipeline for infrastructure-as-code account vending.

A preventive control stops a non-compliant action before it happens and is implemented as an SCP or RCP; a detective control reports drift after the fact and is implemented as an AWS Config rule; a proactive control checks resources against policy before they are provisioned and is implemented as a CloudFormation hook. Matching the behavior to the requirement is the testable point: stop it (preventive), find it later (detective), or block it at deploy time (proactive).

Trap Picking a detective control to stop a non-compliant action; a Config rule only reports drift after the fact, you need a preventive SCP/RCP to actually block it.

By guidance level, mandatory controls are always on and cannot be disabled, strongly recommended controls follow AWS best practice, and elective controls let you opt into stricter behavior. This guidance level is independent of the preventive/detective/proactive behavior axis, so a control is described by both, for example a strongly recommended detective control.

AWS recommends keeping the management account free of workloads, so day-to-day operation of GuardDuty, Security Hub, AWS Config, IAM Access Analyzer, and Detective is delegated to a dedicated security or audit account. That delegated administrator configures the service, auto-enrolls members, and views findings org-wide, while the management account only enables trusted access. This shrinks the blast radius of the most powerful account.

Trap Operating GuardDuty or Security Hub from the management account; AWS guidance is to delegate it to a security account so the management account stays workload-free.

IAM Identity Center supports a delegated administrator member account, but the Identity Center instance itself must always reside in the management account. The delegated administrator can manage most things but cannot alter permission sets used for access to the management account; only an Identity Center administrator in the management account can change those.

Trap Assuming a delegated administrator can move the IAM Identity Center instance out of the management account; the instance must remain there even with delegation.

Central management of root credentials lets the management account or a delegated administrator delete a member account's root password, access keys, signing certificates, and MFA device, so no long-term root credential exists to be stolen or misused. You enable it with the EnableOrganizationsRootCredentialsManagement action. The management account's own root user is governed separately and is not removed this way.

After removing standing root credentials, genuine root-only tasks run through a central root session: a short-lived, task-scoped session of at most 15 minutes authorized to perform only that one action, enabled with EnableOrganizationsRootSessions. The canonical uses are recovery: deleting a misconfigured S3 bucket policy that denies all principals, and deleting an SQS queue resource-based policy that denies all principals. This replaces logging in as the member account root with a permanent credential.

Trap Recovering a deny-all bucket policy by logging in as the member account root; centralized root access removes that standing credential, so the recovery path is a 15-minute task-scoped root session from the central account.

When the goal is to limit what identities in member accounts may do, the answer is an SCP; when it is to protect resources from over-broad or cross-org access, the answer is an RCP with aws:PrincipalOrgID; when it is to keep a service setting true over time, the answer is a declarative policy. Reading the verb in the stem (limit identities, protect resources, pin a setting, recover root) is the fastest discriminator on this subtopic.

Trap Choosing an SCP for a resource-protection goal because both are deny policies; an SCP cannot see an external principal accessing your resource, so the resource case needs an RCP.

SCPs, RCPs, and declarative policies require an organization with all features enabled, not the consolidated-billing-only mode. Consolidated billing alone gives you combined invoicing and volume discounts but none of the authorization or configuration guardrails. Switching to all features is a one-way move that member accounts must approve.

IAM Access Analyzer external-access analysis only evaluates resource policies in the Region where the analyzer is enabled, so multi-Region coverage requires an analyzer in each Region with resources. Set the organization as the zone of trust to flag only access from outside the org, and run it from a delegated administrator to view findings org-wide without the management account.

Trap Assuming a single analyzer covers every Region: an analyzer in us-east-1 never produces findings for resources in another Region.

An archive rule with criteria such as a trusted account ID or resource type automatically marks matching external-access findings as intended, and choosing 'create and archive active findings' applies it to existing findings too. Access Analyzer suggests the default criterion 'Public access is false' so a rule never silently archives findings for genuinely public resources.

An IAM Access Analyzer unused-access analyzer supports two exclusion lists: specific AWS account IDs to skip entirely, and tag key-value pairs that exempt matching IAM users and roles (for example break-glass roles tagged Purpose=Emergency-Access) from generating unused-access findings.

Policy validation sorts findings into errors, security warnings, general warnings, and suggestions. iam:PassRole on Resource "*" is a security warning because passing any role enables privilege escalation; security warnings call out overly permissive statements rather than syntax problems.

Customizations for AWS Control Tower (CfCT) is the AWS-published solution that uses a CloudFormation manifest, StackSets, and SCPs to configure accounts, triggered by Control Tower lifecycle events such as CreateManagedAccount. It is the low-overhead choice for automating post-Account-Factory setup without Terraform.

Trap Reaching for Account Factory for Terraform (AFT) when no Terraform is wanted: AFT is the Terraform/GitOps path, while CfCT is the CloudFormation-native one.

Account Factory for Terraform (AFT) runs from a dedicated AFT management account and provisions Control Tower accounts from account-request Terraform files in a repo (GitOps). After provisioning it applies aft-global-customizations to every account and aft-account-customizations to accounts whose request names a matching customization; failures surface on the aft-failure-notifications SNS topic.

Pre-existing accounts join Control Tower governance through the Enroll account action in Account Factory, which deploys the baseline (Config, CloudTrail, Identity Center access, SCPs) into a registered OU. Each account must already have the AWSControlTowerExecution role trusting the management account, and any existing Config recorder and delivery channel must be removed first because Control Tower creates its own.

Control Tower reports drift when its managed resources change outside Control Tower, such as an account moved between OUs through Organizations or a Control-Tower SCP edited by hand. The remediation is to move the account back to its registered OU through Control Tower and run the Reset action to re-apply the baseline and SCPs.

Trap Editing the drifted SCP or OU directly in Organizations to undo it: changes made outside Control Tower keep the landing zone in drift instead of clearing it.

With an external IdP, SAML 2.0 only handles sign-in; new users and groups appear in IAM Identity Center only when SCIM v2.0 automatic provisioning is configured. Identity Center rejects multivalue attributes over SCIM, so each attribute such as email or phone must map to a single value or the sync fails.

Trap Assuming working SAML federation also creates accounts: without SCIM, newly added IdP users never provision and cannot access AWS.

A SCIM access token generated in IAM Identity Center is valid for one year. When it is within 90 days of expiry, AWS posts reminders in the Identity Center console and the AWS Health Dashboard so you can rotate it; if it expires, provisioning synchronization stops.

The AWS access portal session duration (set in Identity Center settings, up to 90 days) controls how long a user stays signed in to the portal, while each permission set's session duration (1 to 12 hours) caps a console/role session inside an account. Set them independently to allow a long portal sign-in but short account sessions.

A guardrail that keeps member accounts from detaching or disabling service integration is an SCP that denies organizations:LeaveOrganization (and organizations:DisableAWSServiceAccess) attached to the Root, where it inherits to all current and future accounts. Because a deny in SCPs is inherited by everything beneath the attach point, attaching it one OU too high blocks sibling OUs you meant to leave alone.

Trap Attaching a targeted deny to a parent OU instead of the intended child OU: the deny flows down to every child OU and account, not just the one you wanted to restrict.

To let a specific role (for example a SecurityAuditRole) keep performing actions an SCP otherwise denies org-wide, add a condition to the Deny statement using ArnNotLike on aws:PrincipalArn for that role's ARN, so the deny applies to everyone except the excluded principal.