Match the class to the access pattern and the retrieval tolerance. Frequent access stays standard; unpredictable patterns suit intelligent tiering, which moves objects automatically for a small monitoring fee. Infrequent access classes are cheaper to store but charge for retrieval and have minimum durations, and archive classes are cheapest with retrieval delays. Use lifecycle rules to transition and expire, including old versions, and check the object count first.
Why interviewers ask this
This is a cost engineering question with real traps. The interviewer wants to know whether you understand minimum storage durations, retrieval charges, and the fact that transitioning millions of tiny objects can cost more in request charges than it saves. They also look for whether you remember non current versions and incomplete uploads, which quietly accumulate and dominate a lot of storage bills.
How to structure your answer
- Anchor the choice in access pattern and retrieval tolerance.
- Name the trade offs: retrieval fees and minimum durations.
- Warn about the small object transition trap.
- Cover versioning cleanup and expiring incomplete uploads.
Example answer
I look at how often the data is read and how long the reader can wait. Hot data stays in standard. If nobody can tell me the access pattern, intelligent tiering is the honest answer, because it moves objects for you and the monitoring fee is small compared to guessing wrong. Data I know is rarely read goes to an infrequent access class, but only if it will live past the minimum duration, otherwise the early deletion charge eats the saving. Archive classes are for compliance retention where a retrieval delay of minutes or hours is acceptable. The trap I check for before writing any lifecycle rule is object count, because transitions are charged per object, so a bucket of two hundred million tiny log files can cost more to move than it saves; those should be aggregated instead. And the biggest wins are usually not the class at all. Turning on expiry for non current versions in a versioned bucket, and aborting incomplete multipart uploads after a week, have each cut a bucket bill by half for me without touching a single live object.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What happens if you transition an object then delete it after a week?
- How would you find out what is actually accumulating in a large bucket?
- How do lifecycle rules interact with object lock or legal holds?
Related cloud engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions