S3 Lifecycle Policy practice questions

A team stores application logs in an S3 bucket. They keep logs for 18 months for compliance. Access patterns: logs are heavily accessed during the first 30 days, rarely accessed between days 31 and 180, and almost never accessed after day 180. They currently store everything in S3 Standard and want to reduce storage cost without violating the 18-month retention requirement. What should they implement?

Trap 1: Leave logs in S3 Standard for 18 months and add a tag for internal…

Adding a tag is purely for metadata, reporting, and cost allocation; it does not change the underlying S3 storage class, so the logs still incur the full S3 Standard rate for all 18 months. Since application logs are rarely read after the first few weeks, keeping them in the most expensive storage class is wasteful. A lifecycle policy that moves cold logs to Standard-IA and then Deep Archive would achieve the same retention at a fraction of the cost.

Trap 2: Immediately move all logs to Glacier Instant Retrieval and expire…

Moving every log to Glacier Instant Retrieval immediately is problematic because it does not distinguish between hot logs from the recent 30 days and older, colder logs. Glacier Instant Retrieval offers millisecond retrieval but is designed for long-lived data that is rarely accessed, and its retrieval per-GB fee makes it more expensive than Standard-IA for the frequent reads of recent logs. It also has a 90-day minimum storage duration, so moving 30-day-old logs in and then expiring them at 18 months is fine, but the immediate transition fails to optimize for the high first-30-day access pattern.

Trap 3: Enable versioning and rely on object lifecycle expiration to reduce…

Enabling versioning creates multiple copies of each object every time it is overwritten, which can increase storage costs rather than reduce them; lifecycle expiration simply deletes noncurrent versions after a set period, but the current versions of the logs remain in S3 Standard. Expiration alone does not transition data to a cheaper storage class, so you still pay the highest per-GB price for the entire 18-month retention period. Versioning is useful for protecting against accidental deletion, but it is not a cost optimization mechanism and sidesteps the real issue of selecting an appropriate storage class.

A
Leave logs in S3 Standard for 18 months and add a tag for internal reporting
Why it fails: Adding a tag is purely for metadata, reporting, and cost allocation; it does not change the underlying S3 storage class, so the logs still incur the full S3 Standard rate for all 18 months. Since application logs are rarely read after the first few weeks, keeping them in the most expensive storage class is wasteful. A lifecycle policy that moves cold logs to Standard-IA and then Deep Archive would achieve the same retention at a fraction of the cost.
B
Create an S3 lifecycle policy to transition logs to Standard-IA after 30 days and to Glacier Deep Archive after 180 days
This is correct because it matches storage cost to actual access frequency: logs are typically accessed heavily in the first 30 days, so S3 Standard is appropriate, after which Standard-IA reduces storage cost while still allowing rapid access. At 180 days, the logs are unlikely to be needed for active operations, so Glacier Deep Archive provides the lowest-cost storage while still satisfying the 18-month retention requirement. The lifecycle transitions honor S3's minimum storage duration constraints (30 days and 180 days), so no early-deletion fees are incurred.
C
Immediately move all logs to Glacier Instant Retrieval and expire after 18 months
Why it fails: Moving every log to Glacier Instant Retrieval immediately is problematic because it does not distinguish between hot logs from the recent 30 days and older, colder logs. Glacier Instant Retrieval offers millisecond retrieval but is designed for long-lived data that is rarely accessed, and its retrieval per-GB fee makes it more expensive than Standard-IA for the frequent reads of recent logs. It also has a 90-day minimum storage duration, so moving 30-day-old logs in and then expiring them at 18 months is fine, but the immediate transition fails to optimize for the high first-30-day access pattern.
D
Enable versioning and rely on object lifecycle expiration to reduce costs; do not change storage classes
Why it fails: Enabling versioning creates multiple copies of each object every time it is overwritten, which can increase storage costs rather than reduce them; lifecycle expiration simply deletes noncurrent versions after a set period, but the current versions of the logs remain in S3 Standard. Expiration alone does not transition data to a cheaper storage class, so you still pay the highest per-GB price for the entire 18-month retention period. Versioning is useful for protecting against accidental deletion, but it is not a cost optimization mechanism and sidesteps the real issue of selecting an appropriate storage class.

