SAA-C03 sample questions — 25 answered and explained

Cross-account role assumption needs consent on both sides: the target role's trust policy must name the caller, and the caller's identity-based policy must allow sts:AssumeRole on the target role.

Within one account a single allow can be enough, but across accounts both accounts must allow the request. Account B consents through the trust policy on the role being assumed, and account A consents by allowing its role to call sts:AssumeRole on that role's ARN. An SCP cannot grant anything, a permissions boundary has no say in who may assume a role, and a trust policy on the caller's own role controls who can assume the caller, not what the caller can assume.

1. Locate the role being assumed: it is in account B.
2. Its trust policy must name the caller.
3. Across accounts the caller's account must also allow the action: sts:AssumeRole in an identity-based policy.
4. Discard layers that cannot grant (SCPs) or that do not control assumption (boundaries).

Exam tip: Cross-account AssumeRole = trust policy on the target role + sts:AssumeRole allow on the caller.

A central pipeline or tool that acts in many accounts should assume a role in each target account. Each role trusts the pipeline's role, carries only the permissions that account needs, and issues temporary credentials per session.

Per-account deployment roles give the pipeline short-lived credentials, keep permissions scoped account by account, and leave an AssumeRole record for every deployment. Reusing OrganizationAccountAccessRole is the tempting shortcut because it already exists in accounts created by Organizations, but it grants AdministratorAccess and trusts the management account, not the operations account, so it fails least privilege. Resource-based policies are not available for the stacks and instances involved, and an SCP cannot grant anything.

1. Identify the actor: an automated principal in one account acting in many others.
2. Rule out layers that cannot grant (SCPs) and resources with no resource policy (EC2 instances, CloudFormation stacks).
3. Reject the existing administrator role: it works only with a trust change and is far broader than the pipeline needs.
4. Create a scoped role per workload account whose trust policy names the pipeline's role.

Exam tip: Hub-and-spoke automation: one trusted role per target account, assumed per run.

Third parties that run in their own AWS account should get access through a cross-account role, not IAM user keys. For multi-tenant vendors, the trust policy also requires an external ID that the vendor assigns to each customer.

A cross-account role with an external ID condition gives the vendor only temporary credentials, never exposes long-lived keys, and can be revoked by editing the trust policy. The same role without the external ID is the near-twin: it fixes the keys but leaves the confused-deputy gap that a multi-tenant vendor creates. An Identity Center user is a workforce sign-in for people, not a way for a vendor's service in another AWS account to call this one. Resource-based policies do not cover most of what a cost tool reads.

1. Identify the actor: an automated multi-tenant service in its own AWS account.
2. Rule out any design that gives the vendor long-lived keys or a workforce identity.
3. Use a cross-account role with read-only permissions in the company's account.
4. Because the vendor serves many customers, add an external ID condition to the trust policy.

Exam tip: Vendors assume a role with an external ID; they never receive access keys.

The confused-deputy problem: a trusted multi-tenant service can be tricked into using its access to one customer on behalf of another. The external ID, a value the vendor assigns per customer and checks in the trust policy condition sts:ExternalId, ties each assumption to the right customer.

Requiring the vendor-generated external ID means the vendor can assume this role only when acting for this company, which is exactly the risk raised. MFA would break an automated integration. Source IP conditions cannot tell customers apart, because every customer's requests come from the same vendor. A permissions boundary narrows what the role can do but does nothing about who causes it to be assumed.

1. Name the risk: another customer using the vendor as a confused deputy.
2. Find the control that distinguishes customers, not callers: the external ID.
3. Rule out MFA (breaks automation) and IP ranges (same for all customers).
4. Add the sts:ExternalId condition to the trust policy; the permissions stay as they are.

Exam tip: External ID = confused-deputy defense for multi-tenant vendors; it goes in the trust policy condition.

