Managing Implementation and Ensuring Solution and Operations Reliability practice questions

GKE Standard

Why wrong: GKE Standard requires node management and does not provide a workload-level SLA.

GKE Autopilot

Why wrong: This option is identical to option D but listed as incorrect due to a duplicate. The correct choice is GKE Autopilot, which is option D.

GKE on Bare Metal

Why wrong: GKE on Bare Metal is for on-premises deployments and does not meet the no-node-management requirement.

Partner Interconnect

Why wrong: Partner Interconnect is limited to 50 Mbps–10 Gbps and maximum 10 Gbps per connection. It relies on a third-party provider.

Direct Peering

Why wrong: Direct Peering does not offer an SLA and is not intended for production traffic requiring guaranteed bandwidth.

HA VPN

Why wrong: HA VPN provides 99.99% SLA but bandwidth is limited to 3 Gbps per tunnel and traffic traverses the public internet.

GKE Standard with Cluster Autoscaler

Why wrong: Cluster Autoscaler only scales nodes; node management and SLAs are still user responsibility.

GKE Standard with node auto-provisioning

Why wrong: Node auto-provisioning still requires the user to manage node pools and does not offer workload-level SLAs.

GKE Standard with sole-tenant nodes

Why wrong: Sole-tenant nodes provide isolation but require manual management and lack workload SLAs.

Use Database Migration Service to replicate to a second Cloud SQL instance

Why wrong: Database Migration Service is used for migration, not high availability; it does not provide automatic failover.

Enable point-in-time recovery (PITR) and increase backup retention

Why wrong: PITR uses logs to restore to a point in time, but does not provide automatic failover.

Create a cross-region read replica and manually promote it on failure

Why wrong: Cross-region replicas require manual promotion and may have replication lag leading to data loss.

Delta metric

Why wrong: A delta metric measures change over an interval, but percentiles require a distribution of values.

Cumulative metric

Why wrong: A cumulative metric increases over time and is reset; it does not support percentile calculations.

Gauge metric

Why wrong: A gauge metric represents a value at a point in time, not suitable for percentile calculations over a time window.

Configure a GKE Ingress with weighted backend services

Why wrong: GKE Ingress with weighted backends is possible but does not provide the built-in canary pipeline and monitoring integration that Cloud Deploy offers.

Deploy the new version to a separate namespace and use DNS weighting

Why wrong: DNS weighting is not accurate for traffic splitting and does not provide the control and observability needed for canary deployments.

Use Kubernetes Deployment with rolling update strategy

Why wrong: Rolling update gradually replaces pods but does not support precise traffic splitting percentages (e.g., 1%).

Configure a Cloud Scheduler job to check CPU utilization and publish to Pub/Sub

Why wrong: Cloud Scheduler is not designed for monitoring and alerting; it would require custom code and lacks integration.

Create a log-based alert for CPU utilization using Logging and route to email and Pub/Sub

Why wrong: CPU utilization is a metric, not a log entry. Log-based alerts are for log entries, not metrics.

Use Cloud Functions to poll the Cloud Monitoring API every minute and send notifications

Why wrong: This is an overly complex and less reliable solution compared to using native alerting policies.

Cloud Logging in the Console

Why wrong: Cloud Logging aggregates logs from multiple sources but does not allow direct file access on a VM.

Cloud Console's VM instances page

Why wrong: The VM instances page shows metadata but not log file contents.

Cloud SDK installed locally

Why wrong: Local Cloud SDK is not available in the Console; it requires local installation.

Use a global load balancer with a backend service pointing to multiple zonal instance groups

Why wrong: This provides traffic distribution but does not automatically create new instances in case of zone failure; manual intervention would be needed.

Set up a Cloud Scheduler to check instance health and create new instances via Cloud Functions

Why wrong: Cloud Scheduler triggering Cloud Functions adds unnecessary latency and complexity for zone failover, as it relies on periodic polling rather than immediate, event-driven detection of zone failure. The correct approach uses an Instance Group with autohealing and multi-zone deployment, which automatically redistributes instances without external orchestration. This option is tempting because Cloud Scheduler and Functions are a common pattern for scheduled or event-driven automation, such as restarting instances on a fixed schedule or reacting to non-infrastructure events.

Create a snapshot schedule and use Cloud Deployment Manager to recreate instances

Why wrong: This approach would require manual or scheduled execution and is not automated for zone failure.

