Deploying and Implementing a Cloud Solution practice questions

gcloud compute instances create my-instance --machine-type=n1-standard-1 --image-family=debian-10 --image-project=debian-cloud --boot-disk-size=50 --zone=us-central1-a

Why it fails: Image family is debian-10, not debian-11; boot-disk-size needs units (GB).

gcloud compute instances create my-instance --machine-type=n1-standard-1 --image-family=debian-11 --image-project=debian-cloud --boot-disk-size=50GB --region=us-central1-a

Why it fails: --region is used for regional resources; instances live in zones, so --zone is required.

gcloud compute instances create my-instance --machine-type=n1-standard-1 --image-family=debian-11 --image-project=debian-cloud --root-disk-size=50GB --zone=us-central1-a

Why it fails: --root-disk-size is not a valid flag; it should be --boot-disk-size.

kubectl create deployment web --image=web:v1; kubectl expose deployment web --type=LoadBalancer --port=80; then reserve a regional static IP with gcloud compute addresses create web-ip --region us-central1 and assign it via annotation.

Why it fails: For a regional cluster, you should use a regional static IP, not global. However, the correct command to assign IP is via '--load-balancer-ip' or annotation, but the provided option is incomplete.

kubectl create deployment web --image=web:v1 --replicas=3; kubectl expose deployment web --type=NodePort --port=80; then use gcloud compute addresses create web-ip --global; kubectl patch service web -p '{"spec":{"loadBalancerIP":"<IP>"}}'

Why it fails: NodePort does not provide a load balancer; you cannot assign loadBalancerIP to a NodePort service.

gcloud compute addresses create web-ip --global; then kubectl create deployment web --image=web:v1; kubectl expose deployment web --type=LoadBalancer --port=80; then patch service to set loadBalancerIP.

Why it fails: Global static IP is used for global load balancers (HTTP/HTTPS), not for TCP/UDP LoadBalancer services in GKE.

gsutil mb -s standard -l us-west1 gs://my-bucket

Why it fails: -s is not a valid flag for gsutil mb; use -c for storage class.

gsutil mb -l us-west1 gs://my-bucket

Why it fails: Although this creates a bucket with default Standard class, the question explicitly asks to set the storage class; this command does not specify a class.

gcloud storage buckets create --storage-class=standard --location=us-west1 gs://my-bucket

Why it fails: gcloud storage buckets create command does not have --storage-class flag; use --default-storage-class or use gsutil.

Run 'terraform state rm google_container_cluster.my_cluster' to remove the cluster from state, then decide whether to recreate.

Why it fails: Running `terraform state rm google_container_cluster.my_cluster` surgically removes that resource from the Terraform state file, so Terraform no longer tracks the already-deleted cluster. After this, `terraform plan` will show no diff for that cluster, and you can explicitly decide whether to recreate it via a new `terraform apply` or leave it permanently removed. This is the approved workflow for reconciling state when a resource was deleted outside of Terraform.

Run 'terraform apply' again to recreate the cluster.

Why it fails: Running `terraform apply` again will detect that the cluster is missing in the cloud and try to recreate it using the configuration, but this implicitly assumes you want the cluster restored just as it was, rather than letting you first update the configuration or assess whether it should exist at all. It also leaves the stale state entry present during the apply, and if the cluster name or underlying network has been changed or is in a deletion-in-progress state, the apply can fail with a conflict. The correct move is to remove the stale state entry first, then decide whether recreation is warranted.

Run 'terraform destroy' to destroy all resources.

Why it fails: Running `terraform destroy` is far too destructive: it attempts to delete every resource tracked in the state, including node pools, VPCs, or other infrastructure that may still be in use. Because the cluster is already gone, `terraform destroy` would either fail trying to delete a non-existent resource or – if the provider treats a 404 as success – it would silently drop the cluster from state as part of a much larger teardown. This does not give you the option to selectively remove just the cluster and keep the rest of your infrastructure.

Use gsutil mv -s nearline file.txt gs://my-bucket.

Why it fails: The gsutil mv command performs a copy-and-delete operation and does not accept the -s flag to set storage class. Passing -s nearline will cause gsutil to fail with an unrecognized-option error because mv only forwards a limited subset of cp's flags. To move a file while setting its storage class, you must use gsutil cp -s nearline followed by a separate removal, or rely on the bucket's default.

Upload with --storage-class nearline flag on gsutil cp.