IAM Identity Center provides workforce single sign-on across every account in an organization. It connects to an existing identity source (here Microsoft Entra ID through SAML 2.0 and SCIM) and grants access with permission sets assigned to accounts.

Identity Center connected to Entra ID lets employees use the identity they already have, provisions roles in each account from permission sets, and makes offboarding a single change in Entra ID. Per-account SAML federation also removes IAM users but has to be configured and maintained 25 times. A hub account with role switching and a sync script both keep IAM users that live apart from the corporate directory.

1. Identify the actor: a workforce across many accounts with an existing IdP.
2. Prefer federation to the existing IdP over creating identities in AWS.
3. Compare federation options: per-account SAML versus one central configuration.
4. Choose IAM Identity Center with permission sets for the lowest ongoing overhead.

Exam tip: Workforce + many accounts + existing IdP = IAM Identity Center with permission sets.

To federate an existing on-premises Active Directory for workforce access to many AWS accounts, connect it to IAM Identity Center (through AD Connector or AWS Managed Microsoft AD) and assign directory groups to accounts with permission sets.

Connecting the AD as Identity Center's identity source lets employees use their existing credentials, and permission sets assigned to AD groups give every account temporary-credential roles that are managed from one place. Identity Center with its default directory is the near-twin: it centralizes access but duplicates the workforce in a second directory. Per-account SAML federation also gives temporary credentials but splits the permission assignment across 30 accounts, and mirroring users into IAM keeps long-lived credentials.

1. Note the existing directory: an on-premises Microsoft AD.
2. Note the requirements: temporary credentials and centralized per-account assignment.
3. Connect the AD to IAM Identity Center through AWS Directory Service.
4. Assign AD groups to accounts with permission sets.

Exam tip: Existing AD + many accounts: connect AD to IAM Identity Center and assign groups with permission sets.

Permissions boundaries enable safe delegation: developers may create roles only if each new role carries an approved boundary (enforced with the iam:PermissionsBoundary condition key), so no delegated role can exceed it.

Requiring the approved boundary on every role created gives both self-service and a hard ceiling. The full pattern also denies developers the ability to remove or edit the boundary. Putting the boundary on the developers themselves is the near-twin trap: it caps the developers, not the roles they create. Blocking role creation with an SCP removes self-service, and a Config rule only detects violations after the roles exist.

1. Separate the two goals: self-service role creation and a ceiling on every created role.
2. Recall that a boundary limits only the identity it is attached to.
3. Attach the boundary to the created roles by requiring it in an iam:PermissionsBoundary condition.
4. Also deny developers permission to change or remove the boundary policy.

Exam tip: Delegate IAM safely by forcing a permissions boundary onto every role developers create.

A permissions boundary sets the maximum permissions for a user or role but grants nothing. Effective permissions are the intersection of what the identity-based policies allow and what the boundary allows.

S3 is allowed by the identity policy but falls outside the boundary, and DynamoDB is inside the boundary but not allowed by the identity policy, so neither service is in the intersection. Treating the boundary as a grant (DynamoDB works) or the two policies as a union are the common mistakes. Boundaries apply to IAM users too, and same-account access needs no bucket policy when an identity policy allows it.

1. List what the identity policy allows: S3.
2. List what the boundary allows: DynamoDB.
3. Take the intersection: nothing.
4. Fix by allowing both in each layer, or adjust whichever layer is wrong.

Exam tip: Boundary ∩ identity policy = effective permissions; a boundary alone grants nothing.

SNS subscription filter policies let each subscriber receive only the events it wants, and subscribing an SQS queue gives that subscriber a durable buffer with its own dead-letter queue.

The refunds team needs three things, and two subscription-side changes provide them: an SQS queue subscribed to the topic (durable through maintenance, with a redrive policy to a dead-letter queue for repeated failures) and a filter policy on that subscription (only shipment-cancelled events, no publisher change). A second topic would separate the events, but only by changing the publisher. Filtering inside a Lambda subscriber works for selection but leaves the team without a buffer it controls or a dead-letter queue for its processing failures. SNS cannot be polled.

1. Split the requirements: selection, durability, failure isolation, no publisher change.
2. Selection without publisher change: a filter policy on the subscription.
3. Durability and failure isolation: an SQS queue subscriber with a redrive policy to a dead-letter queue.
4. Reject polling SNS (not possible) and options that change the publisher.

Exam tip: Subscriber wants a subset of a shared topic: filter policy on its subscription; wants durability: subscribe its own SQS queue with a DLQ.

EventBridge is an event bus with rules: rules match on event content and route to many target types, and SaaS partner event sources deliver third-party events onto a partner event bus with no polling or webhook code.

Two requirements together point to EventBridge. Content-based routing to a Step Functions workflow and to an SQS queue is a pair of rules with different targets. Receiving a supported SaaS help desk's events without webhooks is what partner event sources do. SNS is the tempting near-twin because its filter policies can now match on the message body, but SNS cannot deliver to Step Functions directly and has no SaaS partner integration. The SQS-plus-Lambda router and per-destination Kinesis consumers both move the routing into custom code and still leave the help desk integration unsolved.

1. List the targets: a Step Functions workflow and an SQS queue, chosen by a value in the event.
2. List the sources: your application and a third-party SaaS partner.
3. Recall that EventBridge rules route by content to Step Functions, SQS and more, and partner event sources ingest SaaS events.
4. Check SNS: payload filtering exists, but Step Functions is not a subscriber type and there are no partner sources.

Exam tip: Content-based routing to varied targets plus SaaS partner events = EventBridge; SNS filters but cannot reach every target or ingest SaaS events.

A central EventBridge event bus with a resource-based policy is the standard pattern for cross-account event-driven architectures: producers put events on it, and rules on that one bus decide which events go to which consumer accounts.

The governance requirement decides it. With a central bus, every routing decision is a rule in one account, producers are granted access by the bus's resource policy, and consumer accounts receive matches on their own buses. SNS topics in each producer account are a workable cross-account pattern but scatter governance across every account, and filter policies are owned per subscription. A central Kinesis stream gives shared access but no routing, so each consumer writes filtering code. A single shared SQS queue fails outright because consumers compete for messages.

1. Identify the needs: cross-account publish and consume, routing on event fields, one governance point, minimal code.
2. Rule out the shared queue: competing consumers.
3. Rule out the shared stream: no routing, filtering in code.
4. Choose between SNS per account and a central bus on governance: the central EventBridge bus keeps every rule in one place.

Exam tip: Cross-account event routing governed in one place = a central EventBridge bus with a resource policy and rules.

Step Functions has two workflow types. Standard workflows run for up to one year with exactly-once execution and support the callback pattern; Express workflows run for up to five minutes, are at-least-once and suit high-volume, short event processing.

A days-long human pause needs a Standard workflow: a task started with a task token waits until the portal calls SendTaskSuccess or SendTaskFailure, and per-step Retry rules provide the backoff for the bureau call with no code. The Express twin looks identical but fails on two facts: its five-minute maximum duration and its lack of support for the callback pattern. Chained Lambda functions and queue-plus-polling designs can be made to work, but only with hand-written retries, state tracking and polling, which the LEAST custom code qualifier rules out.

1. Spot the orchestration need: ordered steps with per-step retries points to Step Functions.
2. Spot the long human wait: days rules out anything bounded by minutes.
3. Recall the workflow types: Standard runs up to a year and supports task tokens; Express runs up to five minutes.
4. Pick Standard with Retry rules and a callback task token.

Exam tip: Human approval or multi-day waits = Step Functions Standard with a task token; Express is for short, high-volume runs.

Orchestration keeps a workflow's sequence, retries and state outside the functions. A Step Functions state machine calls each function as a task, applies Retry and Catch rules per step, and records every execution.