Question 2mediummultiple choice

A marketing site stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost?

Trap 1: Keep all logs in S3 Standard indefinitely

Keeping all logs in S3 Standard indefinitely forces you to pay the highest per-GB storage price even for objects that are rarely or never accessed after the first 30 days. S3 Standard is designed for frequently accessed, low-latency workloads, not for accumulating historical log data that is queried sporadically. Over months or years, the compounding storage costs become far greater than transitioning to lower-cost classes, and there is no retrieval fee savings because Standard incurs no retrieval charges—you simply pay premium storage for no benefit. This approach ignores the predictable pattern that log query frequency decays with age.

Trap 2: Use EBS snapshots for the logs

EBS snapshots are block-level backups of Amazon EBS volumes, not a native service for storing or querying individual log objects from S3. To use them, you would first need to copy logs into an EBS volume, then snapshot it, and later restore the entire volume to access any log—making object-level queries impractical and slow. Snapshots are incremental and stored in S3, but they are only accessible through Amazon EC2/EBS APIs, so you cannot use S3 storage classes, lifecycle policies, or object-level methods like Athena or S3 Select. This approach creates unnecessary operational complexity and incurs costs for EBS volume provisioning and snapshot storage, making it a poor fit for application log archival.

Trap 3: Move all logs immediately to S3 Glacier Deep Archive

Moving all logs immediately to S3 Glacier Deep Archive saves on storage costs but makes recent logs nearly impossible to query, because retrieval from Deep Archive can take up to 12–48 hours and incurs high per-GB retrieval fees. The site's requirement is to query logs for 30 days, so logs in the query window must be immediately accessible with low latency, which Deep Archive cannot provide. Using Deep Archive from day one would force you to restore lots of data for routine queries, racking up expensive retrieval costs and missing the 30-day query SLA. The correct approach is to let a lifecycle policy transition logs gradually, keeping hot logs in Standard or Standard-IA and moving only older logs to Deep Archive.

A
S3 lifecycle policy that transitions objects to lower-cost storage classes over time
An S3 lifecycle policy automates object transitions based on age, aligning storage cost with actual access patterns. Since logs are queried only for 30 days, rules can move older logs to S3 Standard-IA after 30 days, then to S3 Glacier Instant Retrieval or S3 Glacier Flexible Retrieval, and eventually to S3 Glacier Deep Archive for archival. This approach minimizes storage cost while keeping recent logs immediately accessible, and it requires no manual intervention. Lifecycle rules are evaluated daily per object, making them the ideal cost optimization mechanism for time-decaying log data.
B
Keep all logs in S3 Standard indefinitely
Why it fails: Keeping all logs in S3 Standard indefinitely forces you to pay the highest per-GB storage price even for objects that are rarely or never accessed after the first 30 days. S3 Standard is designed for frequently accessed, low-latency workloads, not for accumulating historical log data that is queried sporadically. Over months or years, the compounding storage costs become far greater than transitioning to lower-cost classes, and there is no retrieval fee savings because Standard incurs no retrieval charges—you simply pay premium storage for no benefit. This approach ignores the predictable pattern that log query frequency decays with age.
C
Use EBS snapshots for the logs
Why it fails: EBS snapshots are block-level backups of Amazon EBS volumes, not a native service for storing or querying individual log objects from S3. To use them, you would first need to copy logs into an EBS volume, then snapshot it, and later restore the entire volume to access any log—making object-level queries impractical and slow. Snapshots are incremental and stored in S3, but they are only accessible through Amazon EC2/EBS APIs, so you cannot use S3 storage classes, lifecycle policies, or object-level methods like Athena or S3 Select. This approach creates unnecessary operational complexity and incurs costs for EBS volume provisioning and snapshot storage, making it a poor fit for application log archival.
D
Move all logs immediately to S3 Glacier Deep Archive
Why it fails: Moving all logs immediately to S3 Glacier Deep Archive saves on storage costs but makes recent logs nearly impossible to query, because retrieval from Deep Archive can take up to 12–48 hours and incurs high per-GB retrieval fees. The site's requirement is to query logs for 30 days, so logs in the query window must be immediately accessible with low latency, which Deep Archive cannot provide. Using Deep Archive from day one would force you to restore lots of data for routine queries, racking up expensive retrieval costs and missing the 30-day query SLA. The correct approach is to let a lifecycle policy transition logs gradually, keeping hot logs in Standard or Standard-IA and moving only older logs to Deep Archive.

