Hard Difficulty Questions

Use a stronger read consistency level

Why it fails: 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 it fails: This would reduce write latency due to less replication, but would compromise global availability and durability.

Enable follower reads

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

Use a single row per sensor with column qualifiers as timestamps

Why it fails: This would create a wide row that can exceed limits and cause hotspots on the sensor node.

Use timestamp as the row key and sensor ID as column qualifier

Why it fails: This would spread each sensor's data across many tablets, hurting scan performance.

Use a random prefix to distribute writes evenly

Why it fails: Random prefix distributes writes but scatters sensor data across tablets, making range reads inefficient.

Create a service account key and mount it as a secret in the pod

Why it fails: This would use long-lived keys, which Workload Identity is designed to avoid.

Grant the GSA the roles/iam.serviceAccountUser role on the project

Why it fails: This would allow the GSA to be used by users, not bind a KSA to a GSA.

Add an annotation to the GSA referencing the KSA, and grant the KSA the iam.workloadIdentityUser role on the GSA

Why it fails: The annotation is on the KSA, not the GSA.

Increase the SLO target to 99.99% to reduce future burn rate.

Why it fails: Raising the target to 99.99% does not restore the exhausted error budget and makes compliance harder, since current performance already misses it. It is tempting as a way to appear rigorous, and would be correct only when deliberately tightening reliability goals after capacity and remediation work.

Trigger a rollback of the latest deployment to stabilize the service.

Why it fails: Rolling back addresses the change that likely caused the failures, but the stem gives no evidence linking the deployment to the SLO breach. Rollback is the right first move when a recent release correlates with a spike in errors; here it is speculative and may itself cause further disruption.

Scale up the service to handle more traffic and reduce error rate.

Why it fails: Scaling up assumes the breach stems from capacity limits, yet the stem provides no saturation or load evidence. Horizontal scaling is correct when metrics show resource exhaustion driving errors; applying it here risks masking the fault and consuming budget without restoring availability.

Preconfigured WAF rules

Why it fails: Preconfigured WAF rules match known attack signatures such as SQL injection and XSS; they do not present a reCAPTCHA challenge or check a challenge token. They are tempting as a ready-made Cloud Armor security control, but the reCAPTCHA gate needs the bot-management challenge rule instead.

Adaptive Protection

Why it fails: Adaptive Protection applies machine-learning anomaly detection to flag and block suspicious Layer 7 traffic patterns; it cannot issue or validate a reCAPTCHA challenge. It is tempting because it enforces security at the edge, but the reCAPTCHA gate requires the separate bot-management challenge integration.

Rate limiting

Why it fails: Rate limiting throttles request volume per client IP or key over a time window; it cannot verify that a user completed a reCAPTCHA challenge. It is tempting because it mitigates abusive traffic at the edge, but the reCAPTCHA gate requires the bot-management challenge rule, not a request-rate threshold.

Create a read replica in a different region.

Why it fails: A read replica in another region serves read scaling and cross-region disaster recovery; it cannot be promoted automatically on zonal failure, so the primary's zone loss still causes an outage. It is tempting because replicas do provide a copy of data, but failover remains manual.

Export the database daily and import into a new instance if failure occurs.

Why it fails: Daily export and import is a backup and recovery method with hours of data loss and manual intervention, not automatic failover. It suits disaster recovery or migration between instances, whereas a regional instance with a standby replica provides the required zonal resilience.

Deploy Cloud SQL across multiple regions using cross-region replication.

Why it fails: Cross-region replication asynchronously copies data to another region for disaster recovery, not zonal failover; it provides no automatic failover and no standby instance in a second zone. It is tempting because it protects against region-wide outages, which is a different requirement from the zonal resilience described here.

Switch to BigQuery Editions with Autoscaling slots

Why it fails: Changing slot pricing models does not inherently improve query performance; it may increase cost without performance gain.

Use SELECT * only when necessary

Why it fails: Avoiding SELECT * is a best practice but does not address the performance issue for the described query.

Create a materialised view that pre-aggregates the data

Why it fails: Materialised views can improve performance but may increase storage costs. The question asks to optimise without increasing slot costs, but materialised views do not directly affect slot costs; they use storage. The question's focus is on performance optimisation without increasing slot costs, and materialised views are not strictly necessary if partitioning and clustering are applied.