All three symptoms come from the chain itself. In a state machine no function waits for another, because Step Functions drives each task in turn; retries become declarative Retry rules on each state instead of copied code; and the execution history shows the failed state. Queues between functions are the tempting alternative: they remove the waiting, but each hop needs its own retry and dead-letter handling and there is no end-to-end view of a run. A layer plus longer timeouts tidies the code but keeps the coupling. A single Fargate task is a rewrite that rebuilds what Step Functions provides.

1. Trace each symptom to the synchronous chain: waiting, duplicated retries, no run state.
2. Recall what Step Functions provides: sequencing, per-state Retry/Catch, and execution history.
3. Check the queue option: it fixes waiting but not visibility or centralised retries.
4. Choose the state machine as the one change that fixes all three with no new code.

Exam tip: Lambda functions calling Lambda functions is a smell: orchestrate the steps with Step Functions and its Retry/Catch rules.

API Gateway is a managed front door: usage plans and API keys give per-client throttling and quotas, request validators check requests before integration, and the stable API contract decouples clients from the backend.

Each requirement maps to a built-in API Gateway feature: a usage plan per partner sets that partner's rate, burst and quota; request validation runs before the backend; and swapping the integration from HTTP to Lambda leaves the public contract unchanged. AWS WAF rate-based rules, whether on an ALB or CloudFront, throttle by IP or other request keys but have no concept of a monthly quota per client, and validation would be custom code. Building it into the application meets the functional needs but maximises operational overhead and ties the controls to the backend being replaced.

1. List the needs: per-partner rate limit and quota, validation, backend swap without client change.
2. Map them to API Gateway: usage plans with API keys, request validators, stable API in front of a changeable integration.
3. Check the WAF options: rate limiting yes, quotas and validation no.
4. Prefer the managed feature set over custom middleware for least overhead.

Exam tip: Per-client throttles and quotas on an API = API Gateway usage plans with API keys; WAF rate rules don't do quotas.

When many Linux instances need concurrent read-write access to the same files across AZs with POSIX semantics, the answer is file storage — and with no Windows or HPC keyword, that means EFS.

The four EFS tells all appear: shared, concurrent, across AZs, POSIX. EFS mounts simultaneously from every instance in every AZ and scales capacity automatically as the Auto Scaling group churns files. Multi-Attach is the precise-fact trap: it does exist, but it is same-AZ only and demands a cluster-aware file system, so it fails a multi-AZ fleet twice. S3 fails the access shape — the application performs file operations, not API calls. Per-instance gp3 volumes with sync scripts technically function but recreate a distributed file system by hand, with consistency conflicts and constant maintenance.

1. Extract the pattern: shared, concurrent, read-write, multi-AZ, POSIX file semantics.
2. Eliminate block storage: EBS attaches within one AZ, and Multi-Attach is same-AZ with a cluster-FS requirement.
3. Eliminate object storage: S3's API access does not satisfy POSIX file operations.
4. Check for redirect keywords (Windows, SMB, Active Directory, HPC): none, so EFS rather than FSx.
5. Select EFS mounted on all instances across the three AZs.

Exam tip: Shared + concurrent + across AZs + POSIX on Linux is the EFS signature; EBS Multi-Attach is a same-AZ clustering tool, not general file sharing.

In Bursting mode EFS throughput scales with the data stored, so a small, busy file system drains its burst credits and throttles. Provisioned throughput fixes a known, steady requirement at a fixed rate; Elastic throughput (the default for new file systems) suits spiky or unpredictable load and bills per use.

The symptom (fast in the morning, collapsing by midday) is burst-credit exhaustion on a 50 GiB file system whose baseline is tiny. Both Provisioned and Elastic throughput would remove the throttling, so the stated constraints decide: the requirement is known and constant, and finance wants a predictable charge. AWS recommends Provisioned throughput for known requirements with a high average-to-peak ratio, and Elastic for spiky, hard-to-forecast load, where pay-per-use wins. Padding the file system works mechanically but bills for junk data. Max I/O is a previous-generation performance mode, set only at creation, that adds latency and does not touch throughput credits.

