Google ACE Practice Question: A developer needs to run an interactive shell…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  kubectl ssh api-pod-7d4f9 -n production

  Why it's wrong here

  kubectl ssh is not a real kubectl subcommand; the Kubernetes CLI has no built-in SSH functionality because Pods are not VMs and typically lack sshd. To get a shell in a container you must use `kubectl exec -it <pod> -n <namespace> -- <command>`, which uses the container runtime's exec API rather than a network SSH daemon. Even if `kubectl ssh` existed, it would not know how to negotiate container-level access, so this command would fail with an unknown command error.

• ✓

  kubectl exec -it api-pod-7d4f9 -n production -- /bin/bash

  Why this is correct

  This is the correct way to open an interactive shell inside the `api-pod-7d4f9` Pod. `-i` keeps STDIN open so you can type commands, `-t` allocates a pseudo-TTY for a proper terminal session, and `-n production` selects the namespace where the Pod lives. The `-- /bin/bash` specifies the command to run inside the first container of the Pod, and because most application images include bash, this gives you an interactive bash shell. If bash were not installed, you could substitute `/bin/sh` or another available shell.

• ✗

  kubectl run debug --image=busybox --attach=api-pod-7d4f9

  Why it's wrong here

  `kubectl run` is used to create a new workload resource (a Pod, Deployment, or Job) from an image — it does not attach to an existing Pod. The `--attach` flag on `kubectl run` only controls whether the CLI attaches to the newly created container's output, and it requires a command to run; it cannot target another Pod like `api-pod-7d4f9`. Therefore this command would create a separate busybox Pod (or Deployment) rather than giving you a shell inside the existing API Pod, which is not what you want for debugging that specific Pod.

• ✗

  gcloud container exec api-pod-7d4f9 --namespace=production -- bash

  Why it's wrong here

  `gcloud container exec` is not a valid command in the Google Cloud CLI; `gcloud container` manages GKE clusters (e.g., `gcloud container clusters list`, `gcloud container clusters get-credentials`), but it does not provide a direct way to execute commands inside a Pod. Pod-level access is always performed through `kubectl`, which talks to the Kubernetes API server after you have authenticated to the cluster. To achieve the same result, you would first run `gcloud container clusters get-credentials <cluster>` and then use `kubectl exec -it api-pod-7d4f9 -n production -- bash`.

Go deeper

Related to this question