Managing Cloud Storage and Databases: Lifecycle, Backups, and CMEK

You secure Cloud Storage objects with IAM at the bucket level, and you should almost always enable uniform bucket-level access, which disables per-object ACLs so IAM policies alone govern the bucket. That gives you one consistent, auditable permission model. The legacy alternative, fine-grained access, lets each object carry its own ACL — needed only for rare per-object permission schemes, and a source of accidental exposure otherwise. Grant access with roles such as roles/storage.objectViewer (read objects), roles/storage.objectAdmin (full object control), and roles/storage.admin (buckets and objects), for example: gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=user:ana@example.com --role=roles/storage.objectViewer. Turn on public access prevention to make it impossible to grant access to allUsers, and note that gsutil-era workflows are now handled by the gcloud storage command group.

To give someone temporary access without a Google account or any IAM change, generate a signed URL: a time-limited URL cryptographically signed with a service account's credentials that grants access to exactly one object until it expires, for example gcloud storage sign-url gs://BUCKET_NAME/report.pdf --duration=1h --private-key-file=key.json. Whenever a question says an external user, a mobile app, or a partner needs short-lived access to a single object, the answer is a signed URL — not making the bucket public and not creating IAM bindings.

Object versioning protects against overwrites and deletions: once enabled on a bucket, replacing or deleting an object turns the old data into a noncurrent version you can list (gcloud storage ls --all-versions) and restore by copying back. Versioning multiplies storage cost if you never clean up, which is exactly what lifecycle rules are for — the next section. For compliance holds where even admins must not delete data, use bucket retention policies or Object Lock features rather than versioning.

A lifecycle policy automates cost control: each rule pairs one action with one or more conditions, and Cloud Storage applies the action when every condition on a rule is true. The two main actions are SetStorageClass (transition the object to a colder class) and Delete (remove it, or remove a noncurrent version); AbortIncompleteMultipartUpload cleans up abandoned uploads.

Policies are written as JSON and applied to the bucket: gcloud storage buckets update gs://BUCKET_NAME --lifecycle-file=lifecycle.json. A canonical policy for versioned log data: transition to Nearline at 30 days, Coldline at 90, Archive at 365, and delete noncurrent versions once numNewerVersions exceeds 2. Transitions only move toward colder classes, and rules act on objects — they never re-warm data for you.

Two gotchas pair with the storage classes themselves. Nearline, Coldline, and Archive carry minimum storage durations (30, 90, and 365 days respectively) — deleting or transitioning earlier still bills the minimum — and they charge retrieval fees per GiB read. So a lifecycle rule that pushes frequently read data into Archive raises cost. If access patterns are unknown or shifting, Autoclass manages transitions automatically per object and removes the guesswork.

Each data service has a native query path, and the exam expects you to match tool to service. For Cloud SQL, connect with gcloud sql connect INSTANCE_NAME --user=root — it temporarily allowlists your IP and opens the familiar database shell — or run the Cloud SQL Auth Proxy for IAM-authenticated connections from applications without managing authorized networks or SSL certificates. From there it is ordinary SQL against your engine of choice. AlloyDB, the PostgreSQL-compatible service, works the same way conceptually: connect with standard PostgreSQL clients such as psql, typically through the AlloyDB Auth Proxy, or use AlloyDB Studio in the console.

For BigQuery, run SQL in the console's BigQuery Studio or from the bq CLI: bq query --use_legacy_sql=false 'SELECT name, COUNT(*) FROM dataset.table GROUP BY name'. Always use standard SQL. Before running an expensive query, a dry run (bq query --dry_run) reports how many bytes it would scan without billing you — remember this for cost questions. For Spanner, execute SQL with gcloud spanner databases execute-sql DATABASE_NAME --instance=INSTANCE_NAME --sql='SELECT ...' or use Spanner Studio in the console.

Bigtable is a NoSQL wide-column store — no SQL engine of its own. You read rows with the cbt CLI (cbt -instance=INSTANCE_ID read TABLE_NAME) or client libraries, and query it with SQL only indirectly, for example through a BigQuery external table. Firestore is a document database queried through client libraries and the console's query builder against collections and documents rather than tables. When a question hands you a service and asks how to run a query, eliminate by data model first: SQL for Cloud SQL, AlloyDB, Spanner, and BigQuery; cbt or client libraries for Bigtable; document queries for Firestore.

You estimate storage costs by combining three factors — volume stored, storage class or tier, and access pattern — and the Google Cloud pricing calculator is the tool for turning those into a number before you build. For Cloud Storage the estimate is monthly GiB stored per class, plus operation charges, plus retrieval fees for cold classes, plus any early-delete charges from minimum storage durations. The recurring exam trap: Archive storage is by far the cheapest at rest but expensive to touch, so the right class depends on how often data is read, not just how big it is.

BigQuery costs split into storage and compute. Storage is billed for data at rest (with a lower rate for long-term storage — tables or partitions unmodified for 90 days). Compute is either on-demand — billed per TiB of data scanned by each query — or capacity-based reservations billed for slots. On-demand is why partitioning and clustering matter operationally: a query that prunes to one day's partition scans and bills a fraction of the table, and a dry run tells you the scanned bytes in advance. Cloud SQL and AlloyDB bill for provisioned vCPUs, memory, and storage over time (plus backup storage), so their estimates look like VM sizing; Spanner bills for compute capacity plus storage; Bigtable bills for nodes plus storage.