Why it fails: The --storage-class flag is not a valid option for gsutil cp. The correct long-form syntax is the short -s flag, as in gsutil cp -s nearline file.txt gs://my-bucket. Using --storage-class will make gsutil reject the command with an invalid-option error. This distinction matters because the double-dash long-form is commonly misremembered from other tools like gcloud or AWS CLI.

In Cloud Build history page.

Why it fails: Build logs are in Cloud Build, but runtime logs are in Cloud Logging.

In the Cloud Run service details page under 'Logs' tab.

Why it fails: There is a Logs tab? Actually Cloud Run console has a 'Logs' tab that shows logs from Cloud Logging. So this is also correct? The question asks 'where can you view' – both options A and B might be correct. But we need to pick one. The typical answer is Cloud Logging. I'll go with B.

In Cloud Monitoring dashboards.

Why it fails: Monitoring is for metrics, not logs.

Lock the retention policy using gsutil retention lock gs://my-bucket.

Why it fails: Incorrect. Locking the retention policy makes it permanent and unchangeable, but the question does not specify that the policy must be locked; it only requires preventing deletion for 30 days.

Set an IAM policy to prevent deletion.

Why it fails: Incorrect. IAM policies control who can delete objects but do not prevent deletion outright if the user has delete permission.

Set a retention policy using gsutil retention set 30d gs://my-bucket.

Why it fails: Incorrect. Setting a retention policy with a duration specifies the minimum time objects must be retained, but without versioning or holds, objects can still be deleted after that period.

gcloud compute instances create my-vm --machine-type=n1-standard-2 --subnet=my-subnet --startup-script='echo Hello'

Why it fails: Incorrect. The `--startup-script` flag does not exist; startup scripts are provided via `--metadata startup-script`.

gcloud compute instances create my-vm --machine-type=n1-standard-2 --network=my-subnet --metadata startup-script='echo Hello'

Why it fails: Incorrect. Uses `--network` instead of `--subnet`; the subnet must be specified with `--subnet`.

Use 'gcloud compute ssh' with the --tunnel-through-iap flag

Why it fails: IAP tunneling is for accessing instances without external IPs, not for enforcing OS Login.

Set metadata 'enable-oslogin=FALSE' at the instance level

Why it fails: This disables OS Login.

Set metadata 'block-project-ssh-keys=TRUE' at the instance level

Why it fails: This blocks project-wide SSH keys but does not enforce OS Login.

response.end(JSON.stringify({ 'status': 'ok' }))

Why it fails: The parameter is named 'res' in Cloud Functions' HTTP trigger signature, so 'response' is undefined in this scope. Even if it were defined, calling .end() only writes the raw string without setting the Content-Type header to application/json; the client would receive the correct body but not as encoded JSON. In practice, this code would raise a ReferenceError before sending anything, which is why it is incorrect.

return { 'status': 'ok' }

Why it fails: For an HTTP-triggered Cloud Function, returning a plain object from your function does not automatically send it to the client. The function signature provides a response object, and you must explicitly call a method like res.send() or res.json() to write the HTTP response. The returned value is ignored unless it is a Promise that triggers asynchronous work; otherwise, the function ends without completing the request, causing a timeout or a 500 error.

context.done(null, { 'status': 'ok' })

Why it fails: The context.done callback is part of the background (event-driven) functions contract, not HTTP triggers. When using an HTTP trigger, the function receives a request and a response object, and you must use res.send(), res.end(), or res.status() to finish the request. If you attempt to call context.done, the context object may be undefined for an HTTP function, and even if it exists, it cannot send a response to the client, so the request remains unresolved.

Increase the autoscaling cooldown period

Why it fails: Increasing the autoscaling cooldown period lengthens the wait time after a scaling event before the autoscaler can evaluate metrics again. In a sudden spike, the first scale-up triggers a cooldown, and if that cooldown is longer, the autoscaler will take more time to detect continued high utilization and initiate further scale-ups. This directly delays the scaling response, making the MIG slower to reach the required capacity, so it is the opposite of what is needed for fast reaction to a surge.

Decrease the autoscaling cooldown period

Why it fails: Decreasing the autoscaling cooldown period shortens the delay after a scaling event before the autoscaler re-evaluates load metrics. When a spike occurs, the autoscaler can detect that utilization is still above the target threshold sooner after each scale-up, triggering additional instances in quicker succession. This accelerates the overall scaling process, allowing the MIG to better keep up with sharp, immediate increases in traffic, though it must be tuned to avoid flapping.

Use a larger machine type in the instance template

