Answer
Pull the previous container's logs (the crashed instance, not the current restart) with kubectl logs -p deployment/ifsapp-iam -c ifsapp-iam -n <namespace>, and separately check kubectl get events -n <namespace> — the currently-running container's own logs are often too thin right after a fresh crash loop, while the previous instance's logs and the namespace's events frequently contain the actual failure detail that explains why IAM keeps crashing.