Hard Difficulty Questions

Sustained use discounts (automatically applied)

Why wrong: Sustained use discounts apply automatically for VMs running more than 25% of a month, but their maximum savings (30% for N2) are lower than 3-year CUDs.

1-year committed use discount (CUD)

Why wrong: 1-year CUDs offer approximately 37% discount — better than SUDs, but less than 3-year CUDs.

Switching to Spot VMs

Why wrong: Spot VMs offer deep discounts but can be preempted at any time — they are not suitable for stable production workloads that must run continuously.

IAM deny policies on the organization + VPC Service Controls

Why wrong: IAM deny policies block specific actions, and VPC Service Controls limit API access — neither directly constrains where new projects can be created or which billing accounts they can use.

Cloud Asset Inventory alerts + manual review of new projects

Why wrong: Asset Inventory can detect non-compliant projects after creation, but doesn't prevent them — reactive, not preventive.

Requiring multi-factor authentication for all project creators

Why wrong: MFA controls authentication strength — it doesn't enforce where projects are created or which billing accounts they use.

A NodePort Service for the backend

Why wrong: NodePort exposes the service on a port of every node's IP — it's reachable from outside the cluster, not just internally.

A LoadBalancer Service for the backend

Why wrong: LoadBalancer provisions an external cloud load balancer — exposing the backend publicly, which violates the requirement.

A Kubernetes Ingress resource for the backend

Why wrong: Ingress routes external HTTP/HTTPS traffic into the cluster — it doesn't provide internal service-to-service discovery.

Google-managed encryption keys (the default)

Why wrong: With GMEK, Google creates, stores, and manages encryption keys — the customer has no control over the keys and Google can theoretically access the data.

Client-side encryption before uploading to Cloud Storage, without using Cloud KMS

Why wrong: Client-side encryption works technically, but it doesn't use GCP's key management infrastructure — audit logging, key rotation, and IAM-based access control for keys are all missing.

Shielded VM with vTPM enabled on the storage backend

Why wrong: Shielded VM protects VM integrity (boot security) — it doesn't control encryption keys for Cloud Storage objects.

gcp backend storing state in a BigQuery table

Why wrong: Terraform has no native `gcp` or BigQuery backend. BigQuery is not supported as a Terraform state backend.

remote backend connected to a Cloud SQL database

Why wrong: The `remote` backend in Terraform connects to Terraform Cloud/Enterprise — not Cloud SQL. Cloud SQL is not a Terraform state backend.

local backend with a path shared over Cloud Filestore

Why wrong: A local backend stores state on the local filesystem. Even if shared via Filestore, it lacks built-in state locking and is error-prone for team use.

Delete all unhealthy instances manually; the MIG will recreate them with the old template

Why wrong: Deleting instances will cause the MIG to recreate them with the new (broken) template, not the old one — this doesn't resolve the issue.

Increase the target size of the MIG to dilute the unhealthy instances

Why wrong: New instances created during a scale-out will use the new (broken) template — this doesn't fix the issue and wastes resources.

Disable autohealing temporarily to prevent the MIG from restarting instances

Why wrong: Disabling autohealing prevents automatic recovery of unhealthy instances — it makes the situation worse, not better.

200 separate Cloud SQL instances, one per customer

Why wrong: 200 separate Cloud SQL instances generate significant operational overhead (patching, monitoring, backups), costs, and slow provisioning — not scalable.

Storing all customer data in a single shared database with customer_id as a discriminator column

Why wrong: A shared database with a discriminator column provides no true data isolation — a query bug could expose one customer's data to another.

Using BigQuery with a separate dataset per customer

Why wrong: BigQuery is an analytics warehouse — it's not appropriate for transactional SaaS application databases requiring row-level operations.

Shielded VMs with Secure Boot enabled

Why wrong: Shielded VMs protect against boot-level attacks using TPM and Secure Boot — they don't encrypt network traffic between VMs.

VPC firewall rules denying all non-encrypted traffic

Why wrong: VPC firewall rules control whether traffic is allowed or denied based on port/protocol/IP — they can't inspect or enforce encryption of allowed traffic.

Enabling VPC Flow Logs on all subnets

Why wrong: VPC Flow Logs capture traffic metadata for analysis — they don't encrypt traffic.

Rotate the service account key to generate a new one, keeping the old key active briefly for transition

Why wrong: The old key remains active during transition and is still compromised — it must be immediately deleted, not kept active.

Change the service account's display name and email to invalidate the leaked key

Why wrong: Service account names and emails are metadata — changing them does not invalidate existing keys.

Remove all IAM roles from the service account to deny all actions until the investigation completes

Why wrong: Removing IAM roles may help but the key still exists and could be re-used if roles are re-added. The key itself must be deleted first.

A LoadBalancer Service with path routing rules

Why wrong: Kubernetes Services (including LoadBalancer type) operate at Layer 4 — they don't support URL path-based routing.

A NodePort Service with iptables path routing rules

Why wrong: NodePort exposes a port on every node — it doesn't support HTTP path-based routing. iptables rules operate at L3/L4.

Multiple ClusterIP Services with DNS SRV records for path routing

Why wrong: DNS SRV records provide service discovery but don't route HTTP requests by URL path. ClusterIP Services don't support L7 routing.

Store a service account JSON key as a GitHub Actions secret and use it in the workflow

Why wrong: JSON key files are long-lived credentials and a security risk — they can be leaked via logs, forks, or misconfigurations. Workload Identity Federation eliminates the need for key files.

OAuth 2.0 user credentials from a developer's Google account

Why wrong: User credentials tie access to a specific person's account — not appropriate for automated CI/CD pipelines.

API keys created for the Artifact Registry service

Why wrong: Artifact Registry uses IAM for access control — API keys are not a supported authentication mechanism for Artifact Registry.

