Deploying and implementing a cloud solution practice questions

gcloud vm create web-01 --zone=us-central1-a --machine=e2-medium

Why wrong: `gcloud vm` is not a valid command group. The correct group is `gcloud compute instances`.

gcloud instances create web-01 --region=us-central1 --type=e2-medium

Why wrong: `gcloud instances` is not a valid subcommand group. The full path is `gcloud compute instances`. `--type` is also not a valid flag — use `--machine-type`.

gcloud compute create-instance web-01 --zone=us-central1-a --size=e2-medium

Why wrong: `create-instance` is not a valid subcommand. The correct subcommand is `instances create`. `--size` is also not a valid flag.

kubectl create -f api-deployment.yaml

Why wrong: `kubectl create -f` fails with an error if the resource already exists — it is not idempotent like `apply`.

kubectl run api-deployment.yaml

Why wrong: `kubectl run` creates a Pod directly from an image name — it does not apply a YAML manifest file.

kubectl deploy -f api-deployment.yaml

Why wrong: `kubectl deploy` is not a valid kubectl command. Use `kubectl apply` or `kubectl create`.

gcloud run create api-service --image=gcr.io/myproject/api:v2 --zone=us-east1 --public

Why wrong: `gcloud run create` is not a valid command. Use `gcloud run deploy`. `--zone` is not used by Cloud Run; `--public` is not a valid flag.

gcloud cloud-run deploy api-service --container=gcr.io/myproject/api:v2 --region=us-east1

Why wrong: `gcloud cloud-run` is not a valid command group. Use `gcloud run`. `--container` is also not the correct flag — use `--image`.

gcloud run deploy --name=api-service --image=gcr.io/myproject/api:v2 --region=us-east1 --no-auth

Why wrong: The service name is a positional argument, not a `--name` flag. `--no-auth` is not a valid flag — use `--allow-unauthenticated`.

gcloud kubernetes clusters create prod-cluster --location=us-central1 --autoscale=3:10

Why wrong: `gcloud kubernetes` is not a valid command group — use `gcloud container`. `--autoscale=3:10` is not a valid flag syntax.

gcloud container cluster create prod-cluster --zone=us-central1 --scaling=3-10

Why wrong: `cluster create` is missing the plural `clusters`. `--zone=us-central1` is a region, not a zone. `--scaling` is not a valid flag.

kubectl create cluster prod-cluster --region=us-central1 --autoscale --min=3 --max=10

Why wrong: `kubectl` manages resources within an existing cluster — it cannot create GKE clusters. Use `gcloud container clusters create`.

gcloud storage mk gs://my-archive-bucket --location=US

Why wrong: `mk` is not a valid subcommand for `gcloud storage`. Use `buckets create`.

gcloud cloud-storage create my-archive-bucket --region=US

Why wrong: `gcloud cloud-storage` is not a valid command group. Use `gcloud storage`. The bucket name must also be prefixed with `gs://`.

gsutil mk -l US gs://my-archive-bucket

Why wrong: `gsutil mb` (make bucket) is the correct legacy command, not `gsutil mk`. Option D uses `mk` which is invalid.

HTTP trigger

Why wrong: HTTP triggers fire only when a client makes an HTTP request to the function's URL — they don't respond to storage events.

Pub/Sub trigger

Why wrong: Pub/Sub triggers fire on messages published to a topic — not directly on storage uploads (unless storage notifications are separately configured to publish to Pub/Sub).

Cloud Scheduler trigger

Why wrong: Cloud Scheduler invokes functions on a time schedule — it cannot react to storage events.

gcloud app create --config=app.yaml

Why wrong: `gcloud app create` initializes App Engine in the project region — it's a one-time setup step, not for deploying code.

gcloud appengine deploy app.yaml

Why wrong: `gcloud appengine` is not a valid command group. Use `gcloud app`.

gcloud run deploy --platform=appengine

Why wrong: `--platform=appengine` is not a valid flag for `gcloud run deploy`. Cloud Run and App Engine are separate deployment commands.

Auto mode VPCs cost more per subnet than custom mode

Why wrong: VPC networking costs are based on traffic and peering, not the VPC mode — auto and custom mode have the same pricing structure.

Auto mode VPCs cannot be used with GKE clusters

Why wrong: GKE clusters can be deployed in both auto mode and custom mode VPCs.

Custom mode VPCs support more IP addresses per subnet than auto mode

Why wrong: The VPC mode doesn't restrict subnet IP capacity — both modes support the same CIDR sizes.

Cloud Composer

Why wrong: Cloud Composer is managed Apache Airflow — it orchestrates multi-step workflows but doesn't execute Apache Beam pipelines.

Cloud Dataproc

