A pod in your Amazon EKS cluster is stuck in the ImagePullBackOff state. You verified the image name and tag are 100% correct in your YAML file. What are the next three non-syntax things you check?
Quick Answer
Check whether the node's IAM role (or IRSA) actually has ecr:GetAuthorizationToken and ecr:BatchGetImage permissions on that specific ECR repository, because ImagePullBackOff after a syntax-correct image name is almost always an authentication or network-path failure, not a typo. Then check whether the node has outbound network access to reach the ECR and STS endpoints (NAT gateway health, security group egress, or VPC endpoint configuration), and finally check the imagePullSecrets if pulling from a private registry outside ECR, since a missing or expired secret produces the identical error.
Detailed Answer
Picture ordering a package online with the exact correct street address, but the delivery still fails. The address being right doesn't guarantee delivery — the courier might not have a key to the building, the road to the building might be closed, or the recipient might have changed the lock and never told the sender. ImagePullBackOff with a verified-correct image name is exactly this: the address is right, but something in the delivery chain is broken.
Kubernetes was designed so the kubelet on each node, not the control plane, is responsible for actually pulling container images — this keeps image pulls local to wherever the pod is scheduled and avoids funneling every pull through a central bottleneck. That design choice means image pull failures are a node-level and network-level problem, not something the API server can diagnose on its own, which is why the error surfaces as a generic ImagePullBackOff regardless of the underlying cause.
Internally, when a pod is scheduled, the kubelet calls the container runtime (containerd on modern EKS) to pull the image, which in turn needs three things to succeed: DNS resolution and network reachability to the registry endpoint, valid credentials scoped to that specific repository, and enough local disk space. For ECR specifically, authentication happens via a short-lived token obtained through STS, and the node's IAM role (or a pod's IRSA role if using enhanced pull-through setups) must be attached to a policy permitting ecr:GetAuthorizationToken account-wide and ecr:BatchGetImage/ecr:GetDownloadUrlForLayer scoped to that repository. If a security team recently tightened an ECR repository policy to restrict cross-account access, or if a node group's IAM role was swapped during a cluster upgrade without carrying over ECR permissions, the pull silently fails with the same generic message.
At production scale, teams debug this by exec-ing onto the node (or using a debug pod with hostNetwork) and manually running the equivalent aws ecr get-login-password and docker pull sequence, which surfaces the real underlying error — AccessDenied, a DNS timeout, or a TLS handshake failure — because kubectl describe pod only shows Kubernetes' summarized retry-backoff message, not the actual containerd error in most default configurations (though it often appears further down in Events if you look carefully). Engineers also check whether a NAT gateway is healthy for private subnets, since ECR endpoints are public by default unless VPC endpoints for ecr.api and ecr.dkr are configured, and a NAT gateway outage silently blocks every image pull cluster-wide, producing what looks like a per-pod scheduling problem but is actually infrastructure-wide.
The non-obvious gotcha: rate limiting. Docker Hub and even ECR can throttle pulls under high concurrency (for example, during a cluster-wide rolling restart that pulls the same large image on every node simultaneously), and the resulting throttling error also surfaces as ImagePullBackOff after several retries, making an intermittent capacity problem look identical to a permanent misconfiguration — the fix there is pull-through caching or a registry mirror, not touching IAM at all.