Locust

Why wrong: Locust is an open-source tool that requires manual setup and does not integrate natively with Cloud Monitoring.

Apache JMeter

Why wrong: JMeter is an open-source tool that does not have native integration with Cloud Monitoring and requires custom configuration.

gcloud alpha loadtest

Why wrong: There is no 'gcloud alpha loadtest' command. gcloud provides commands for Cloud Load Testing but not directly as a subcommand.

Object versioning only

Why wrong: Object versioning retains versions indefinitely unless lifecycle rules are added.

Retention policy

Why wrong: Retention policy prevents deletion but does not delete old versions automatically.

Object holds

Why wrong: Object holds prevent deletion but do not provide automatic cleanup.

Use Kubernetes Services with multiple Deployments and manual scaling

Why wrong: Kubernetes Services do not support routing based on cookies or percentage-based splitting.

Configure an HTTP(S) load balancer with URL maps and backend services

Why wrong: HTTP(S) load balancers can route based on URL or host, but not on cookies for percentage-based traffic splitting.

Deploy two separate GKE clusters and use DNS-based traffic splitting

Why wrong: DNS-based splitting does not provide cookie-based routing and is not as precise.

Use a stronger read consistency level

Why wrong: Stronger consistency (e.g., strong reads) may increase latency; it does not reduce write latency.

Change from a multi-region to a single-region configuration

Why wrong: This would reduce write latency due to less replication, but would compromise global availability and durability.

Enable follower reads

Why wrong: Follower reads reduce read latency but do not affect write latency.

Configure a failover replica in another zone

Why wrong: Failover replica provides high availability, not point-in-time recovery.

Create a cross-region read replica

Why wrong: Cross-region replicas provide geographic redundancy but not point-in-time recovery.

Export the database daily to Cloud Storage

Why wrong: Daily exports are not point-in-time and would lose data between exports.

Increase the instance's memory by changing the machine type

Why wrong: Changing the machine type is a fix, not a diagnostic action.

Create a snapshot of the boot disk

Why wrong: Snapshot is for backup, not troubleshooting memory issues.

Cloud SQL with a cross-region read replica

Why wrong: Cloud SQL cross-region replicas are for read scaling and require manual promotion for write availability.

Cloud CDN

Why wrong: Cloud CDN caches content at edge locations but does not provide compute or database failover across regions.

Enable deletion protection on the instance.

Why wrong: Deletion protection prevents accidental deletion but does not provide failover.

Create a cross-region read replica and manually promote it during a failure.

Why wrong: Read replicas are for read scaling; manual promotion is not automatic failover and has longer downtime.

Enable point-in-time recovery (PITR) and keep 30 days of transaction logs.

Why wrong: PITR allows restoring to a point in time but does not provide automatic failover.

Use Partner Interconnect with a single 10 Gbps connection.

Why wrong: Single connection is a single point of failure; Partner Interconnect relies on a partner, but two connections are needed for HA.

Configure a single Dedicated Interconnect connection and use Cloud VPN as backup.

Why wrong: A single Dedicated Interconnect is a single point of failure; VPN backup adds complexity and lower bandwidth.

Deploy a single HA VPN tunnel.

Why wrong: HA VPN provides up to 3 Gbps per tunnel and is software-defined; does not provide dedicated 10 Gbps.

Configure a Cloud Build trigger to run a script that checks logs and rolls back if error rate exceeds threshold.

Why wrong: Cloud Build is for CI/CD, not for real-time monitoring and automatic rollback during canary.

Set up a Cloud Monitoring alert with a notification to the SRE team and have them manually roll back.

Why wrong: Manual rollback does not meet the automatic requirement and is slower.

Use GKE blue-green deployment with a manual verification step before switching traffic.

Why wrong: Blue-green deployments require manual verification; no automatic rollback on error rate increase.

Enable automated backups and transaction log retention for 7 days. Restore the backup in a new instance in a different region.

Why wrong: Automated backups are daily; you cannot restore to a specific second within the day.

Use Cloud SQL's built-in replication to create a cross-region replica, and enable failover. Failover automatically recovers to the latest transaction.

Why wrong: Failover recovers to the latest available state, not a specific point in time.

Export the database daily using gcloud sql export and store in Cloud Storage with versioning.

Why wrong: Exports are point-in-time snapshots; you cannot recover to an arbitrary second.