Manage a solution that can span multiple database technologies practice questions

Use Cloud Bigtable's online storage migration feature to switch to SSD without downtime.

Why wrong: There is no online storage migration feature in Bigtable.

Update the instance's storage type using 'gcloud bigtable instances update' with the --storage-type flag.

Why wrong: The storage type cannot be modified on an existing cluster; you must create a new cluster.

Export the HDD cluster's data to Cloud Storage, then import into a new SSD cluster.

Why wrong: While exporting and importing data is a valid method for migrating data between Bigtable instances, it is not the correct procedure for changing storage type within an existing cluster. Bigtable does not support in-place conversion of HDD to SSD storage for an active cluster. This option is tempting because it represents a common data migration pattern, and would be the appropriate solution if you needed to move data to a completely separate, new cluster with different configurations, or if an in-place upgrade were not possible.

Create a new table with the index and batch copy data from the original table.

Why wrong: Unnecessary; Spanner index creation is online.

Schedule a maintenance window, then create the index during the window.

Why wrong: No downtime needed.

Drop the table and recreate it with the index, then restore from backup.

Why wrong: Causes downtime and is not recommended.

Use Firestore in Datastore mode for automatic composite indexes.

Why wrong: Datastore mode also requires manual composite indexes.

Configure index exemptions for the fields.

Why wrong: Index exemptions are for arrays and maps, not for composite queries.

No configuration needed; single-field indexes are sufficient.

Why wrong: Single-field indexes do not support multi-field queries.

Export the database, modify the schema, and import using Dataflow

Why wrong: Export/import is disruptive and not the standard method for schema changes in Spanner.

Use CREATE INDEX for the new column

Why wrong: CREATE INDEX adds an index, not a column.

Drop and recreate the table with the new column

Why wrong: Dropping and recreating the table causes downtime and data loss if not carefully managed.

Configure a cross-region replica to provide failover and data durability.

Why wrong: Cross-region replica is not a supported feature in Memorystore for Redis, so this option does not achieve the requirement.

Take regular on-demand backups using gcloud redis instances export.

Why wrong: On-demand backups are not real-time; any data written after the last backup would be lost in a node failure.

Increase the maxmemory setting to store more data.

Why wrong: Increasing maxmemory does not provide any durability or replication; it only affects memory capacity.

Take daily on-demand exports to Cloud Storage.

Why wrong: Exports are point-in-time but not sufficient for 1-hour RTO; promoting a replica is faster.

Create two cross-region read replicas for redundancy.

Why wrong: One replica is sufficient; multiple replicas add cost without significant benefit for DR.

Increase the instance tier to have more memory.

Why wrong: Scaling up does not provide DR capability.

Manually run SELECT statements to export data and DESCRIBE commands for schema.

Why wrong: Manually running SELECT and DESCRIBE commands is not a built-in export feature and does not produce a portable format. It is inefficient and error-prone.

Use the Spanner migration tool to export to a SQL dump file.

Why wrong: The Spanner migration tool is used for migrating databases to Cloud Spanner, not for exporting from Spanner. It does not create a portable dump file for archival.

Use gcloud spanner databases export with the --async flag to export to a Cloud Storage bucket in Avro format.

Why wrong: The gcloud spanner databases export command exports data in Avro format and includes the schema (often in a separate schema file or within the Avro metadata), making it a portable export. The --async flag is optional and does not affect schema inclusion.

Use gcloud spanner databases backup create to create a backup that is stored in Cloud Storage.

Why wrong: This command creates a backup that is stored internally within Cloud Spanner, not directly in a user-accessible Cloud Storage bucket. It is not suitable for long-term archival export to Cloud Storage.

Use Dataflow to read the Spanner tables and write them to Cloud Storage as Parquet files.

Why wrong: Dataflow with Parquet exports table data but does not capture Cloud Spanner’s schema metadata—such as interleaved tables, secondary indexes, or foreign-key constraints—meaning a restore into a new Spanner database would require manual schema reconstruction. This option is tempting because Parquet is an efficient columnar format for analytics workloads, and Dataflow is often used for bulk data movement; it would be correct if the goal were to export data for querying in BigQuery or a data lake, not for full database restoration.

Use gcloud spanner databases restore to copy the database to a new instance.

Why wrong: This command restores a backup to a new instance, it does not export data to Cloud Storage.

Use gcloud bigtable clusters update with the --storage-type flag.

Why wrong: There is no such flag; storage type is immutable.

Modify the cluster settings and change the storage type to SSD.

Why wrong: Storage type cannot be changed on an existing cluster; it's immutable after creation.

Export the data to Cloud Storage, create a new SSD cluster, and import the data.