1. Recognize the symptom: good throughput after idle periods that collapses under sustained load means burst credits are draining.
2. Connect it to configuration: Bursting mode ties baseline throughput to stored size, and 50 GiB is small.
3. List the real fixes: Provisioned or Elastic throughput both decouple throughput from size.
4. Apply the constraints: a known, steady rate with a predictable bill points to Provisioned; Elastic suits spiky, unpredictable load.
5. Reject padding (wasteful) and Max I/O (previous-generation latency trade-off, not a throughput fix).

Exam tip: Small, busy EFS on Bursting throttles: choose Provisioned throughput for a known steady rate, Elastic for spiky or unpredictable load.

EFS answers shared multi-AZ POSIX access, and its lifecycle management answers the cost-optimization variant by automatically moving cold files to an Infrequent Access storage class.

Two requirements, two actions. Shared POSIX access across AZs on Linux is EFS's home ground, so the files belong on EFS. The cost problem is storage cost from cold files, and EFS has a built-in answer: lifecycle management transitions files untouched for a chosen period to Infrequent Access automatically, with no scripts or migration. Changing to Provisioned throughput is the tempting EFS-shaped distractor, but throughput mode changes how throughput is billed, not what each stored GB costs. The self-managed NFS server can serve the fleet, but the team inherits an entire file-server operation. S3 with lifecycle rules is cheap but breaks the access model: the instances mount a file system, and S3 is not mountable POSIX storage.

1. Match the access pattern (shared, concurrent, multi-AZ, POSIX on Linux) to EFS.
2. Identify the cost driver: storage of files that are rarely read after 30 days.
3. Address it with the managed storage-class feature: lifecycle management to Infrequent Access.
4. Eliminate Provisioned throughput (a throughput billing choice, not a storage-price one), the self-built NFS server (operational effort) and S3 (breaks mount semantics).

Exam tip: EFS plus lifecycle management to Infrequent Access is the managed answer for shared POSIX storage with aging, rarely accessed files.

FSx questions are close to keyword matching: Windows clients, SMB protocol, and Active Directory all name FSx for Windows File Server.

The scenario stacks the FSx for Windows File Server signals: SMB drive mappings, NTFS permissions and Active Directory groups, with a fully managed requirement. FSx for Windows File Server provides managed SMB shares with NTFS ACLs and native AD integration. EFS is the familiarity trap: it serves NFS to Linux and cannot satisfy SMB or AD. FSx for Lustre is a parallel HPC file system, and FSx for OpenZFS is the near-twin within the FSx family: managed and fast, but NFS-only with Unix permissions.

1. List the signals: SMB drive mappings, NTFS permissions, Active Directory groups.
2. Eliminate NFS-only services: EFS and FSx for OpenZFS.
3. Eliminate FSx for Lustre: parallel HPC throughput, not a departmental Windows share.
4. Choose the managed Windows-native file service: FSx for Windows File Server.

Exam tip: Windows, SMB, or Active Directory in a file-share scenario points to FSx for Windows File Server, never EFS.

Data lake in S3 plus a compute burst needing a fast POSIX file system is FSx for Lustre linked to the bucket; the scratch deployment type answers the MOST cost-effective variant for short-lived jobs.

Lustre is the HPC answer: parallel throughput at cluster scale, and the S3 linkage presents the bucket's objects as files and writes results back — no bulk copy phase. The cost qualifier then splits scratch from persistent: scratch file systems are cheaper and non-replicated, built exactly for a several-day campaign after which the file system is discarded, so persistent Lustre is the workable-but-overpaying distractor. EFS fails the performance class — it is general shared NFS, not a parallel file system for hundreds of concurrent HPC clients — and forces a manual data copy besides. Per-node gp3 copies collapse under petabyte scale and offer no shared namespace at all.