Cloud HSM

Why it fails: Cloud HSM provides hardware-backed key storage and cryptographic operations, not secret payload storage or scheduled rotation. It is tempting because it hardens key material, but the requirement for automatic 30-day rotation and Cloud Functions integration points to Secret Manager, which handles secret versions and rotation directly.

Cloud KMS

Why it fails: Cloud KMS manages encryption keys and performs cryptographic operations; it does not store secret payloads or rotate them on a schedule. It is tempting because both concern credentials, but automatic 30-day rotation with Cloud Functions integration is Secret Manager's role, not KMS's key lifecycle.

Cloud Asset Inventory

Why it fails: Cloud Asset Inventory catalogs and exports resource metadata; it neither stores secret values nor rotates them. It is tempting because it inventories GCP resources including secrets, but listing assets is unrelated to holding credentials, scheduling 30-day rotation, or serving secrets to Cloud Functions at runtime.

A single-region deployment for consistency

Why it fails: A single-region deployment is vulnerable to regional outages.

Load testing to validate performance

Why it fails: Load testing is part of performance testing, not core to DR plan.

Enable GKE node auto-upgrade, configure Pod Disruption Budgets (PDB) with minAvailable 1, and set readiness probes to check application health.

Why it fails: Node auto-upgrade, PDBs, and readiness probes improve maintenance resilience and restart handling but leave the 512Mi memory limit, absent autoscaling, and unpooled hardcoded connections untouched, so OOM kills and timeouts persist. It is tempting because these controls govern disruption during node maintenance, which the stem also mentions.

Migrate the database to a StatefulSet in GKE with persistent volumes, increase node count to 10, and enable cluster autoscaler.

Why it fails: Running PostgreSQL in a StatefulSet replaces managed Cloud SQL with self-managed storage, adding operational risk and not resolving OOM kills, latency, or connection exhaustion. It is tempting when workloads need co-located stateful storage, but the stem's database is already managed and the failures stem from resource sizing and connection handling.

Increase memory limits to 2 Gi and CPU to 2, add Horizontal Pod Autoscaler (HPA) based on CPU utilization, and implement connection pooling using Cloud SQL Auth Proxy.

Why it fails: Increases limits may reduce OOM but does not address readiness probes or node maintenance; CPU-based HPA may not respond to latency spikes.

Cloud Logging

Why it fails: Cloud Logging records audit entries for API-driven configuration changes, but firewall rule modifications surface through Admin Activity audit logs, which must be routed to a log sink for retention and review; Cloud Logging alone is the raw capture layer, not the audit destination. It is the right tool for querying and exporting log data generally.

Cloud Monitoring

Why it fails: Cloud Monitoring collects metrics, uptime checks and alerting policies on resource performance; it does not record who changed a firewall rule or when. It tempts because it surfaces anomalies and dashboards, but configuration-change auditing requires Admin Activity audit logs, which Monitoring neither stores nor exposes as change records.

VPC Flow Logs

Why it fails: VPC Flow Logs capture sampled IP traffic metadata for connections through subnets, recording source, destination and disposition, not administrative API calls that alter firewall rules. It appeals for network forensics and traffic analysis, but change auditing needs Admin Activity audit logs, which Flow Logs never generate.

Use a Cloud Load Balancer in front of the managed instance group.

Why it fails: Already implied; does not address database availability.

Deploy a read replica of the Cloud SQL instance in another region.

Why it fails: Read replica is for read scaling, not automatic failover; also not cross-zone.

Take frequent snapshots of the boot disk and store them in a multi-regional bucket.

Why it fails: Snapshots are not a high-availability solution; recovery time is too long.

Use a custom runner.

Why it fails: A custom runner changes where and how pipeline code executes, not the volume of worker compute consumed, so it does not reduce processing charges. It tempts because custom runners can cut costs for non-Dataflow workloads, but Dataflow billing is driven by worker vCPU and memory hours.

Increase the number of workers.

Why it fails: Adding workers increases the total vCPU and memory hours billed, raising processing cost rather than reducing it. It tempts because more workers shorten wall-clock runtime, but Dataflow charges for aggregate resource consumption, so throughput gains do not offset the extra capacity.

The startup script is not executable.

Why it fails: The script is being executed; the error occurs when trying to fetch the script from GCS.

