You are currently pushing container images to Artifact Registry and deploying a containerized microservices application to GKE. After deploying the application, you notice that the services do not…

Question

Options

• AConnect to the problematic Pod by running the kubectl exec -it POD_NAME - /bin/bash command
• BExecute the gcloud projects get-iam-policy PROJECT_ID command where the PROJECT_ID
• CRun the kubectl logs POD_NAME command where the POD_NAME parameter is the name of the
• DIn the Google Cloud console, navigate to Cloud Logging in the project of the cluster's VPC. Enter

• B
  6% (1)
• C
  94% (16)

Explanation

CrashLoopBackoff means the container starts, crashes, and Kubernetes keeps restarting it. The first diagnostic step is always to read the container's logs to understand why it is crashing. Option C (kubectl logs POD_NAME) retrieves the stdout/stderr output of the failed container, which typically reveals the error - such as a missing environment variable, failed database connection, or application exception. Option A (kubectl exec) requires a running container; exec is unavailable when the pod is in CrashLoopBackoff. Option B (gcloud projects get-iam-policy) checks IAM permissions, which is unrelated to a crashing container. Option D looks in the wrong Cloud Logging location (the VPC project rather than the cluster's project) and adds unnecessary complexity when kubectl logs is the direct, fast approach.

No community discussion yet for this question.