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 wrong: 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 wrong: --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 wrong: --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 wrong: 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 wrong: 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 wrong: 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 wrong: -s is not a valid flag for gsutil mb; use -c for storage class.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Store parameters in a Cloud Storage bucket and read them at runtime.

Why wrong: Possible but not the direct approach for deployment-time configuration.

Edit the function code to hardcode the parameters.

Why wrong: Hardcoding is not flexible.

Include the parameters in the HTTP request body.

Why wrong: That would be runtime, not deployment time.

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

Why wrong: 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 wrong: 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.

Use psql command from a Compute Engine instance to connect and import the file.

Why wrong: Possible but not the recommended or direct method; the question asks for a command, and gcloud sql import sql is the proper way.

gcloud sql instances import my-instance gs://bucket/file.sql --database=db

Why wrong: Wrong command; the correct is gcloud sql import sql.

gcloud sql import csv my-instance gs://bucket/file.sql --database=db

Why wrong: --csv is for CSV files, not SQL dumps.

In Cloud Build history page.

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

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

Why wrong: 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 wrong: Monitoring is for metrics, not logs.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Incorrect. Uses `--network` instead of `--subnet`; the subnet must be specified with `--subnet`.

terraform { backend "storage" { bucket = "my-terraform-state" } }

Why wrong: Incorrect. 'storage' is not a valid Terraform backend type for GCS. The correct backend type is 'gcs'.

terraform { backend "gcloud" { bucket = "my-terraform-state" } }

Why wrong: Incorrect. 'gcloud' is not a valid Terraform backend type. The correct backend type is 'gcs'.

Increase the autoscaling cooldown period

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 'gcloud mb' is not a valid command; use 'gsutil mb'.

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

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

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: App Engine Standard Environment uses specific runtimes, not custom containers, and its scaling is not primarily based on CPU usage.

Cloud Run

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: Incorrect. US-CENTRAL1 is a single region, not a multi-region. The requirement is US multi-region.

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

Why wrong: Incorrect: gsutil acl ch is the legacy ACL method, not IAM, and AllUsers:R is not an IAM role.

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

Why wrong: Incorrect: gcloud storage buckets add-iam-policy-binding requires a bucket URL such as gs://my-bucket, not just the bucket name.

gsutil iam ch allUsers:storage.objectViewer gs://my-bucket

Why wrong: Incorrect: storage.objectViewer is not a valid IAM role alias; use objectViewer or roles/storage.objectViewer.

Set the autoscaling policy to use the target CPU utilization of 60

Why wrong: The `targetCPUUtilization` field in an autoscaling policy expects a decimal fraction between 0.0 and 1.0, not a percentage integer. Setting it to `60` would be invalid per the API schema, as it would be interpreted as 6000% if accepted at all. To represent 60% CPU utilization, the correct value is `0.6`, not `60`.

No autoscaling is needed; MIGs automatically scale based on load

Why wrong: Managed instance groups do not automatically scale based on load unless an autoscaling policy is explicitly defined and attached to the group. Without such a policy, the MIG simply maintains a fixed target size, only replacing unhealthy instances rather than adding or removing them based on demand. Therefore, stating that autoscaling is unnecessary because it happens automatically is incorrect.

Set the autoscaling policy to use the target HTTP load balancing utilization of 60%

Why wrong: The HTTP load balancing utilization signal is a different autoscaling metric that reflects usage of the backend service's capacity, such as `maxRatePerInstance` or `maxUtilization`, not the CPU utilization of the instances. It is only relevant when the MIG is behind a load balancer and you want to scale based on request load. The question specifically asks for CPU-based scaling, making this option incorrect, and the value would also need to be a decimal (e.g., `0.6`) rather than a percentage.