The instance does not have the appropriate IAM permissions to read from Cloud Storage.

Why it fails: While permission issues are possible, the error message specifically says 'Could not find resource', not a permission denied error. Permission denied would typically return a 403 error.

The instance has no network connectivity to access Cloud Storage.

Why it fails: Network connectivity would likely result in a timeout or connection refused, not a 'Could not find resource' error.

Use Storage Transfer Service

Why it fails: Storage Transfer Service is for data already in the cloud or from HTTP/HTTPS sources, not for on-premises bulk.

Use gsutil rsync to transfer the data

Why it fails: gsutil rsync over 100 Mbps would take ~19 days, exceeding the one-week deadline.

Use Velostrata (Migrate for Compute Engine)

Why it fails: Velostrata is for VM migration, not bulk data transfer.

Increase the maximum number of concurrent function instances.

Why it fails: More instances do not increase memory per instance; the existing instances will still hit the limit.

Enable Pub/Sub batching to reduce the number of function invocations.

Why it fails: Batching reduces invocations but each invocation may still process a large message and exceed memory.

Split the function into multiple smaller functions, each handling a subset of the data.

Why it fails: Splitting functions increases complexity and may not solve the per-message memory issue if each message is large.

The user lacks IAM permissions to create firewall rules.

Why it fails: An IAM permission gap produces an authorisation or 403 error, not a conflict stating the resource already exists; that message means the firewall rule is already present in the project or was created outside the deployment. It is tempting because permission failures are common in deployments, but the specific 'already exists' text points to a naming collision, not access rights.

The network reference in the firewall rule is incorrect.

Why it fails: An incorrect network reference would surface as a validation or reference-resolution error, not an 'already exists' conflict. It tempts because firewall rules do reference networks, and misconfiguration is a common deployment failure, but the specific error indicates a naming collision with a resource outside the deployment's management.

The deployment does not include a 'delete' policy for existing resources.

Why it fails: Deployment Manager does not reconcile pre-existing resources unless the config declares them as existing via an 'action: acquire' or the resource is imported; a delete policy governs teardown, not creation conflicts. It tempts because deletion policies matter for cleanup scenarios, but the error stems from an unmanaged resource occupying the name.

The ImagePullSecret is not correctly base64-encoded.

Why it fails: The error is AccessDenied, not Unauthorized or ImagePullSecret errors. If the secret were malformed, the error would typically be different.

The network policy blocks egress traffic to the Container Registry's endpoints.

Why it fails: Network policies in GKE are ingress- or egress-based; by default, if no egress policy is defined, all egress is allowed. The error is AccessDenied, not network timeout.

The cluster's private cluster feature prevents access to external registries.

Why it fails: The exhibit does not indicate a private cluster; even if it were, private clusters can still pull images from external registries via Cloud NAT or VPC peering.

Grant the service project's Cloud SQL service account the Cloud SQL Client role on the host project

Why it fails: Cloud SQL Client grants data-plane access to an instance, not cross-project connectivity; the service project's own service account already holds it on its own resources. It is tempting because IAM roles do control Cloud SQL access, but Shared VPC connectivity is governed by firewall rules and the host project's network, not by granting this role.

Configure VPC peering between host and service project

Why it fails: VPC peering connects two separate VPC networks, whereas Shared VPC places service project resources directly inside the host project's network, so no peering is needed or possible. It is tempting because peering is the standard answer for joining distinct VPCs, but Shared VPC already provides that shared network.

Enable the Cloud SQL Admin API in the service project

Why it fails: Enabling the Cloud SQL Admin API in the service project only permits that project to create and manage its own instances; it does not grant network reachability to an instance living in the host project. It is tempting because API enablement is a prerequisite for Cloud SQL usage, but it is scoped per project and irrelevant to cross-project Shared VPC access.

Use a rate-based rule to limit requests from those IP ranges and add a reCAPTCHA action.

Why it fails: Rate-based does not block all requests.

Create a whitelist rule for the IP ranges and attach it as a deny rule with higher priority.

Why it fails: Whitelist allows all from that IP; need to block unless token.

Use Identity-Aware Proxy (IAP) to block the IPs and reCAPTCHA for others.

Why it fails: IAP is for user identity, not fine-grained IP blocking with CAPTCHA.