Question 3mediummultiple choice

A SaaS company uses an S3 bucket for database backups created daily. Backups are rarely restored; the company’s documented RTO is 24 hours, and the compliance policy requires backups be kept for 90 days. The team currently stores all backups in S3 Standard, which is costly.

Which single lifecycle policy change is most cost-optimized while still meeting the 24-hour RTO and 90-day retention?

Trap 1: Add a lifecycle rule to transition backups older than 1 day to S3…

While S3 Glacier Instant Retrieval offers immediate access, meeting the RTO, it is generally a more expensive storage class for data that is infrequently accessed, especially compared to Glacier Flexible Retrieval. For backups that are older than one day and expected to be rarely retrieved, the higher per-GB retrieval cost and storage cost of Instant Retrieval make it less cost-effective. This choice fails to optimize costs effectively when a cheaper alternative with an acceptable RTO exists.

Trap 2: Add a lifecycle rule to transition backups older than 1 day to S3…

S3 Glacier Deep Archive is designed for the lowest-cost archival storage, but its standard retrieval times typically range from 12 to 48 hours, with bulk retrievals taking up to 48 hours. This extended retrieval period directly conflicts with a strict 24-hour Recovery Time Objective (RTO), as there's no guarantee of data availability within the required timeframe. Therefore, despite meeting the 90-day retention, this storage class is unsuitable due to its potentially slow retrieval performance.

Trap 3: Add a lifecycle rule to transition backups older than 1 day to S3…

This option is fundamentally flawed because it specifies deleting backups after only 7 days, which directly violates the required 90-day data retention policy. While S3 One Zone-IA offers cost savings by storing data in a single Availability Zone, its primary drawback here is the insufficient retention period. The solution must ensure data is available for the full 90 days, making this lifecycle rule unacceptable.

A
Add a lifecycle rule to transition backups older than 1 day to S3 Glacier Flexible Retrieval, and keep them until day 90.
This option correctly leverages S3 Lifecycle rules to transition older, less frequently accessed backups to S3 Glacier Flexible Retrieval. This storage class provides significant cost savings compared to S3 Standard or S3-IA, while still supporting retrieval times measured in hours, which comfortably meets a 24-hour Recovery Time Objective (RTO). Maintaining retention until day 90 also satisfies the long-term data retention requirement efficiently.
B
Add a lifecycle rule to transition backups older than 1 day to S3 Glacier Instant Retrieval, and keep them until day 90.
Why it fails: While S3 Glacier Instant Retrieval offers immediate access, meeting the RTO, it is generally a more expensive storage class for data that is infrequently accessed, especially compared to Glacier Flexible Retrieval. For backups that are older than one day and expected to be rarely retrieved, the higher per-GB retrieval cost and storage cost of Instant Retrieval make it less cost-effective. This choice fails to optimize costs effectively when a cheaper alternative with an acceptable RTO exists.
C
Add a lifecycle rule to transition backups older than 1 day to S3 Glacier Deep Archive, and keep them until day 90 with no restore configuration.
Why it fails: S3 Glacier Deep Archive is designed for the lowest-cost archival storage, but its standard retrieval times typically range from 12 to 48 hours, with bulk retrievals taking up to 48 hours. This extended retrieval period directly conflicts with a strict 24-hour Recovery Time Objective (RTO), as there's no guarantee of data availability within the required timeframe. Therefore, despite meeting the 90-day retention, this storage class is unsuitable due to its potentially slow retrieval performance.
D
Add a lifecycle rule to transition backups older than 1 day to S3 One Zone-IA, and delete them after 7 days.
Why it fails: This option is fundamentally flawed because it specifies deleting backups after only 7 days, which directly violates the required 90-day data retention policy. While S3 One Zone-IA offers cost savings by storing data in a single Availability Zone, its primary drawback here is the insufficient retention period. The solution must ensure data is available for the full 90 days, making this lifecycle rule unacceptable.

