Task 2.2: Configuring individual storage systems.

• AObject Versioning with a lifecycle rule that keeps noncurrent versions

  Incorrect

  Versioning keeps old copies, but an administrator can still delete versions or change the lifecycle rule.

• BA bucket retention policy of seven years that is locked with Bucket Lock

  Correct

  A retention policy blocks deletion and overwriting of objects until they reach the retention age, and locking it makes the policy permanent so nobody can remove or shorten it.

• CSoft delete on the bucket with the longest available retention duration

  Incorrect

  Soft delete keeps deleted objects restorable for 7 to 90 days at most, far short of seven years, and the policy can be changed.

• DA lifecycle rule that moves every object to Archive storage after one day

  Incorrect

  Archive storage lowers cost but adds no protection against deletion or overwriting.

Write-once retention for compliance is what Bucket Lock is for: a locked retention policy cannot be removed or reduced, and objects cannot be deleted or replaced until they are old enough.

• ASet a table expiration of 90 days on the table

  Incorrect

  A table expiration deletes the whole table, including recent data, when it is reached.

• BRun a scheduled query that deletes old rows nightly

  Incorrect

  It works, but it adds a job to run and pay for when a table setting does the same.

• CRely on long-term storage pricing after 90 days

  Incorrect

  Long-term storage only lowers the price of unchanged data; it removes nothing.

• DSet a partition expiration of 90 days on the table

  Correct

  With a partition expiration, BigQuery deletes each daily partition automatically when it reaches the set age, while the table stays in place.

Data lifecycle for partitioned tables is a table property: partition expiration drops old partitions on its own without affecting queries on recent data.

• AA lifecycle rule that moves every object to Archive after 30 days

  Incorrect

  Archive has retrieval costs and a long minimum storage duration, which hurt when old content becomes popular again.

• BStandard storage for every object, with Object Versioning enabled

  Incorrect

  Keeping everything in Standard misses the savings on rarely watched content, and versioning adds storage.

• CNearline as the default storage class for every new upload

  Incorrect

  New uploads are watched heavily at first, and Nearline charges for that retrieval.

• DEnable Autoclass on the buckets that store the media library

  Correct

  Autoclass moves each object to a colder class when it is not accessed and back to Standard when it is, which suits unpredictable access.

When access patterns cannot be predicted, Autoclass manages storage classes per object, balancing the cost of cold storage against the cost of reading it.

• AGrant allUsers the Storage Object Viewer role on the whole course bucket

  Incorrect

  This makes every video public to anyone, paying or not, with no time limit.

• BGrant each customer's email address an IAM role on the bucket

  Incorrect

  IAM grants need a Google identity, which these customers do not have, and they do not expire on their own.

• CGenerate a V4 signed URL for each video that expires after 15 minutes

  Correct

  A signed URL gives anyone who holds it time-limited access to one object, with no Google account needed.

• DGive each customer an HMAC key for the platform's service account

  Incorrect

  HMAC keys are long-lived credentials for the account, not a way to share one object briefly.

Security and access management for object storage includes temporary, scoped access. Signed URLs are the standard way to let unauthenticated users read or write one object for a limited time.

• AA read replica for the analysts, so reports run off the primary

  Correct

  Read replicas copy the primary and take read-only work such as reporting, so the primary keeps its capacity for orders.

• BHigh availability on the instance, pointing the reports at the standby

  Incorrect

  The HA standby does not serve queries; it only takes over when the primary fails.

• CA larger machine type for the primary to absorb both workloads

  Incorrect

  Scaling up may help for a while, but both workloads still compete on one instance.

• DAutomatic storage increases on the primary instance's data disk

  Incorrect

  Disk capacity is not the bottleneck here, and the setting does not separate reporting from orders.

Storage systems should be configured for their access patterns. Moving read-heavy reporting to replicas scales reads without degrading the primary's transactional work.

• AObject Versioning on every bucket in the organization

  Incorrect

  Versioning keeps older copies of objects; it does nothing about who can read them.

• BSigned URLs for each object that users must reach

  Incorrect

  Signed URLs grant temporary access; they do not remove existing ACLs or block public grants.

• CUniform bucket-level access on the buckets

  Correct

  With uniform bucket-level access, ACLs are disabled and only bucket-level IAM grants access to the bucket and its objects.

• DCustomer-managed encryption keys on the buckets

  Incorrect

  Encryption keys do not stop someone with public read access from reading objects.

• EThe public access prevention organization policy

  Correct

  Enforcing public access prevention through the organization policy constraint blocks public access to buckets throughout the organization.

Securing object storage at scale means one access model (IAM through uniform bucket-level access) and a guardrail that stops public exposure (public access prevention).