Why it fails: Choosing a larger machine type increases the capacity of each individual instance, so fewer instances may be needed to handle the same load, but it does not change the autoscaler's timing logic. The autoscaler still waits for the cooldown period after each scaling event and evaluates utilization at the same frequency, so the speed at which new instances are added remains unchanged. While a larger instance might reduce the number of scaling events required, it does not make the MIG scale up faster in response to a sudden spike, so it fails to address the core latency issue.

Set a firewall rule allowing ingress from the IP 203.0.113.5 to port 22

Why it fails: A firewall rule allowing ingress from 203.0.113.5 to port 22 is misguided because the instance has only an internal IP address, so the external client cannot route directly to it. In IAP tunneling, the TCP connection originates not from the client's IP but from IAP's proxy service, specifically from the 35.235.240.0/20 address range; therefore the source in the rule would never match the actual traffic. The correct firewall practice is to permit ingress from IAP's proxy ranges to port 22 on the instance, not from the user's public IP.

Modify the Cloud NAT to allow the external IP

Why it fails: Cloud NAT translates outbound traffic from internal instances to the internet, but it does not accept inbound connections from an external IP; it lacks a mechanism to forward unsolicited inbound traffic to a specific internal instance. This option is tempting because Cloud NAT is often used to grant external access for outbound traffic, and one might assume it can be reversed for inbound access, but it would only be correct if the requirement were to allow the instance to reach the internet, not to allow an external IP to reach the instance.

Assign a public IP to the instance

Why it fails: Assigning a public IP would violate the explicit requirement that the instance have only an internal IP, and it would expose the VM to the open internet, expanding its attack surface unnecessarily. Even with a public IP, you would need a separate firewall rule allowing SSH from 203.0.113.5, thereby abandoning IAP's identity-based access controls and audit logging. IAP tunneling is precisely the mechanism that avoids public IP exposure while still granting secure, user-specific access.

gcloud compute instances create my-vm --image debian-11 --boot-disk-size 50 --subnet my-subnet

Why it fails: This command incorrectly uses the --image flag, which requires an exact image name, not a family alias like debian-11; the correct flag is --image-family. It also omits --image-project, so gcloud cannot resolve the image project. Additionally, --boot-disk-size should include an explicit unit, e.g., 50GB, rather than a bare number.

gcloud compute instances create my-vm --image-family debian-11 --image-project debian-cloud --disk-size 50GB --subnet my-subnet

Why it fails: The flags --image-family and --image-project correctly identify the Debian 11 image family, but the command uses --disk-size, which is not a valid flag for gcloud compute instances create. The correct flag for the root disk is --boot-disk-size, so this command will fail with an unknown flag error. No other issues are present; the boot disk size value 50GB is properly formatted.

gcloud compute instances create my-vm --image-family debian-11 --boot-disk-size 50 --subnet my-subnet

Why it fails: This command correctly uses the --image-family flag, but it omits --image-project, which is required to locate the image family in the public debian-cloud project; without it, gcloud may default to your own project's images and fail. Additionally, --boot-disk-size is given as a bare 50, which is implicitly GB but should be written as 50GB for clarity and to match documented syntax, and the lack of an explicit unit can lead to confusion.

gcloud compute instance-groups managed update my-mig --autoscaling --cpu-utilization 60

Why it fails: This command is invalid because the gcloud compute instance-groups managed update subcommand is used for updating instance group properties such as size or template, not for configuring autoscaling. The --autoscaling flag does not exist on the update command; you must use set-autoscaling. Additionally, --cpu-utilization 60 is incorrect because the target CPU utilization must be provided as a decimal (0.6), not an integer percentage.

gcloud compute instance-groups managed configure-autoscaling my-mig --region us-central1 --target-cpu-utilization 0.6

Why it fails: This command fails because configure-autoscaling is not a recognized subcommand in the gcloud compute instance-groups managed group. The correct verb is set-autoscaling, which is the only command that accepts autoscaling policy flags. Even though the other flags like --region and --target-cpu-utilization are appropriately used for a regional MIG, the invalid command name causes the operation to fail before any changes are made.

gcloud compute instance-groups managed set-autoscaling my-mig --zone us-central1-a --max-num-replicas 10 --target-cpu-utilization 60

Why it fails: This command uses --zone us-central1-a, which targets a zonal managed instance group, but the MIG in question is regional, so the --region us-central1 flag is required. Additionally, --target-cpu-utilization 60 is incorrect because the flag expects a decimal fraction, so 60% must be expressed as 0.6, not the integer 60. Both the scope and the utilization value are wrong, making this option invalid.

