Google ACE Practice Question: A team stores application log archives in a Cloud…

Answer analysis

Option-by-option breakdown

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

• ✗

  Cloud Scheduler jobs that run gsutil rewrite and gsutil rm commands nightly

  Why it's wrong here

  A nightly Cloud Scheduler job executing `gsutil rewrite` and `gsutil rm` would require you to build and maintain crontab-like infrastructure, write object-aging queries, and manually identify which objects are past 90 or 365 days. Running `gsutil rewrite` also incurs data-access and network costs for every object rewritten between storage classes. This approach is brittle and unnecessary because Cloud Storage's native lifecycle management performs the same age-based transitions and deletions declaratively, with no custom scripts, no servers to patch, and no per-run compute costs.

• ✓

  Cloud Storage Object Lifecycle Management rules on the bucket

  Why this is correct

  Cloud Storage Object Lifecycle Management lets you define rules at the bucket level, for example an action to set the storage class to Coldline when `age` is 90 days, and a delete action when `age` is 365 days. These rules are evaluated asynchronously by Google Cloud for all current and future objects, so you get automatic, fully managed transition and deletion behavior without any external triggers. This is the intended mechanism for exactly this requirement, and it is both simpler and more reliable than any custom event-driven or scheduler-based solution.

• ✗

  Cloud Pub/Sub notifications triggering a Cloud Function on each object creation

  Why it's wrong here

  A Pub/Sub notification is emitted when an object is created, and a Cloud Function can immediately react to that object, but this event-driven model has no built-in knowledge of an object's age or a future timeline. You would need to write custom code to persist timestamps and schedule follow-up operations 90 or 365 days later, and any objects already in the bucket before the function is deployed would never be processed. Lifecycle rules, by contrast, continuously evaluate all objects against their age conditions and operate fully server-side.

• ✗

  Retention policies that lock objects in Coldline after 90 days

  Why it's wrong here

  Retention policies (including Bucket Lock) enforce a minimum retention duration for objects — they prevent deletion before a specified time, but they do not change storage class automatically. Applying a 90-day retention policy on a Coldline bucket would not transition objects to Coldline; it would merely forbid deleting them for 90 days. Since the goal is to move objects at 90 days and delete at 365 days, retention policies lack both the transition action and the deletion scheduling capability, and an overly long retention period would actively prevent the 365-day deletion.

Go deeper

Related to this question