Google Cloud Professional Cloud Developer — Question 286

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 behave as expected. You use the kubectl get pods command to inspect the state of the application Pods, and discover that one of the Pods has a state of CrashLoopBackoff. How should you troubleshoot the Pod?

Answer options

• A. Connect to the problematic Pod by running the kubectl exec -it POD_NAME - /bin/bash command where the POD_NAME parameter is the name of the problematic Pod. Inspect the logs in the /var/log/messages folder to determine the root cause.
• B. Execute the gcloud projects get-iam-policy PROJECT_ID command where the PROJECT_ID parameter is the name of the project where your Artifact Registry resides. Inspect the IAM bindings of the node pool s service account. Validate if the service account has the roles/artifactregistry.reader role.
• C. Run the kubectl logs POD_NAME command where the POD_NAME parameter is the name of the problematic Pod. Analyze the logs of the Pod from previous runs to determine the root cause of failed start attempts of the Pod.
• D. In the Google Cloud console, navigate to Cloud Logging in the project of the cluster’s VPC. Enter a filter to show denied egress traffic to the Private Google Access CIDR range. Validate if egress traffic is denied from your GKE cluster to the Private Google Access CIDR range.

Correct answer: C

Explanation

The correct answer is C because reviewing the logs of the Pod allows you to understand the errors or issues causing the CrashLoopBackoff state. Option A is incorrect as accessing the Pod's shell may not provide relevant information about the crash. Option B is not applicable in this scenario, as IAM policies do not directly relate to why a Pod is crashing. Option D pertains to network traffic issues, which are not the primary concern when a Pod fails to start.