Google ACE: Storage, Databases and Data Services — Study Guide

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

This section provides a practical, operations-focused reference for Google Cloud storage, databases, and analytical data services. It emphasizes configuration patterns, access control, durability mechanisms, performance and cost characteristics, and safe recovery practices. The goal is to help you decide which service to use for a given workload, understand the operational trade-offs, and anticipate common failure modes.

Cloud Storage design, access, lifecycle, and protection

Cloud Storage is durable, highly available object storage for unstructured data and backups.

Buckets and objects: Buckets are global namespaces in a location (region or dual/multi-region) that contain immutable object versions. Choose bucket location to minimize egress and meet data residency.
Storage classes: Use Standard (hot), Nearline (~30-day min), Coldline (~90-day min), and Archive (~365-day min) based on access frequency. For DR backups, Coldline is a common default. You can mix classes per object within a bucket.
Lifecycle rules: Automate transitions and deletions by Age, CreatedBefore, MatchesStorageClass, and NoncurrentVersion conditions. Example to transition at 90 days and delete at 365 days:
1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
2. Apply: gsutil lifecycle set lifecycle.json gs://my-bucket
Retention and legal holds: Retention policies prevent deletion or modification of objects before the period elapses; locking the policy is irreversible. Legal holds are per-object and must be cleared before deletion.

Access control and sharing:

Uniform vs fine-grained: Prefer Uniform bucket-level access (UBLA) to manage permissions with IAM only. Fine-grained access (object ACLs) is legacy and complicates auditability and propagation. Enabling UBLA disables ACLs and can immediately affect existing integrations that relied on ACLs.
Signed URLs: For short-lived access without a Google identity, use signed URLs. Avoid service account key files by signing with IAM: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com Ensure the service account has service account token creator on itself or via a signer role.
Encryption: Server-side encryption by default; enable CMEK at the bucket or per-object scope when you need control over keys and audit trails. Monitor KMS key availability and rotation; CMEK unavailability will block uploads and decrypts.
Versioning: Enable object versioning to keep noncurrent versions after overwrites/deletes. Combine with lifecycle rules to expire noncurrent versions and control storage growth. Be aware of client-side listing logic when many versions exist.

Failure modes and mitigation:

Accidental deletion or overwrite: Use versioning and retention policies. For strict compliance, lock retention.
Misconfigured public access: Enforce Public Access Prevention and UBLA. Periodically audit with Cloud Asset Inventory and policy analyzer.
Excess costs: Lifecycle rules, object-level classes, and requester pays reduce surprises. Monitor with Cloud Monitoring metrics and budgets.

Useful commands:

Create bucket with UBLA and retention: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

Block and file storage for compute workloads

Choose storage by access pattern, performance needs, and durability requirements for Compute Engine and GKE.

Persistent Disk (PD): Durable block storage, zonal or regional. Types: Standard (HDD) for sequential throughput; Balanced (pd-balanced) and SSD (pd-ssd) for low latency and IOPS. Regional PD synchronously replicates across zones, enabling faster recovery. PD can be snapshotted, resized online, and attached read-only to multiple VMs (single-writer for read-write).
- Trade-offs: Higher IOPS costs on SSD; HDD is cost-effective but high latency for random IO. Regional PD costs more but reduces RTO.
Local SSD: NVMe or SCSI-attached ephemeral storage with very high IOPS and low latency. Data is lost on VM stop/host maintenance; use it only for ephemeral caches or replicated data. Back up or replicate elsewhere to avoid data loss.
Filestore: Managed NFS for POSIX-shared file semantics. Basic tiers are zonal; Enterprise and higher tiers offer regional HA with synchronous replication and higher IOPS. Ideal for GCVE, HPC scratch, media rendering, and apps needing shared file locking.
- Trade-offs: NFS introduces client-side caching and lock semantics; throughput and latency differ by tier; not suitable for small random IO at single-digit microsecond latencies like local SSD.

Failure considerations:

Host maintenance: Local SSD data loss; protect with application replication.
Zonal outages: Zonal PD and Basic Filestore interruptions; use regional PD or Filestore Enterprise for HA.
Snapshot consistency: For application-consistent PD snapshots, coordinate with filesystem freeze or database native quiesce to avoid crash recovery windows.

Managed databases and data services

Cloud SQL (managed MySQL, PostgreSQL, SQL Server):

Configuration: Choose machine shape, storage type, connections (private IP preferred), authorized networks if using public IP, maintenance windows, and insights for performance diagnostics. Use connection pooling (e.g., Cloud SQL Auth Proxy, PGbouncer) to stay within connection and CPU limits.
High availability: Regional HA instances deploy a standby in another zone with synchronous storage replication; failover is automatic. Expect a short write unavailability window during failover.
Replicas: Read replicas for read scaling and offloading BI; external replication for migrations. Monitor replica lag and design idempotent readers.
Backups and PITR: Enable automated backups and binary/WAL logging for point-in-time recovery. Test restores regularly. gcloud sql instances patch my-sql –backup-start-time=03:00 –enable-bin-log
Failure modes: Long-running transactions block vacuum/checkpointing; spikes in connections cause thrash; storage autogrow can stall if quota is insufficient. Set alerts for CPU, memory, connections, replica lag, and disk usage.

Cloud Spanner:

Scale and regionality: Regional or multi-region instances with synchronous replication and strong global consistency. Scale nodes for throughput and storage; leader region placement influences write latency.
Schema and keys: Design primary keys to avoid hotspots; use composite keys with a hashed or randomized prefix for time-series to distribute writes. Use secondary indexes for query patterns and consider storing frequently filtered columns together. Keep transactions small and bounded to minimize lock contention.
Transactions: Strongly consistent, distributed transactions with external consistency via TrueTime. Write latency bounded by quorum; conflicts yield aborted transactions—retry with backoff.

Firestore and Bigtable:

Firestore (Native mode): Document store with collections, real-time listeners, transactions across up to 500 documents per transaction, and strong consistency for document reads and most queries. Best for mobile/web app data, hierarchical JSON, and event-driven apps.
Bigtable: Wide-column database for petabyte-scale and sub-10ms latency. Single-row transactions only; design row keys to avoid hotspotting. Ideal for time-series, IoT, personalization, and large-scale counters. Not for ad-hoc joins or complex aggregations.

Memorystore:

Redis and Memcached: In-memory caches for microsecond-millisecond latency. Basic tier has no HA; Standard tier provides regional HA with automatic failover for Redis. Treat as ephemeral; do not use as the system of record.

BigQuery:

Datasets and tables: Organize by dataset; control access at project, dataset, table, column, and row levels. Use partitioned and clustered tables to control scanned bytes and cost.
Load and query jobs: Load from Cloud Storage, Cloud SQL exports, or streaming inserts. Use dry runs to estimate cost: bq query –use_legacy_sql=false –dry_run=true ‘SELECT …’
Access control: Grant BigQuery Data Viewer at dataset scope for read-only consumers; use authorized views or row-level/column-level security for least privilege.

Data movement, migration, validation, and operations trade-offs

Migration and transfer:

Database Migration Service (DMS): For homogeneous migrations to Cloud SQL with minimal downtime via replication. Validate cutover with lag metrics and checksum comparisons.
Cloud Storage transfers: Storage Transfer Service for repetitive or event-driven transfers; gsutil -m rsync for one-off synchronized copies with checksums; Transfer Appliance for large offline moves.
Import/export: Cloud SQL exports to Cloud Storage; re-import supports PITR bootstrap and data verification. BigQuery supports batch loads from Cloud Storage and exports to Avro/Parquet for downstream use.
Validation: Use object checksums (CRC32C), row counts, sampling queries, and application-level invariants. For BigQuery, compare GROUP BY counts or hashes across source and target.

Performance, availability, capacity, and cost trade-offs:

Cloud Storage: Optimize egress by co-locating compute; choose classes by access frequency; use dual/multi-region for cross-zone resilience and higher availability at higher storage cost.
PD/Filestore: SSD for low-latency IO; HDD for throughput; regional replication for HA; right-size IOPS to avoid throttling.
Cloud SQL: Vertical scaling is simple but limited; read replicas offload read traffic; HA adds availability but not read capacity; storage class affects latency and cost.
Spanner: Scales horizontally with strong consistency; premium cost offset by global RPO/RTO and simplified sharding. Writes are sensitive to key design and leader region latency.
Firestore/Bigtable/Memorystore: Choose by latency, data model, and consistency. In-memory caches reduce database load but add cache-invalidation complexity.
BigQuery: On-demand cost is proportional to scanned bytes; partitioning/clustering and predicate pushdown reduce spend. Flat-rate reservations trade predictability for commitment.

Troubleshooting and safe recovery:

Cloud Storage: Use object versioning and retention to recover; examine Cloud Logging data access logs to audit read/write events; ensure CMEK keys are enabled during recovery.
PD/Filestore: Restore from snapshots or backups; run fsck and database recovery modes; ensure consistency with app-level quiesce before snapshotting.
Cloud SQL: Restore to a new instance for PITR to avoid data loss on the primary; verify with read-only tests; maintain firewall and private DNS for safe cutover patterns.
Spanner/Bigtable: Investigate hotspotting via key access skew; use Monitoring to track latency and throttling; implement backoff and retries for aborted transactions or rate-limited operations.
BigQuery: Diagnose slow queries via execution details; add partitions and clustering; limit SELECT *; materialize intermediate results when appropriate. Recover dropped tables within the time travel window by restoring a snapshot or copying from a snapshot time.

Practical Problem Scenario

Contoso Retail is consolidating backups and analytics data while hardening access controls and enabling point-in-time recovery for its transactional systems. They need to: store application backups with automated tiering, provide short-lived file sharing to third parties, enable PITR for a small relational workload, and estimate analytics query costs before execution.

Approach:

Create a regional Cloud Storage bucket with UBLA, retention, and lifecycle.
- Command: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
- Rationale: UBLA centralizes authorization in IAM and improves auditability. A one-year retention prevents accidental deletion. Lifecycle transitions backups to Coldline after 90 days and deletes them at expiry to control cost.
Grant write-only access for backup jobs via a dedicated service account.
- Command: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
- Rationale: storage.objectCreator prevents metadata tampering and read-back of sensitive backups, adhering to least privilege.
Share a sensitive backup with a vendor for four hours using a signed URL without distributing keys.
- Command: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
- Rationale: Time-bounded, identity-less access avoids creating external identities or long-lived secrets. Impersonation uses centralized KMS-backed signing and eliminates leaked key risks.
Enable Cloud SQL backups and PITR for the order database.
- Command: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
- Rationale: Automated backups plus binary/WAL logging provide restore points to any second within the retention window, protecting against logical corruption and operator error.
Test recovery by restoring to a new instance and validating data before cutover.
- Command: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
- Rationale: Restoring to a separate instance avoids impacting production and allows validation via checksums and sample queries before any DNS or application-level switch.
Estimate BigQuery query cost with a dry run and optimize with partitioning.
- Command: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
- Rationale: Dry runs surface bytes to be scanned; ensuring sale_date is a partition column with a bounded predicate reduces scanned bytes and controls on-demand costs.
Monitor and audit access.
- Steps:
  - Enable Data Access logs for Cloud Storage and BigQuery.
  - Configure Cloud Monitoring alerts on Cloud SQL connections, disk usage, and backup failures.
- Rationale: Data Access logs provide object-level read/write visibility for compliance. Proactive alerts shorten MTTR and ensure backups and PITR remain effective.
Document failure modes and runbooks.
- Steps:
  - Record procedures for object version restores, signed URL revocation, Cloud SQL PITR, and BigQuery table recovery using time travel.
- Rationale: Clear, tested runbooks reduce operational risk during incidents and standardize safe recovery practices across teams.