Select Two (Multi-Select) Questions

Cloud Bigtable

Why wrong: Bigtable is eventually consistent.

BigQuery

Why wrong: BigQuery is analytical, not transactional.

Firestore

Why wrong: Firestore is not globally consistent and lacks complex relational queries.

Schema changes require the instance to be restarted.

Why wrong: No restart needed.

You can only add columns, not drop them.

Why wrong: Spanner supports dropping columns.

Creating a secondary index requires taking the table offline.

Why wrong: Index creation is online and non-blocking.

The version of the source PostgreSQL database.

Why wrong: Version differences are minimal; not a primary factor.

The choice of SSL or non-SSL connection.

Why wrong: SSL adds negligible overhead.

Export the database to Cloud Storage and import in another region.

Why wrong: Export/import RTO is hours, not minutes.

Cloud SQL point-in-time recovery from backups.

Why wrong: PITR RPO is limited by binary log retention (seconds) but RTO is hours for restore from backup.

Use Cloud SQL automated backups with cross-region copy.

Why wrong: Backup restore RTO is hours.

Export the database to a SQL file and import after the cutover.

Why wrong: This causes downtime during export and import.

Schedule a maintenance window for the cutover.

Why wrong: A maintenance window implies downtime.

Use a secondary index on transactions.account_id.

Why wrong: While possible, a secondary index is less efficient than interleaving for this access pattern and adds write overhead.

Define a foreign key constraint from transactions to accounts.

Why wrong: Cloud Spanner does not enforce foreign keys; they are informational only.

Store transactions as a JSON array of repeating fields within the account record.

Why wrong: Denormalization limits query flexibility and indexing, and is not recommended for Spanner.

Use arrays in the chat room document to store message IDs.

Why wrong: Arrays have size limits and are not suitable for large numbers of messages.

Store all messages in a single top-level collection with a field for chat room ID.

Why wrong: A single large collection can be less efficient for filtering on chat room and timestamp.

Use a separate top-level collection for each chat room.

Why wrong: This results in many collections, which is not recommended due to collection limits and management overhead.

Create a view with UNION ALL of all region tables

Why wrong: Does not prune tables; scans all tables on every query.

Create materialized views for each region

Why wrong: Materialized views are pre-computed and may not support dynamic region selection.

Store all data in a single table with region as a column

Why wrong: Increases storage and may violate data locality requirements.

Use NULL values in primary key columns to allow optional fields.

Why wrong: Primary key columns cannot be NULL; they must have unique non-null values.

Avoid using composite primary keys; use single-column keys instead.

Why wrong: Composite primary keys are common and recommended in Spanner for data distribution.

Use LIMIT in subqueries to reduce output

Why wrong: LIMIT does not reduce the scan of the underlying table; it only limits output rows.

Use SELECT * to avoid missing columns

Why wrong: SELECT * often scans all columns, increasing bytes.

Create a replication dashboard in Data Studio

Why wrong: Dashboard is not a configuration; monitoring metric is needed.

Set the replication consistency level to 'strong'

Why wrong: Bigtable only supports eventual consistency across clusters; strong consistency is not available.

Enable synchronous replication for zero lag

Why wrong: Synchronous replication is not supported.

A Cloud Monitoring dashboard

Why wrong: Dashboards are for visualization, not alerting.

A runbook for incident response

Why wrong: Runbooks guide response but are not essential for setting up on-call rotation.

Enable point-in-time recovery on the destination.

Why wrong: Not essential for cutover; can be done later.

Take a full backup of the source after quiescing.

Why wrong: Unnecessary; DMS already replicated data.

Cloud Build with privilege escalation mode

Why wrong: Privilege escalation is not directly related to Binary Authorization.

Container Registry with vulnerability scanning enabled

Why wrong: Vulnerability scanning is separate from image signing and enforcement.

Cross-region backup and restore

Why wrong: Backup restore has RPO measured in hours and RTO in hours, not meeting the requirements.

Point-in-time recovery (PITR)

Why wrong: PITR is for recovering to a specific point in time, not for automatic failover.

Multi-region configuration with read-only replicas

Why wrong: Read-only replicas do not provide automatic failover; they are for reads only.

GEOMETRY

Why wrong: Spanner does not support spatial data types.

TEXT

Why wrong: Use STRING instead of TEXT.

TINYINT

Why wrong: Cloud Spanner uses INT64 for integer types.

Use gcloud commands to encrypt all existing disks with the KMS key.

Why wrong: Existing disks must be manually encrypted, but the question asks for steps to enforce the policy, which is preventive.

Enable the Cloud KMS API in each project where the policy is enforced.

Why wrong: The KMS API is needed for key management, but the policy already requires CMEK; enabling the API is a prerequisite but not a step to enforce the policy.

Grant the cloudkms.cryptoKeyEncrypterDecrypter role to the Compute Engine service account.

Why wrong: This role is needed for the service account to use the key, but it is not a step to enforce the policy; it's a permission that must be granted separately.

Blue/green strategy

Why wrong: Not requested; canary is specified.

Automated rollback

Why wrong: While possible, it is not one of the three features described (canary, verification, approval).

Use Cloud Deploy instead of kubectl

Why wrong: Not necessary for this specific task.

Create a new Docker image tag with the commit SHA

Why wrong: Tagging the image is separate from setting an env var.

A single billing account per team.

Why wrong: Billing accounts are separate from landing zone structure; one billing account can cover multiple projects.

A separate project per developer for sandbox environments.

Why wrong: While sandbox projects are common, they are not essential; the core landing zone focuses on shared services.