Question 4easymultiple choice

A company stores user uploads in an S3 bucket. Objects are accessed rarely after upload, but when an object is accessed, it must be retrievable quickly (minutes to a few hours). Objects must be retained for at least 18 months. The team wants to reduce storage cost while meeting these requirements. Which lifecycle configuration best fits these requirements?

Trap 1: Keep all objects in S3 Standard permanently to avoid lifecycle…

Keeping objects in S3 Standard does not reduce storage cost. Lifecycle transitions are specifically designed to move infrequently accessed data to lower-cost storage classes after a delay. Even if there are per-transition request costs, the ongoing savings from using a cheaper storage class for the long retention period typically outweigh those transition request costs.

Trap 2: After 30 days, transition objects to S3 Intelligent-Tiering, and…

Intelligent-Tiering can reduce cost when access patterns are unpredictable, but the expiration setting must still meet the business retention requirement. Expiring at 12 months violates the requirement to retain objects for at least 18 months, so this option would fail compliance.

Trap 3: After 30 days, transition objects to S3 Glacier Deep Archive, and…

Deep Archive is generally the lowest-cost option for data that is extremely rarely accessed, but it has much slower restore times compared with Instant Retrieval. Because the prompt states that when accessed, objects must be retrievable quickly (minutes to a few hours), Deep Archive is not the best fit even though it would satisfy the 18-month retention requirement and would reduce cost.

A
Keep all objects in S3 Standard permanently to avoid lifecycle transition fees.
Why it fails: Keeping objects in S3 Standard does not reduce storage cost. Lifecycle transitions are specifically designed to move infrequently accessed data to lower-cost storage classes after a delay. Even if there are per-transition request costs, the ongoing savings from using a cheaper storage class for the long retention period typically outweigh those transition request costs.
B
After 30 days, transition objects to S3 Glacier Instant Retrieval, and after 18 months, expire (delete) the objects.
The prompt requires (1) cost reduction for data that becomes infrequently accessed and (2) quick retrieval when accessed again, and (3) a minimum retention of at least 18 months. Glacier Instant Retrieval is intended for data that is accessed occasionally and needs fast retrieval. Transitioning after 30 days moves the long-term, rarely accessed portion of the data to a cheaper class, while expiring at 18 months satisfies the explicit retention requirement (the objects remain for at least 18 months).
C
After 30 days, transition objects to S3 Intelligent-Tiering, and set expiration to 12 months.
Why it fails: Intelligent-Tiering can reduce cost when access patterns are unpredictable, but the expiration setting must still meet the business retention requirement. Expiring at 12 months violates the requirement to retain objects for at least 18 months, so this option would fail compliance.
D
After 30 days, transition objects to S3 Glacier Deep Archive, and set expiration to 18 months.
Why it fails: Deep Archive is generally the lowest-cost option for data that is extremely rarely accessed, but it has much slower restore times compared with Instant Retrieval. Because the prompt states that when accessed, objects must be retrievable quickly (minutes to a few hours), Deep Archive is not the best fit even though it would satisfy the 18-month retention requirement and would reduce cost.

Question 5easymultiple choice

A company keeps daily database backups in an S3 bucket. They may restore from backups during the first 30 days if there is an issue. After 30 days, backups are rarely restored, but must be retained for 2 years. Which lifecycle strategy most cost-effectively meets these requirements?

Trap 1: Delete backups after 30 days to avoid storage costs, since restores…

Deleting backups after 30 days would violate the stated requirement to retain database backups for 2 years, likely breaking regulatory or business continuity obligations. Even if restores are rare, backups serve disaster recovery and audit needs; premature deletion means data can be permanently lost if a corruption is discovered later. S3 Lifecycle rules should never delete data before the retention window expires, and this option offers no path to meet the compliance mandate.

