I believe the Answer is C not B. This isn't data which needs to be analyzed, so I don't understand why would it be stored in BQ when having data stored in GCS seems much more reasonable. I think the only thing about answer C which throws me off is the fact that they don't mention object life cycle management

Bucket lock and TTL are the key features of Cloud Storage.

Cloud Storage life cycle management

Answer is C

B is correct, all forgot this "Data that has not yet reached the time period should not be deleted." from question this means data is keep on updating if we enforce TTL for a bucker the whole bucket will be deleted including updated data, so with Big query we do updating using pipeline jobs and delete data using expiration time

store it in a bucket for TTL

CS does not delete promptly , hence BQ as it is sensitive data

Life Cycle Management for Cloud storage is used to manage the Storage class to save cost. For data management, you have set retention time on the bucket. I will opt for B as the correct answer.

Correct Answer: C

I would go for C, but all the 4 answers are in my opinion incomplete. all of them say "single" bucket or table, which means that if different dated rows/elements are stored in the same bucket or table, they will expire together and be deleted probably before their real expiration time. so i expected to see partitioning or multiple bucket.

Outdated question again- should be bucket locks now.

Ans : C

Ans - C

Correct Answer: C

The answers need to be worded better. If we're taking the terms literally as specified in the options, then C cannot be the correction answer since there's no Time to Live configuration for a GCS bucket, only Lifecycle Policy. With BigQuery, there is no row-level expiration, although we could create this behavior using Partitioned Tables. So this could be a potential answer. D - it is possible to simulate cell-level TTL (https://cloud.google.com/bigtable/docs/gc-cell-level), so this too could be a potential answer, especially when different cells need different TTLs. Betweem B & D, BigQuery follows a pay-as-you-go model and its storage costs are comparable to GCS storage costs. So this would be the more appropriate solution.

I believe B is correct. Setting a TTL of 14 days on the bucket via LifeCycle will not cause the bucket itself to be deleted after 14 days, instead it will cause each object uploaded to that bucket to be deleted 14 days after it was created