CLF-C02 Cloud Technology and Services 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.

• ✗

  S3 Versioning

  Why it's wrong here

  S3 Versioning is designed for data protection, preserving every version of an object so that accidental deletions or overwrites can be recovered. While lifecycle policies can act on specific versions (for example, transitioning noncurrent versions to Glacier or expiring them), the versioning feature itself performs no storage-class transitions and no cost-optimization actions. It only retains copies, so it is not the service that automatically reprioritizes data into cheaper storage.

• ✓

  S3 Lifecycle policy

  Why this is correct

  S3 Lifecycle policies are the native rule-based engine for automating storage-class transitions and expirations. You define rules such as 'move objects to S3 Standard-IA after 30 days, then to S3 Glacier Flexible Retrieval after 120 days,' and S3 enforces them continuously without manual effort. Lifecycle also handles expiring old object versions and incomplete multipart uploads, making it both a cost-optimization and a governance tool. For any exam scenario that says 'move to cheaper storage after X days,' this is the correct answer.

• ✗

  S3 Intelligent-Tiering

  Why it's wrong here

  S3 Intelligent-Tiering is itself a storage class, not a lifecycle rule. It automatically shifts individual objects between frequent and infrequent access tiers based on real-time usage, and optionally to archive tiers, but those moves happen internally within the Intelligent-Tiering class. You do not specify day-based transitions to specific destinations like Glacier; for that explicit, policy-driven control you need a lifecycle policy. So while it automates tiering, it cannot implement the custom chronological rules described in the question.

• ✗

  S3 Event Notification

  Why it's wrong here

  S3 Event Notifications are asynchronous notifications that fire on bucket events such as PUT, DELETE, or restore-object completion, and they can trigger AWS Lambda functions or send messages to SNS and SQS. They are commonly used for event-driven processing workflows, security automation, or monitoring. Unlike lifecycle policies, event notifications contain no logic to move data between storage classes; they merely inform other services that something happened. To automate storage tiers, you would still need a lifecycle policy (or custom Lambda code), so this is not the right feature.

Go deeper

Related to this question