Customer-Managed Encryption Keys (CMEK) stored in Cloud KMS

Why wrong: With CMEK, the key is stored in Cloud KMS (a Google-managed service). While the customer controls access to the key, Google's infrastructure hosts it — regulators may require the key to never touch Google's systems.

Google-managed encryption keys (default) with restricted IAM policies

Why wrong: Google-managed keys mean Google controls the encryption — IAM policies restrict data access for GCP customers but don't prevent Google from technically accessing the data.

Shielded VM with confidential computing for the VMs that access the data

Why wrong: Confidential VMs encrypt data in use (RAM) during computation — they don't address the Cloud Storage encryption key ownership requirement.

GKE node traffic is unencrypted by default — mTLS must be manually configured on every Pod

Why wrong: GCP's network-level encryption protects VM-to-VM traffic including GKE nodes. mTLS adds an additional application-layer encryption layer but the underlying network traffic is already encrypted.

Enable VPC Flow Logs — they activate encryption for logged traffic

Why wrong: VPC Flow Logs capture metadata for analysis — they have no effect on traffic encryption.

Install a TLS termination proxy on each GKE node — it encrypts intranode traffic

Why wrong: Node-level TLS proxies are not required — GCP's network layer already encrypts VM-to-VM traffic, and Anthos Service Mesh handles application-layer encryption.

Use the Cloud SQL public IP with SSL required — Cloud Run can reach public IPs

Why wrong: Using public IPs exposes the database to the internet unnecessarily — and for truly private instances, public access may be disabled.

Deploy a separate Cloud SQL Auth Proxy container in the same Cloud Run service as a sidecar

Why wrong: Cloud Run Services run a single container per instance — sidecars are not natively supported in Cloud Run (only in Cloud Run for Anthos). The built-in `--add-cloudsql-instances` is the correct approach.

Enable Serverless VPC Access connector to route Cloud Run traffic to the private Cloud SQL IP

Why wrong: Serverless VPC Access connects Cloud Run to private VPC resources — it's useful for other private services, but Cloud SQL connectivity is better handled via the built-in Auth Proxy integration.

`roles/run.admin` only.

Why wrong: run.admin grants Cloud Run management permissions but does not include `iam.serviceAccounts.actAs`, which is required to specify the runtime service account.

`roles/owner` to ensure all necessary permissions are covered.

Why wrong: Owner violates least privilege. The specific permissions needed are well-defined; granting owner is unnecessary and insecure.

`roles/cloudbuild.builds.editor` on the Cloud Run project.

Why wrong: This role grants Cloud Build management permissions, not Cloud Run deployment permissions.

The organization does not exist yet; run `gcloud organizations create` to create it.

Why wrong: GCP organizations are provisioned automatically when a Google Workspace or Cloud Identity domain is connected; there is no `gcloud organizations create` command.

The gcloud SDK does not support the organizations command; use the Cloud Console instead.

Why wrong: `gcloud organizations list` is a valid, supported command that works when the caller has appropriate permissions.

The project must be linked to the organization using `gcloud projects move`.

Why wrong: Project-organization linkage is separate from being able to list organizations; the issue is IAM permissions, not project membership.

Set CPU requests and limits on batch job pods to be lower than web service pods.

Why wrong: Setting lower requests on batch pods reduces their scheduling priority for resources but doesn't prevent them from consuming CPU when web pods' burst headroom is available.

Use Horizontal Pod Autoscaler for batch jobs so they scale down during peak web traffic.

Why wrong: HPA scales pods based on metrics, not on other workloads' needs. Batch jobs won't scale down simply because web services need more CPU.

Enable Cluster Autoscaler so new nodes are added when batch jobs demand more resources.

Why wrong: Cluster Autoscaler adds nodes for unschedulable pods, not for pods already running but competing for CPU. It doesn't prevent existing batch pods from throttling web services on shared nodes.

Add a Cloud Armor security policy to the Cloud Run service blocking all IPs except Cloud Scheduler.

Why wrong: Cloud Armor cannot be attached directly to Cloud Run services (only to load balancers). Also, Cloud Scheduler doesn't have fixed IP ranges to allowlist.

Deploy the Cloud Run service in a VPC and use a VPC firewall rule to block all traffic except Cloud Scheduler.

Why wrong: Cloud Run services are not deployed in a VPC (they use VPC connectors for outbound access). VPC firewall rules don't control inbound access to Cloud Run.

Add a secret header to Cloud Scheduler requests and validate it in the Cloud Run application code.

Why wrong: Custom header validation is a fragile, application-level secret — not a proper authentication mechanism. The secret header could be brute-forced or leaked. OIDC-based IAM authentication is the correct approach.

Set an org policy constraint that applies default IAM bindings to all new projects.

Why wrong: No native org policy constraint applies IAM bindings. Org policies enforce resource configuration constraints, not IAM state.

Require all project creators to use a Terraform module that includes the IAM binding in its configuration.

Why wrong: Terraform modules enforce bindings only for IaC-managed projects. Console-created projects would not get the bindings, creating compliance gaps.

Enable Cloud SQL high availability; the standby replica will serve read traffic.

Why wrong: Cloud SQL HA's standby instance is for failover only — it does not serve read traffic. Only dedicated read replicas can serve read queries.

Scale the primary Cloud SQL instance vertically to a larger machine type.

Why wrong: Vertical scaling has a ceiling and addresses all traffic on one instance. Read replicas horizontally scale read capacity and are specifically designed for read-heavy workloads.

Migrate from Cloud SQL to Cloud Spanner for unlimited horizontal read scalability.

Why wrong: Spanner is a valid long-term solution but requires significant migration effort (schema redesign, application rewrite). Read replicas solve the immediate problem with minimal disruption.