Google Cloud / Intermediate: Service Contracts and Operations / Lesson 8

Cloud Storage Objects and Access

Design object identity, access, consistency, lifecycle, and concurrency without treating a bucket as a general-purpose filesystem.

About 5 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish buckets, objects, generations, and metadata.
Explain access controls and consistency boundaries.
Use preconditions and retention policies deliberately.

An object store has its own data contract

Cloud Storage stores objects in buckets with documented location, storage-class, and access choices. An object name and generation identify data versions under the product contract. Prefix-shaped names do not automatically supply every directory or POSIX filesystem behavior. Hierarchical namespace and managed-folder features have specific support and semantics that must be checked rather than assumed from slashes in a name.

Choose object storage for suitable immutable or replace-as-a-unit data patterns. Concurrent application updates need explicit version and precondition handling. A successful local file operation is not evidence that the same mutation, rename, or locking model exists in an object API or a filesystem adapter.

Bucket access settings have distinct purposes

The illustrative document enables uniform bucket-level access and enforces public access prevention in a bucket request shape. It remains non-runnable and uses names requiring adaptation. Uniform access disables ACL-based access management in favor of IAM under its rules; public access prevention restricts public exposure through its documented mechanisms. Neither grants an application the private access it needs.

Review bucket and object permissions, inherited policy, signed-access mechanisms, organization constraints, and credential identity separately. A restriction on public access is not encryption-key ownership, network isolation, or an audit-log retention policy. Keep each control’s purpose visible instead of calling a single flag secure.

json Illustrative bucket access settings

{
  "name": "EXAMPLE_BUCKET_NAME",
  "location": "REGION",
  "iamConfiguration": {
    "uniformBucketLevelAccess": {"enabled": true},
    "publicAccessPrevention": "enforced"
  }
}

This non-runnable request shape is not submitted, name-validated, or checked against organization policy.

Strong object consistency does not erase every propagation boundary

Cloud Storage documents strong consistency for object reads after successful writes, metadata changes, deletions, and listings. Do not repeat the outdated blanket claim that new objects are eventually listed. However, access changes and some configuration transitions have their own propagation behavior, and cached publicly readable content has cache-control semantics. The operation being discussed matters.

Strong consistency does not guarantee that every dependency is available during a regional incident or that an application used the correct generation. A stale cache, wrong object name, failed write, or authorization change can require different diagnosis. Separate a successful object-write response from metadata policy propagation and client caching.

Preconditions make a write’s intent explicit

The offline program compares an expected generation with a synthetic current generation. A mismatch means the caller’s local review should not assume its read version is current. In the real API, generation and metageneration preconditions apply to specified operations and can prevent races when used correctly. This arithmetic comparison neither sends a request nor implements distributed concurrency control.

Use the documented special cases and retry rules for the exact operation; do not generalize one precondition to every bucket or object mutation. Retrying an unconditional replacement after a timeout can overwrite newer data. An idempotency and version policy should explain what happens when the first attempt’s outcome is unknown.

python Check a synthetic version expectation

expected_generation = 6
current_generation = 7
print(f"generation_matches={expected_generation == current_generation}")
print("review action:", "continue model" if expected_generation == current_generation else "refresh version evidence")

Expected output

generation_matches=False
review action: refresh version evidence

Generation6 differs from7, so the offline review requires refreshed version evidence.

Versioning, soft delete, and retention solve different problems

Object Versioning, soft delete, lifecycle management, holds, and retention locks have distinct semantics, eligibility, cost, and reversibility. A lifecycle deletion rule is not a backup test; replication is not protection from every logical deletion. Review current bucket configuration and product constraints before assuming an older generation can always be recovered.

Define who may change protection settings, how long data must remain, which restore path is required, and how application references find the recovered version. Test recovery in an approved isolated environment before relying on it. No object, bucket, retention setting, or data copy is changed in this lesson.

Common errors and fixes

A new object is assumed eventually consistent for listing.

Why it happens: Old generic object-store advice replaced the product contract.
How to fix it: Use the documented strong-consistency semantics for the exact operation.
Prevent it next time: Separate cache and policy-propagation questions.

A restricted bucket is assumed readable by the workload.

Why it happens: Public prevention was confused with a private grant.
How to fix it: Review the workload principal and object permissions.
Prevent it next time: Test control purposes separately in the design.

A timed-out replacement is retried without version conditions.

Why it happens: The unknown first outcome and concurrent writer were ignored.
How to fix it: Design documented preconditions and safe retry semantics.
Prevent it next time: Record object-generation expectations.

Check your understanding

1. An application uploads an object successfully, but a public cached URL still shows old content. What distinction matters?

Show worked solution

Object read-after-write consistency and intermediary/client caching are different contracts. Inspect the exact URL, generation, cache-control metadata, and whether the request uses a cacheable public path. Do not conclude that every Cloud Storage operation is eventually consistent or weaken authorization to diagnose caching. Use authorized evidence of the write and delivery path.

2. Why does retaining several object generations not finish a recovery plan?