Question 31
Domain 5: Incident and Event ResponseA DevOps engineer successfully creates an Amazon Elastic Kubernetes Service (Amazon EKS) cluster that includes managed node groups. When the DevOps engineer tries to add node groups to the cluster, the cluster returns an error that states, "NodeCreationFailure: Instances failed to join the Kubernetes cluster." The DevOps engineer confirms that the EC2 worker nodes are running and that the EKS cluster is in an active state. How should the DevOps engineer troubleshoot this issue?
Correct answer: A
Explanation
EKS worker nodes must join the cluster through networking that does not conflict with the Kubernetes pod and service ranges. If the VPC subnets overlap with "172.17.0.0/16," node traffic can be misrouted and the instances may fail to register, producing "Instances failed to join the Kubernetes cluster."
Why each option is right or wrong
A. Ensure that the EKS cluster's VPC subnets do not overlap with the 172.17.0.0/16 CIDR range.
Amazon EKS requires the worker nodes to reach the cluster API endpoint and other cluster services without CIDR conflicts; AWS specifically warns that VPC subnets must not overlap the Kubernetes default Docker bridge range of 172.17.0.0/16. If the VPC uses that range, node networking can collide with container networking on the instances, preventing kubelet registration and producing the documented NodeCreationFailure: Instances failed to join the Kubernetes cluster.
B. Use kubectl to update the kubeconfig file to use the credentials that created the cluster.
kubeconfig affects kubectl client access, not whether worker nodes can bootstrap and join the cluster.
C. Run the AWSSupport-TroubleshootEKSWorkerNode runbook.
The runbook is a diagnostic aid, but the root cause here is the subnet CIDR overlap.
D. Create an AWS Identity and Access Management (IAM) OpenID Connect (OIDC) provider for the cluster.
An OIDC provider is generally for IAM roles for service accounts, not initial node registration.