Trap 2: Keep all backups in S3 Standard for the entire 2-year retention…

Keeping all backups in S3 Standard for two years is unnecessarily expensive because S3 Standard offers high availability and low-latency access that are not needed for backups that are accessed rarely after the first month. Over a 24-month period, the per-GB storage cost of S3 Standard is roughly six times that of S3 Glacier Deep Archive, so this approach wastes significant budget without any compliance or operational benefit. S3 Lifecycle policies exist specifically to avoid this over-provisioning by transitioning data to appropriate storage classes over time.

Trap 3: Move backups to S3 Glacier Deep Archive immediately after creation,…

Immediately moving backups to S3 Glacier Deep Archive ignores the operational need for rapid restoration during the first 30 days; Deep Archive has a retrieval time of up to 12 hours, which is unacceptable for a recent backup that might be needed for urgent recovery. Additionally, S3 Glacier Deep Archive has a minimum storage duration of 90 days, so if you need to delete or move an object sooner, you'll incur an early-deletion charge. A lifecycle policy that delays the transition to Deep Archive balances both fast initial recovery and long-term cost efficiency.

A
Delete backups after 30 days to avoid storage costs, since restores are rare.
Why it fails: Deleting backups after 30 days would violate the stated requirement to retain database backups for 2 years, likely breaking regulatory or business continuity obligations. Even if restores are rare, backups serve disaster recovery and audit needs; premature deletion means data can be permanently lost if a corruption is discovered later. S3 Lifecycle rules should never delete data before the retention window expires, and this option offers no path to meet the compliance mandate.
B
Keep all backups in S3 Standard for the entire 2-year retention period.
Why it fails: Keeping all backups in S3 Standard for two years is unnecessarily expensive because S3 Standard offers high availability and low-latency access that are not needed for backups that are accessed rarely after the first month. Over a 24-month period, the per-GB storage cost of S3 Standard is roughly six times that of S3 Glacier Deep Archive, so this approach wastes significant budget without any compliance or operational benefit. S3 Lifecycle policies exist specifically to avoid this over-provisioning by transitioning data to appropriate storage classes over time.
C
Use an S3 lifecycle policy to keep backups in S3 Standard for 30 days, then transition them to S3 Glacier Deep Archive for the remainder of the 2-year retention period.
This is correct because an S3 Lifecycle policy can automate the transition of objects after a specified number of days. Storing backups in S3 Standard for the first 30 days ensures rapid restoration during the period when failures are most likely to be detected, then transitioning to S3 Glacier Deep Archive for the remaining ~23 months meets the 2-year retention requirement at drastically lower storage cost. Lifecycle transitions are metadata operations, so they incur no retrieval charge, making this the most cost-effective and compliant approach.
D
Move backups to S3 Glacier Deep Archive immediately after creation, even for the first 30 days.
Why it fails: Immediately moving backups to S3 Glacier Deep Archive ignores the operational need for rapid restoration during the first 30 days; Deep Archive has a retrieval time of up to 12 hours, which is unacceptable for a recent backup that might be needed for urgent recovery. Additionally, S3 Glacier Deep Archive has a minimum storage duration of 90 days, so if you need to delete or move an object sooner, you'll incur an early-deletion charge. A lifecycle policy that delays the transition to Deep Archive balances both fast initial recovery and long-term cost efficiency.

Question 6mediummultiple choice

A marketing site stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost? The architecture review board prefers a managed AWS-native control.

Trap 1: Keep all logs in S3 Standard indefinitely

Keeping all logs in S3 Standard indefinitely ignores that only the first 30 days need frequent, low-latency access; Standard's per-gigabyte price is the highest among S3 storage classes. For data that becomes archival after a month, paying Standard rates for months or years creates avoidable storage spend. A lifecycle policy would move these objects to cheaper classes automatically, so indefinite Standard is neither cost-efficient nor operationally necessary.

Trap 2: Use EBS snapshots for the logs

