SOA-C02 Cost and Performance Optimization Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Configure a lifecycle policy to delete incomplete multipart uploads after 7 days

  Why this is correct

  A lifecycle rule with the 'Incomplete multipart upload' action (e.g., days after initiation = 7) automatically aborts and deletes all parts of any multipart upload that was not completed due to network failure, timeout, or user cancellation. Because S3 bills for every stored part of an incomplete upload just like a full object, leaving these orphaned parts accrues storage costs indefinitely. Setting a 7-day expiration ensures orphaned data is removed without requiring manual intervention, directly reducing storage waste from failed uploads. This is a native S3 cost-control mechanism, not a data-protection feature.

• ✗

  Enable S3 Object Lock to prevent deletion

  Why it's wrong here

  S3 Object Lock enforces a Write-Once-Read-Many (WORM) model through retention periods or legal holds, preventing object deletion or overwrites for compliance. While this protects data from accidental or malicious deletion, it does not lower storage costs; instead, it can increase them because objects in a locked state cannot be removed even if they are stale or unneeded. Additionally, Object Lock is often used with S3 Versioning, which means every version of an object is also retained and billable. Therefore, enabling Object Lock directly contradicts a storage-cost reduction goal.

• ✓

  Create a lifecycle policy to transition objects to S3 Standard-IA after 90 days

  Why this is correct

  Transitioning objects to S3 Standard-IA after 90 days reduces monthly per-GB storage charges, because Standard-IA costs roughly half of S3 Standard for storage while still providing millisecond access. Media files are typically accessed frequently right after upload (e.g., editing, streaming) but become rarely accessed over time, so a 90-day interval aligns with the access-pattern shift. Note that S3 Standard-IA charges a retrieval fee per GB and requires a minimum of 128 KB per object, so the policy is cost-effective only if the objects are indeed larger and rarely read. This is a lifecycle transition rule, which is the appropriate way to optimize storage costs.

• ✗

  Enable S3 Versioning to keep multiple versions

  Why it's wrong here

  Enabling S3 Versioning stores every overwrite or delete as a new version, preserving the current version and all previous versions. Each version consumes the full size of the object in storage, so if a file is updated frequently, storage consumption multiplies without adding value unless you use lifecycle rules to expire noncurrent versions. The feature alone does not optimize storage costs; it actually increases them, especially for media files that are large and possibly updated. To minimize costs, you would instead need a lifecycle policy that purges old versions while keeping only recent ones, which is not mentioned.

• ✗

  Enable Requester Pays on the bucket

  Why it's wrong here

  Requester Pays is a bucket-level setting that makes the requester (instead of the bucket owner) pay the cost of data transfer requests, specifically for data download and API requests. It does not shift or reduce the underlying storage costs for hosting the media files; the bucket owner still pays per-GB per-month for storage of the objects. This feature is intended for shared datasets to discourage excessive downloads or to offset network egress expenses, not to address the storage footprint of media files. Therefore, it cannot optimize storage costs.

Go deeper

Related to this question