Why wrong: Cloud Dataproc runs Apache Spark and Hadoop clusters — it doesn't natively execute Apache Beam pipelines without additional configuration.

Cloud Data Fusion

Why wrong: Cloud Data Fusion is a visual data integration (ETL) platform — it generates Dataflow or Spark jobs, but Dataflow is the actual execution engine.

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.

volumes: - name: config / configMap: name: app-config

Why wrong: This mounts the ConfigMap as a volume (files) — not as environment variables. An additional `volumeMount` would also be required.

env: - name: CONFIG / valueFrom: secretKeyRef: name: app-config

Why wrong: `secretKeyRef` references a Secret, not a ConfigMap. Use `configMapKeyRef` for individual ConfigMap keys.

envFrom: - secretRef: name: app-config

Why wrong: `secretRef` references a Kubernetes Secret, not a ConfigMap — wrong resource type.

Increase the minimum number of instances to reduce cold starts

Why wrong: Cold start latency causes slow first requests, not timeouts on all long requests. Minimum instances help cold starts, not request processing time limits.

Set concurrency to 1 to ensure each instance handles only one request at a time

Why wrong: Concurrency controls how many requests each instance handles simultaneously — it doesn't change the per-request time limit.

Switch to Cloud Run Jobs instead of Cloud Run Services

Why wrong: Cloud Run Jobs run tasks to completion without HTTP — appropriate for batch jobs, not for serving long-running HTTP requests from clients.

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.

Hardcode the API key in the function source code

Why wrong: Hardcoding secrets in source code is a critical security anti-pattern — source code is often stored in version control accessible to many people.

Pass the API key as a plain-text environment variable in the function configuration

Why wrong: Plain-text environment variables in function configuration are visible to anyone with read access to the Cloud Functions configuration.

Store the API key in a Cloud Storage bucket and download it at function startup

Why wrong: Fetching secrets from Cloud Storage at startup adds latency and still requires securing bucket access — Secret Manager is the purpose-built solution.

A HostPath volume pointing to a directory on the node

Why wrong: HostPath mounts a path on the specific node where the Pod runs — if the Pod is rescheduled to another node, it loses access to that data.

A ConfigMap mounted as a volume

Why wrong: ConfigMaps store configuration data, not application-written state. They're read-only (by design) and not appropriate for stateful write workloads.

An emptyDir volume scoped to the Pod

Why wrong: emptyDir volumes are ephemeral — they exist only while the Pod is running and are deleted when the Pod is removed or rescheduled.

kubectl revert deployment/my-app --to-previous

Why wrong: `kubectl revert` is not a valid kubectl command. Use `kubectl rollout undo`.

kubectl apply -f previous-deployment.yaml

Why wrong: This works if you have the old YAML, but requires the file to be available and up-to-date. `kubectl rollout undo` is simpler and uses Kubernetes' built-in revision history.

kubectl delete deployment/my-app && kubectl create -f deployment.yaml

Why wrong: Deleting and recreating causes unnecessary downtime and loses Deployment history. `kubectl rollout undo` is the correct tool.

Include a Bearer token in the Authorization header of the scheduled HTTP request

Why wrong: Static Bearer tokens are not recommended — they are long-lived credentials. OIDC tokens are short-lived and generated dynamically by Cloud Scheduler.

Make the Cloud Run service publicly accessible and use Cloud Armor to restrict access to Cloud Scheduler IPs

Why wrong: Cloud Scheduler IPs are not static — using OIDC is the correct, scalable authentication approach.

Configure an API key for the Cloud Run service and include it in the scheduled request URL

Why wrong: Cloud Run authentication uses IAM/OIDC tokens — API keys are not a valid authentication mechanism for Cloud Run.

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.

Cloud Composer with a Git polling DAG

Why wrong: Cloud Composer (managed Airflow) orchestrates data pipelines — it's not designed for CI/CD workflows triggered by code pushes.

Cloud Run jobs triggered by a Pub/Sub subscription on the repository

Why wrong: This is architecturally possible but adds unnecessary complexity — Cloud Build Triggers are the native, purpose-built CI/CD solution.

Cloud Functions triggered by Cloud Source Repositories push events

Why wrong: Cloud Functions aren't designed for multi-step build and deploy pipelines — they're for lightweight event handlers.

gcloud artifacts docker push myimage --location=us-central1 --repository=myrepo

Why wrong: `gcloud artifacts docker push` is not a valid command. Docker images are pushed using the standard `docker push` command after tagging.

docker push gcr.io/myproject/myimage:v1

Why wrong: This pushes to Container Registry (gcr.io), not Artifact Registry (pkg.dev). The registry host and path format are different.

gcloud container images push myimage:v1 --region=us-central1

Why wrong: `gcloud container images push` is not a valid command. Use standard `docker tag` and `docker push` commands.