EBS snapshots capture block-level copies of an entire EBS volume, not individual log objects, so they would require restoring an entire volume before searching logs and cannot be queried with S3 APIs or services like Athena. They are designed for EC2 disaster recovery and backup, not for appending object logs. Using snapshots for logs would be far more complex and costly than object lifecycle policies, and snapshots do not offer per-object transition tiers.

Trap 3: Move all logs immediately to S3 Glacier Deep Archive

Moving all logs immediately to S3 Glacier Deep Archive would make recent logs unavailable for the 30-day query window because retrieval can take up to 12 hours and requires a restore request. It also incurs a 180-day minimum storage duration and high retrieval costs, penalizing early deletion or frequent access. Querying logs in that class is impractical, whereas lifecycle transitions keep recent data hot and only archive older logs.

A
S3 lifecycle policy that transitions objects to lower-cost storage classes over time
An S3 Lifecycle policy can automate age-based transitions from S3 Standard to S3 Standard-IA and then to Glacier classes, aligning storage costs with the 30-day query pattern. Because log files are queried most heavily when new and rarely when old, transitioning older objects to lower-cost storage maintains S3 API access while reducing spend. Lifecycle rules are the recommended mechanism for this optimization, with no manual intervention or infrastructure changes.
B
Keep all logs in S3 Standard indefinitely
Why it fails: Keeping all logs in S3 Standard indefinitely ignores that only the first 30 days need frequent, low-latency access; Standard's per-gigabyte price is the highest among S3 storage classes. For data that becomes archival after a month, paying Standard rates for months or years creates avoidable storage spend. A lifecycle policy would move these objects to cheaper classes automatically, so indefinite Standard is neither cost-efficient nor operationally necessary.
C
Use EBS snapshots for the logs
Why it fails: EBS snapshots capture block-level copies of an entire EBS volume, not individual log objects, so they would require restoring an entire volume before searching logs and cannot be queried with S3 APIs or services like Athena. They are designed for EC2 disaster recovery and backup, not for appending object logs. Using snapshots for logs would be far more complex and costly than object lifecycle policies, and snapshots do not offer per-object transition tiers.
D
Move all logs immediately to S3 Glacier Deep Archive
Why it fails: Moving all logs immediately to S3 Glacier Deep Archive would make recent logs unavailable for the 30-day query window because retrieval can take up to 12 hours and requires a restore request. It also incurs a 180-day minimum storage duration and high retrieval costs, penalizing early deletion or frequent access. Querying logs in that class is impractical, whereas lifecycle transitions keep recent data hot and only archive older logs.

Question 7mediummultiple choice

A test environment stores logs in S3. Logs are queried for 30 days, rarely accessed for one year, and then retained for compliance. What should reduce storage cost?

Trap 1: Keep all logs in S3 Standard indefinitely

Keeping all logs in S3 Standard indefinitely ignores the cost-to-access tradeoff: S3 Standard charges the highest per-GB storage fee because it is designed for frequently accessed data with millisecond retrieval. Logs older than the 30-day query window are rarely read, so retaining them at Standard tier for months or years means paying premium prices for cold data. A lifecycle policy reduces this waste by automatically transitioning those objects to lower-cost tiers as they age, which is exactly what this scenario requires.

Trap 2: Move all logs immediately to S3 Glacier Deep Archive

Moving all logs immediately to S3 Glacier Deep Archive is both impractical and counterproductive for a 30-day query window. Deep Archive has a retrieval time of up to 12 hours and charges a per-GB retrieval fee, so recent logs—which are the ones being queried—would become slow and expensive to access. Moreover, S3 lifecycle rules cannot transition objects to Deep Archive until 180 days after creation, so an immediate transition is not even possible; you would have to stage the transition manually, defeating the purpose of automation.

Trap 3: Use EBS snapshots for the logs

EBS snapshots are a block-level backup mechanism for Amazon EC2 volumes, not a native storage service for individual application log objects. Logs typically arrive as many small, write-once objects that need to be queried using object APIs or services like Athena, but EBS snapshots do not expose object-level access or support S3 lifecycle management. Using snapshots for logs would require creating a volume, copying files into it, taking snapshots, and then attempting to restore and parse them for queries—an inefficient, high-cost model that does not align with S3's object storage capabilities.

