SOA-C02 Cost and Performance Optimization Practice Question

A company uses a centralized logging solution with Amazon OpenSearch Service. The log volume has grown significantly, increasing costs. The logs are retained for 90 days for compliance, but only the last 30 days are frequently accessed. Which combination of actions would reduce costs without compromising compliance?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Migrate indices older than 30 days to UltraWarm nodes.

Migrating indices older than 30 days to UltraWarm nodes reduces storage costs because UltraWarm provides cost-effective storage for infrequently accessed data. This retains data for the full 90-day compliance period while keeping the last 30 days in hot storage for fast access. Option A is incorrect because moving logs to S3 Glacier would make querying impractical and is not designed for OpenSearch. Option B is incorrect because increasing data nodes would increase costs without addressing storage optimization. Option D is incorrect because deleting indices after 30 days would violate the 90-day retention requirement.

Answer analysis

Option-by-option breakdown

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

✗
Move the logs to Amazon S3 Glacier and use a Lambda function to query them.
Why it's wrong here
Moving the logs to Amazon S3 Glacier removes them from the OpenSearch Service cluster, but S3 Glacier does not support direct indexing or querying by OpenSearch; you would need to initiate a restore request and wait for hours before objects become available in S3 for Lambda to read. This introduces unacceptable retrieval latency and would break the centralized, near-real-time logging solution, because logs older than 30 days still need to be searchable within seconds. Additionally, Lambda cannot directly query Glacier objects and has no native integration for running OpenSearch query syntax against archived data, so the logging solution would lose its core search capability.
✗
Increase the number of data nodes to improve indexing performance.
Why it's wrong here
Scaling out by adding more data nodes would increase the cluster's CPU and memory capacity for indexing operations, but that comes with higher per-instance costs and larger EBS storage costs, which is exactly the opposite of the goal to reduce spending. The performance bottleneck is irrelevant here because the logs older than 30 days are not heavily indexed or queried; they simply need to remain stored and occasionally searched. A better capacity decision is to transition those older indices to UltraWarm, which uses a different, cheaper storage tier rather than provisioning additional hot data nodes.
✓
Migrate indices older than 30 days to UltraWarm nodes.
Why this is correct
UltraWarm nodes in Amazon OpenSearch Service provide a warm storage tier that is dramatically cheaper per GiB than hot storage but still fully searchable, because it uses a combination of Amazon S3 and a small caching layer. By creating an Index State Management (ISM) policy that moves indices older than 30 days to UltraWarm, the company retains the ability to query compliance-related logs without paying for high-performance EBS-backed hot nodes. This meets both the cost-reduction and the 90-day compliance/retention requirements, since the data remains accessible and the policy can later delete or transition it as needed.
✗
Configure an index lifecycle policy to delete indices older than 30 days.
Why it's wrong here
Configuring an index lifecycle policy to delete indices older than 30 days would permanently remove the log data after one month, making it impossible to answer audits or compliance investigations that require 90 days of retention. ISM delete actions are irreversible and cannot be queried later, unlike transitioning to UltraWarm, which preserves the data in a lower-cost searchable tier. This option directly conflicts with the stated compliance requirement and would create a gap in the centralized logging history, so it is not a valid cost-reduction strategy.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SOA-C02 Cost and Performance Optimization Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question