gcloud container deployments create my-deployment --config deployment.yaml

Why it fails: This command is invalid because gcloud does not manage Kubernetes resources. The gcloud CLI is used for GCP services such as clusters, compute instances, and IAM. Deployments are Kubernetes API objects, so they must be created via kubectl, which communicates with the cluster's API server. The --config flag is not a recognized parameter for gcloud.

kubectl create -f deployment.yaml

Why it fails: kubectl create -f deployment.yaml attempts to create the deployment imperatively. If a deployment with the same name already exists, the command fails with an error, making it unsuitable for idempotent updates. In contrast, kubectl apply reconciles the desired state in the YAML file with the live cluster state, updating only the necessary fields.

kubectl run deployment --image=my-image --restart=Always

Why it fails: The syntax is wrong: 'kubectl run' creates a Pod by default, not a Deployment. Here the string 'deployment' is treated as the Pod's name rather than a resource type. Additionally, the command does not reference the YAML file and lacks the necessary --generator or --restart=Policy to create a Deployment. As written, it would create a standalone Pod, not manage a Deployment.

gcloud storage buckets create my-bucket --storage-class nearline --location us-east1

Why it fails: gcloud storage buckets create uses --default-storage-class, not --storage-class. Also, the bucket name must include gs://.

gcloud mb --class nearline --region us-east1 gs://my-bucket

Why it fails: 'gcloud mb' is not a valid command; use 'gsutil mb'.

gsutil mb --storage-class nearline --location us-east1 gs://my-bucket

Why it fails: These flags are not valid in gsutil; use -c and -l.

gsutil acl ch -u AllUsers:R gs://my-bucket

Why it fails: This command is wrong for two distinct reasons. First, the principal token must be exactly `allUsers` (all lowercase, no quotes) when using Cloud Storage IAM or ACLs; `AllUsers` is case-sensitive and not recognized, so the command would fail. Second, `gsutil acl ch` operates on legacy bucket/object ACLs, not on IAM policy. Even if you corrected the principal to `allUsers`, using ACLs is deprecated and not the preferred approach for public access; IAM (`gsutil iam`) is the current recommended method.

gcloud storage buckets add-iam-policy-binding my-bucket --member allUsers --role roles/storage.objectViewer

Why it fails: This gcloud command is invalid because the bucket argument must include the `gs://` prefix; the resource path should be `gs://my-bucket`, not just `my-bucket`. While `gcloud storage buckets add-iam-policy-binding` is a valid command to modify IAM bindings, omitting the scheme causes the CLI to fail with a resource-not-found or input-validation error. Correctly formed, the command would work (with `--member allUsers` and `--role roles/storage.objectViewer`), but as written it is syntactically incorrect.

gsutil iam set public-read gs://my-bucket

Why it fails: This fails because `gsutil iam set` does not accept predefined policy names like `public-read`; it expects a path to a JSON or YAML file containing a complete IAM policy. Additionally, `iam set` replaces the entire IAM policy, which is risky and could accidentally remove existing bindings. There is no predefined `public-read` IAM policy; the correct way to grant public read access is `gsutil iam ch allUsers:objectViewer gs://my-bucket`.

App Engine Standard Environment

Why it fails: App Engine Standard Environment uses specific runtimes, not custom containers, and its scaling is not primarily based on CPU usage.

Cloud Run

Why it fails: Cloud Run is a serverless container platform that scales based on request concurrency, not CPU usage, so it does not meet the CPU-based scaling requirement.

Managed Instance Groups

Why it fails: Managed Instance Groups are used for managing VM instances, not containers, and are not a container-native solution.

gcloud compute instances create my-instance --zone=us-west1-a --machine-type=e2-medium --image-family=debian-11 --image-project=debian-cloud --boot-disk-size=50GB --no-address

Why it fails: Incorrect because --no-address creates an instance without a public IP, which is not specified in the requirements.

gcloud compute instances create my-instance --zone=us-west1 --machine-type=e2-medium --image-family=debian-10 --image-project=debian-cloud --boot-disk-size=50GB

Why it fails: Incorrect because it uses image family debian-10 (should be debian-11) and zone us-west1 (should be us-west1-a).

gsutil mb -s nearline -l US gs://my-bucket

Why it fails: Incorrect. The -s flag is not valid for gsutil mb; -c is used to specify storage class.

gsutil mb -c nearline -l US-CENTRAL1 gs://my-bucket

Why it fails: Incorrect. US-CENTRAL1 is a single region, not a multi-region. The requirement is US multi-region.