A deployed microservice Pod is in CrashLoopBackOff. Which troubleshooting step gives the most direct information about why the Pod repeatedly fails to start?

When a Pod is in CrashLoopBackOff, it means the container inside the Pod is repeatedly starting and crashing. The most direct way to understand why it's crashing is to examine its logs. The kubectl logs PODNAME command, especially with the --previous flag (implied by "logs from previous runs"), retrieves logs from prior instances of the crashing container, which often contain error messages indicating the cause of the crash (e.g., application errors, misconfigurations, missing dependencies). Connecting with kubectl exec is not ideal because the container is crashing, making it difficult to execute commands inside. IAM policy checks are relevant for image pull issues, but less direct for application-level crashes. Checking VPC flow logs for denied egress traffic is for network connectivity problems, not typically the primary cause of a CrashLoopBackOff unless the application needs to reach an external service to start and is failing to do so, which would still likely manifest in the application logs.