A
Keep all logs in S3 Standard indefinitely
Why it fails: Keeping all logs in S3 Standard indefinitely ignores the cost-to-access tradeoff: S3 Standard charges the highest per-GB storage fee because it is designed for frequently accessed data with millisecond retrieval. Logs older than the 30-day query window are rarely read, so retaining them at Standard tier for months or years means paying premium prices for cold data. A lifecycle policy reduces this waste by automatically transitioning those objects to lower-cost tiers as they age, which is exactly what this scenario requires.
B
Move all logs immediately to S3 Glacier Deep Archive
Why it fails: Moving all logs immediately to S3 Glacier Deep Archive is both impractical and counterproductive for a 30-day query window. Deep Archive has a retrieval time of up to 12 hours and charges a per-GB retrieval fee, so recent logs—which are the ones being queried—would become slow and expensive to access. Moreover, S3 lifecycle rules cannot transition objects to Deep Archive until 180 days after creation, so an immediate transition is not even possible; you would have to stage the transition manually, defeating the purpose of automation.
C
S3 lifecycle policy that transitions objects to lower-cost storage classes over time
An S3 lifecycle policy is the correct solution because it lets you automate storage class transitions based on object age: for example, keep logs in S3 Standard for the first 30 days for active queries, then transition them to S3 Standard-IA or S3 Glacier Instant Retrieval for cheaper long-term storage. Lifecycle rules can chain multiple transitions, so you can progressively move objects to even colder classes (e.g., Glacier Flexible Retrieval) after 90 or 180 days. This matches storage cost to actual access patterns while maintaining the ability to retrieve logs when needed, without manual operations or expensive ingestion-time decisions.
D
Use EBS snapshots for the logs
Why it fails: EBS snapshots are a block-level backup mechanism for Amazon EC2 volumes, not a native storage service for individual application log objects. Logs typically arrive as many small, write-once objects that need to be queried using object APIs or services like Athena, but EBS snapshots do not expose object-level access or support S3 lifecycle management. Using snapshots for logs would require creating a volume, copying files into it, taking snapshots, and then attempting to restore and parse them for queries—an inefficient, high-cost model that does not align with S3's object storage capabilities.

Question 8easymultiple choice

A team stores application logs in Amazon S3. They need access to the logs only occasionally for troubleshooting (infrequent access), and they want to reduce storage cost automatically over time without manually moving objects. What should they implement?

Trap 1: An S3 lifecycle policy that deletes objects after 1 day to…

Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.

Trap 2: An S3 lifecycle policy that keeps all objects in S3 Standard and…

Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.

Trap 3: A policy that changes bucket encryption from SSE-S3 to SSE-KMS to…

Switching from SSE-S3 to SSE-KMS will not lower S3 storage costs; in fact, it typically increases them because AWS KMS incurs per-request charges for encrypt and decrypt operations and a monthly key fee. S3 storage class pricing is determined by the amount of data stored and the access/retrieval rates, not by the encryption mechanism. Since the logs are infrequently accessed, the correct approach is to transition objects into a cheaper storage class via lifecycle rules, not to change encryption to a costlier KMS option.

A
An S3 lifecycle policy that transitions objects to a lower-cost storage class after a set number of days
S3 lifecycle policies can automatically transition objects based on age to storage classes priced for infrequent access (for example, Standard-IA or Glacier-based classes). This preserves the data for later troubleshooting while lowering storage cost as objects become older.
B
An S3 lifecycle policy that deletes objects after 1 day to eliminate storage costs
Why it fails: Deleting after 1 day would remove data before it can be used for occasional troubleshooting. Storage cost optimization must still respect retention and troubleshooting requirements; lifecycle rules should transition to cheaper classes rather than delete immediately unless deletion is explicitly acceptable.
C
An S3 lifecycle policy that keeps all objects in S3 Standard and only applies compression at read time
Why it fails: Staying in S3 Standard does not address the cost driver (storage class pricing based on access frequency). “Compression at read time” is not an S3 lifecycle storage class optimization mechanism and would not directly lower S3 storage class charges as requested.
D
A policy that changes bucket encryption from SSE-S3 to SSE-KMS to reduce storage cost
Why it fails: Switching from SSE-S3 to SSE-KMS will not lower S3 storage costs; in fact, it typically increases them because AWS KMS incurs per-request charges for encrypt and decrypt operations and a monthly key fee. S3 storage class pricing is determined by the amount of data stored and the access/retrieval rates, not by the encryption mechanism. Since the logs are infrequently accessed, the correct approach is to transition objects into a cheaper storage class via lifecycle rules, not to change encryption to a costlier KMS option.