Why wrong: Exporting and re-importing Bigtable data is an overly complex and disruptive approach for changing storage type. Bigtable supports direct modification of a cluster's storage type from HDD to SSD *in-place*, without requiring data migration, thus avoiding unnecessary downtime and operational overhead. This export/import method is typically used for migrating data between Bigtable instances, across projects, or when creating a new instance with a different instance ID, where an in-place change isn't applicable.

Increase the backup retention period to 30 days.

Why wrong: Retention period only affects how long backups are kept, not their geographic redundancy.

Enable point-in-time recovery with a 7-day retention.

Why wrong: PITR does not provide cross-region protection by itself; it relies on binary logs stored in the same region.

Schedule more frequent on-demand backups.

Why wrong: On-demand backups are stored in the same region unless cross-region location is set.

noeviction

Why wrong: noeviction returns errors on writes when memory is full, which would cause application failures.

allkeys-lru

Why wrong: This evicts any key, including critical keys without TTL, based on LRU.

volatile-ttl

Why wrong: volatile-ttl evicts keys with the shortest TTL first, not LRU.

Export the data, create a new database with the index, and import the data.

Why wrong: This causes significant downtime and is unnecessary.

Stop the application, add the index, and restart.

Why wrong: Downtime is not required.

Use gcloud spanner databases add-index command.

Why wrong: No such command; indexes are added via DDL.

Cloud Audit Logs

Why wrong: Audit logs track who did what, not system metrics.

Active Assist

Why wrong: Active Assist provides recommendations, not monitoring/alerting.

Cloud Logging

Why wrong: Cloud Logging is for logs, not metrics and alerting.

Remove the ORDER BY clause to improve performance.

Why wrong: The application requires ordering; removing it changes functionality.

Create a composite index on (city, name).

Why wrong: This does not cover the inequality on age; Firestore would still need to filter.

Create a single-field index on 'name'.

Why wrong: Single-field index does not help with multi-field filter and order.

Configure automated backups with 7-day retention.

Why wrong: Backups provide point-in-time recovery, not HA/DR failover.

Use Cloud SQL Proxy for secure connections.

Why wrong: Proxy is for connectivity, not HA/DR.

Enable binary logging for point-in-time recovery.

Why wrong: PITR helps with data recovery, not HA/DR.

Create a new table with the index and migrate data manually

Why wrong: Unnecessarily complex and would require downtime or additional tooling.

Use the Cloud Console to create the index; it requires a maintenance window

Why wrong: No maintenance window needed; online schema changes are supported.

Take the table offline, create the index, then bring it back online

Why wrong: Spanner supports online schema changes; taking the table offline is unnecessary and causes downtime.

Enable AOF persistence in Memorystore settings

Why wrong: Memorystore for Redis Standard tier does support AOF persistence, but it is not enabled by default and may impact performance. However, for Basic tier instances, AOF is not available. In the context of this question, enabling AOF is not the most reliable method for cross-restart persistence compared to external snapshots.

Use a standard tier instance with persistence enabled

Why wrong: Standard tier instances do support persistence via automatic RDB snapshots, but this only protects against instance restarts within the same zone. For durability across broader failures or to retain data after instance deletion, storing periodic snapshots in Cloud Storage (option A) is the recommended approach.

Enable auto-backup in Memorystore

Why wrong: Enabling auto-backup in Memorystore is not a feature; auto-backup typically refers to database backups, but Memorystore does not have an auto-backup setting. This option is misleading.

Create multiple standalone instances and route traffic manually

Why wrong: Manual routing is not a managed solution.

Use Persistent Disk for data persistence

Why wrong: Memorystore does not use Persistent Disk; persistence is not needed for HA.

Use the Basic tier

Why wrong: Basic tier has no replication, thus no automatic failover.

Create a new instance and use gcloud spanner instances restore.

Why wrong: The restore command is for databases, not instances.

Use gcloud spanner databases import from the Cloud Storage backup file.

Why wrong: Import is for exported data in Avro format, not for native backups.

Restore is not possible; you must use point-in-time recovery.

Why wrong: Spanner supports both backup/restore and PITR.

Use 'gcloud bigtable hot-spots list' command; then split the hot table into multiple tables.

Why wrong: No such command; splitting tables is not a typical mitigation.

Use Cloud Monitoring to check CPU utilisation; then add more nodes to the cluster.

Why wrong: Adding nodes helps with overall throughput but does not fix hot spots caused by row key design.

Use the Bigtable admin console to view table statistics; then change the storage type from HDD to SSD.

Why wrong: Changing storage type requires a new cluster and does not address hot spots.