1. Spot the HPC signals: massive parallel throughput, POSIX access, large compute cluster.
2. Choose the service: FSx for Lustre, using its S3 linkage to avoid copying the data lake.
3. Apply the cost qualifier to deployment type: short-lived, disposable work fits cheaper scratch file systems.
4. Eliminate persistent Lustre (paying for durability between campaigns), EFS (wrong performance class), and per-node EBS copies (unshared, impractical).

Exam tip: S3 data plus a temporary HPC processing burst equals scratch FSx for Lustre linked to the bucket.

Multipart upload is the S3 tool for large objects: parts upload in parallel and failed parts retry individually, which is decisive on unreliable connections.

The pain is stated precisely — large uploads fail partway and restart from zero. Multipart upload fixes that mechanism: the file is split into parts, each part is an independent transfer, and only a failed part is retried, so an interruption costs one part rather than gigabytes of completed progress. Transfer Acceleration is the tempting sibling, but it solves distance, not resilience — an accelerated single-stream upload still restarts entirely on failure. Byte-range fetches are the mirror-image tool for downloads and simply do not apply. Longer timeouts with whole-object retries treat the symptom while preserving the restart-from-zero cost.

1. Name the bottleneck: transfer failure recovery on large objects, not distance or request rate.
2. Match the tool: multipart upload retries failed parts individually and parallelizes the rest.
3. Eliminate Transfer Acceleration as a distance optimization that keeps whole-transfer failure semantics.
4. Eliminate byte-range fetches as download-side, and timeout tweaks as not addressing partial-failure recovery.

Exam tip: Large uploads that fail partway resolve to multipart upload — Transfer Acceleration only helps when distance is the bottleneck.

Incomplete multipart uploads keep their parts, billed as storage, until they are completed or aborted, and those parts never appear in listings. A versioning status of Disabled means the bucket has never been versioned (Suspended means it once was), so it holds no noncurrent versions or delete markers; Expiration is the action that removes current objects.

Two hidden-storage causes fit billed storage exceeding what listings show: noncurrent versions and incomplete multipart upload parts. A Disabled status rules out versions, because only buckets that were once versioned (now Enabled or Suspended) can hold them, and retried multi-gigabyte uploads point at abandoned parts, so AbortIncompleteMultipartUpload is the fix. For the 400-day rule, Expiration deletes current objects; NoncurrentVersionExpiration with the same number of days looks equivalent but touches only noncurrent versions, which this bucket does not have. ExpiredObjectDeleteMarker is likewise a versioned-bucket cleanup.

1. List the causes of billed storage that listings do not show: noncurrent versions and incomplete multipart upload parts.
2. Read the versioning status: Disabled means never versioned, so no noncurrent versions or delete markers exist.
3. Add AbortIncompleteMultipartUpload for the parts left by failed, retried uploads.
4. Use Expiration, not NoncurrentVersionExpiration, to delete current objects at 400 days.

Exam tip: Disabled means never versioned: hidden storage there is abandoned multipart parts, and only Expiration removes current objects.

S3 One Zone-IA prices below Standard-IA by storing data in a single Availability Zone; it is only correct when the data is re-creatable or a secondary copy, because it does not survive the loss of that AZ.

The scenario grants the exact license One Zone-IA requires: thumbnails can be regenerated from originals stored elsewhere, so losing an AZ costs regeneration compute, not data. With infrequent access and a millisecond display requirement, One Zone-IA is the cheapest class that satisfies both. Standard-IA over-delivers multi-AZ durability for data that is disposable by design, so a cheaper sufficient option beats it. Glacier Flexible Retrieval fails the millisecond requirement outright. Standard meets everything but is the priciest per GB, and at infrequent access its lack of retrieval fees does not compensate.