After launch, cost observability replaces estimation: billing reports break down spend by service and SKU, and exporting billing data to BigQuery lets you query spend directly. If a scenario asks how to forecast the cost of a proposed storage design, answer the pricing calculator; if it asks how to analyze existing spend in detail, answer billing export to BigQuery.

For Cloud SQL, enable automated backups — daily backups taken in a configurable window — with gcloud sql instances patch INSTANCE_NAME --backup-start-time=03:00, and take on-demand backups any time with gcloud sql backups create --instance=INSTANCE_NAME. Restoring a backup overwrites or recreates the instance at that backup's moment. To recover to an arbitrary point between backups, enable point-in-time recovery (PITR), which requires automated backups plus transaction logging (binary logging on MySQL, write-ahead logging on PostgreSQL). PITR restores to a new instance at a chosen timestamp — the pattern for undoing an accidental DELETE without losing the rest of the day's writes.

The pattern to internalize: backups restore to a state; PITR restores to a moment. Managed backups also differ from exports — a Firestore export to Cloud Storage or a Spanner export via Dataflow gives you portable data for migration or long-term archive, while native backups are faster to restore but live inside the service. When a question involves accidental data deletion minutes ago, look for the PITR-shaped answer; when it involves keeping a copy for years or moving data between projects, look for export.

You check Dataflow job status in the console's Dataflow Jobs page, where each job shows its state — Running, Succeeded, Failed, Cancelled — alongside the pipeline graph, per-step metrics, autoscaling history, and worker logs. From the CLI, gcloud dataflow jobs list --region=REGION enumerates jobs and gcloud dataflow jobs describe JOB_ID --region=REGION shows one job's detail. A streaming job that must stop has two options with an exam-relevant difference: drain finishes processing in-flight data then stops, while cancel stops immediately and may drop buffered records. Failed jobs are diagnosed from the step-level logs and error counters in the job page.

For BigQuery, every query, load, export, and copy runs as a job. In the console, Job history (personal and project-level) shows each job's status, duration, and bytes processed. From the CLI, bq ls -j --max_results=20 lists recent jobs and bq show -j JOB_ID prints one job's full status, including error details for failures. For fleet-wide analysis — slowest queries, biggest scanners, failure rates — query the INFORMATION_SCHEMA.JOBS views with SQL, which is also the standard answer for auditing who ran what.

Operationally, connect job monitoring to alerting rather than watching dashboards: Dataflow job metrics flow into Cloud Monitoring, where an alerting policy on failed jobs or rising system lag notifies you, and BigQuery job errors surface in Cloud Logging where log-based alerts apply. If a scenario asks how to find out why last night's scheduled load failed, the answer is the job's status detail (bq show -j or the console job history), not re-running the pipeline blind.

Database Center is the single console view of your entire database fleet — Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, and more — across projects, so you stop checking each instance page one by one. It inventories every database resource, then layers on health signals: availability risks such as instances without high availability or automated backups, security findings such as broad network exposure or missing encryption controls, performance issues, and cost optimization opportunities, largely powered by Active Assist recommenders.

The workflow is triage: open Database Center, review the fleet summary of issues grouped by category and severity, drill into an affected instance, and follow the recommendation — enable automated backups here, add high availability there, tighten a network setting elsewhere. It also carries a Gemini-powered chat interface, so you can ask natural-language questions about the fleet's health and get summarized answers instead of assembling them from per-instance pages.

For the exam, position it correctly against its neighbors: Database Center is fleet-wide inventory, health, and recommendations across database services; Cloud Monitoring is metrics and alerting for anything; Query Insights (in Cloud SQL and AlloyDB) diagnoses slow queries inside a single instance. A question about spotting every database in the organization missing backups is Database Center; a question about one instance's slow query is Query Insights.

Everything in Google Cloud is encrypted at rest by default with Google-managed keys; CMEK changes who controls the key, not whether encryption happens. With CMEK, data is protected by a key you create and manage in Cloud KMS — you control its rotation schedule, you can disable or destroy it, and access to it is IAM-audited. Choose CMEK when compliance requires customer control of key lifecycle; the fully customer-supplied alternative (providing raw key material yourself) is rare and operationally heavy, so CMEK is the standard answer for key control requirements.

The setup has three steps and one critical grant. First, create a key ring and key: gcloud kms keyrings create my-ring --location=us-central1 then gcloud kms keys create my-key --keyring=my-ring --location=us-central1 --purpose=encryption. Second — the step exams test — grant the service agent of the data service permission to use the key: each service (Cloud Storage, Cloud SQL, BigQuery, Spanner) has a per-project service agent account that must hold roles/cloudkms.cryptoKeyEncrypterDecrypter on the key. Third, attach the key to the resource: set a bucket's default key with gcloud storage buckets update gs://BUCKET_NAME --default-encryption-key=KEY_RESOURCE_NAME, or pass the key at creation for a Cloud SQL instance, BigQuery dataset, or Spanner database — for many services CMEK can only be chosen at resource creation, not retrofitted.

The operational consequences are the point. The key must live in a location compatible with the resource it protects. If you disable or destroy the key — or revoke the service agent's role — the service can no longer decrypt: data becomes inaccessible, instances can fail to start, and destroyed key versions make data permanently unrecoverable. Key rotation is safe and non-disruptive: new key versions encrypt new data while old versions still decrypt existing data. A scenario where storage "suddenly became inaccessible" after a security cleanup is almost always a disabled CMEK key or a removed service agent grant.