Question 9easymultiple choice

An S3 bucket stores application logs. After 30 days, the team rarely accesses the logs, but compliance requires keeping them for 18 months. Which setup most directly reduces storage cost while maintaining compliance?

Trap 1: Enable S3 Versioning and rely on deleting old versions after 30…

Versioning changes how objects are stored but does not inherently implement a deterministic “keep for 18 months” retention rule for all log data. You could still violate compliance if deletes/version retention are not aligned with the required retention window.

Trap 2: Move the bucket to a different AWS region farther from the users to…

Moving the bucket to a different region does not reduce S3 storage cost for the data itself; pricing is region-specific and not based on distance from users. Cross-region data transfer and potential replication fees would increase total expenses, and a distant region could have a higher per-GB rate. Critically, changing regions does nothing to automate the required 18-month retention or deletion of log objects, leaving the compliance requirement unaddressed.

Trap 3: Switch all objects to S3 Glacier Instant Retrieval immediately,…

Applying Glacier Instant Retrieval to all objects immediately ignores the noted 30-day active-access period; that storage class is designed for infrequently accessed data and carries per-request retrieval fees plus a 90-day minimum storage duration that would make short-lived recent logs more costly than S3 Standard. The option also lacks an expiration action, so it does not enforce the 18-month retention and deletion requirement. A lifecycle policy that transitions by age and expires after 18 months is the correct application of cold storage.

A
Configure an S3 Lifecycle policy to transition objects to a colder storage class after 30 days and expire (delete) them after 18 months.
This lifecycle policy is the right approach because it automatically transitions 30-day-old log objects to a lower-cost storage class — such as S3 Standard-IA or S3 Glacier Instant Retrieval — which directly matches the noted shift in access pattern after the first 30 days. The separate expiration action after 18 months enforces the compliance requirement to retain logs for exactly that period and then delete them, preventing both premature deletion and runaway storage growth. Lifecycle transitions are managed by S3, so the team does not need custom code to move or expire objects.
B
Enable S3 Versioning and rely on deleting old versions after 30 days to reduce storage costs while keeping the latest data.
Why it fails: Versioning changes how objects are stored but does not inherently implement a deterministic “keep for 18 months” retention rule for all log data. You could still violate compliance if deletes/version retention are not aligned with the required retention window.
C
Move the bucket to a different AWS region farther from the users to reduce the likelihood of accidental reads and thereby lower storage costs.
Why it fails: Moving the bucket to a different region does not reduce S3 storage cost for the data itself; pricing is region-specific and not based on distance from users. Cross-region data transfer and potential replication fees would increase total expenses, and a distant region could have a higher per-GB rate. Critically, changing regions does nothing to automate the required 18-month retention or deletion of log objects, leaving the compliance requirement unaddressed.
D
Switch all objects to S3 Glacier Instant Retrieval immediately, regardless of object age, to minimize storage charges.
Why it fails: Applying Glacier Instant Retrieval to all objects immediately ignores the noted 30-day active-access period; that storage class is designed for infrequently accessed data and carries per-request retrieval fees plus a 90-day minimum storage duration that would make short-lived recent logs more costly than S3 Standard. The option also lacks an expiration action, so it does not enforce the 18-month retention and deletion requirement. A lifecycle policy that transitions by age and expires after 18 months is the correct application of cold storage.