1. Confirm the data is re-creatable: thumbnails regenerate from originals in another bucket.
2. Confirm the access pattern: infrequent views that must still be millisecond-fast.
3. Eliminate asynchronous Glacier tiers on the latency requirement.
4. Choose One Zone-IA over Standard-IA because single-AZ durability is acceptable for disposable data and it costs less.

Exam tip: One Zone-IA is only for re-creatable or secondary-copy data, and for exactly that data it beats Standard-IA.

gp2 performance scales with size (3 IOPS per GB), which led teams to oversize volumes to buy IOPS. gp3 includes 3,000 IOPS and 125 MiB/s at any size, so the data size alone sets the volume size. Elastic Volumes can change type and grow a volume online but cannot shrink it.

Two facts combine. First, gp3 gives 3,000 IOPS at any size, so the 1 TB sizing existed only because of gp2, and a gp3 volume sized to the data meets the requirement. Second, EBS volumes cannot be shrunk, so reaching the smaller size means copying the data to a new volume, which the maintenance window allows. Converting in place to gp3 is the tempting answer because it is online and cheaper, but it keeps paying for about 700 GB per volume that holds nothing. A small gp2 volume drops to 900 IOPS baseline. io2 meets performance but adds a per-IOPS charge that gp3 does not have.

1. Find why the volumes are oversized: gp2 ties IOPS to size, so 1 TB was bought to get 3,000 IOPS.
2. Recall that gp3 includes 3,000 IOPS at any size, so the data size sets the volume size.
3. Recall that Elastic Volumes cannot shrink a volume, so a smaller size needs a new volume and a data copy.
4. Use the maintenance window for the copy, and reject io2, which pays extra for IOPS that gp3 includes.

Exam tip: gp3 decouples IOPS from size; EBS volumes only grow, so right-sizing down means a new, smaller volume.

EBS volumes are billed for provisioned capacity whether or not they are attached. Snapshots are billed only for the data they hold and can be restored to a new volume at any time.

Available-state volumes keep billing for their full provisioned size. When nobody knows whether the data matters, deleting outright is too risky, and keeping or attaching the volumes saves nothing. Snapshotting first keeps a recoverable copy at the lower snapshot rate on only the used data, and deleting the volumes then stops the provisioned-capacity charge.

1. Recall that EBS bills provisioned capacity, attached or not.
2. Keep a recoverable copy because the data might still be needed.
3. Use snapshots, which bill only for stored data, as that copy.
4. Delete the volumes to stop the provisioned-capacity charge.

Exam tip: Unattached EBS volumes still bill in full; snapshot them and delete the volumes when the data might still matter.

EBS snapshots are incremental, but deleting an older one is safe because AWS preserves the blocks newer snapshots reference. Data Lifecycle Manager automates retention only for the snapshots it creates. The EBS Snapshots Archive tier stores full snapshots at a much lower price, with a 90-day minimum and restores that take up to 72 hours.

Two changes capture the savings. The daily snapshots beyond 14 days are not required, and deleting them is safe because AWS keeps any blocks newer snapshots depend on; DLM then enforces the policy going forward (it cannot manage the existing manual snapshots, which is why the backlog is deleted directly). The month-end snapshots match the archive tier exactly: kept for years and almost never restored. Archiving everything is the tempting near-twin, but the archive stores each snapshot in full with a 90-day minimum, which makes short-lived daily snapshots more expensive, not less. Keeping old snapshots because they are incremental is the misconception, and a cross-Region copy only adds cost.

1. Separate the snapshots by requirement: daily ones for 14 days, month-end ones for 5 years.
2. Delete the unneeded daily snapshots, which is safe because AWS preserves blocks that newer snapshots reference.
3. Automate retention for new snapshots with Data Lifecycle Manager.
4. Archive only the long-retention, rarely restored month-end snapshots, because the archive tier stores full snapshots with a 90-day minimum.

Exam tip: Prune old incremental snapshots safely, automate retention with DLM, and archive only snapshots kept for months and rarely restored.