Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 514 discussion

By creating interface VPC endpoints, you can enable the necessary communication between the Amazon EKS control plane and the nodes in private subnets. This solution ensures that the control plane maintains endpoint private access (set to true) and endpoint public access (set to false) for security compliance.

Check this : https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html Also, EKS does not require VPC endpoints. This is not the right use case for EKS

to me it looks like a network problem, not a "rights" problem.

B. "The company has received error notifications because the node cannot join the cluster" it's a network connectivity issue, not permissions.

Since the company has configured the Amazon EKS control plane with private access enabled (true) and public access disabled (false), the EKS API server is only accessible through private network routes. The worker nodes, which are in private subnets, must be able to communicate with the EKS control plane for proper functionality. When the nodes cannot join the cluster, the most common cause is that they are unable to reach the EKS API server. In this case, since the control plane is private-only, AWS recommends using interface VPC endpoints (AWS PrivateLink) to enable private communication between the nodes and the control plane.

IMO answer is A. In private cluster you need interface VPC endpoints to necessary connect to some AWS services (https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html) but EKS node always connect to control plane by EKS owned ENI. See this: it is very clear. https://keetmalin.medium.com/eks-cluster-network-architecture-for-worker-nodes-635e067c8c2a

The question is trying to tell us: 1. "private access = true" and "public access = false". So the control plane endpoint is private and only accessible from within the VPC. 2. Nodes (data plane) are in private subnets. Option A is NECESSARY but lack of permissions would generally cause authorization errors, not connectivity errors (that lead to failure of joining the cluster). Only after you got this right, you would likely receive errors about joining. So apparently we have already configured auth correctly, meaning A is not the answer. Option C exposes the nodes to the internet. Wrong. Option D is important for nodes to communicate with AWS services (because of allowing outbound traffic), but it’s not sufficient if the required VPC interface endpoints are not even there.

AmazonEKSNodeRole IAM role https://docs.aws.amazon.com/eks/latest/userguide/create-node-role.html

When Amazon EKS nodes cannot join the cluster, especially when the control plane is set to private access only, the issue typically revolves around networking and connectivity. When the EKS control plane is configured with private access only, the nodes must communicate with the control plane over private IP addresses. Creating VPC endpoints (specifically, com.amazonaws.<region>.eks) allows traffic between the EKS nodes and the control plane to be routed privately within the VPC, which resolves the connectivity issue.

I think is B.

Error they have mentioned is at network level. They are not saying authorisation is failed rather noce is enable to connect to cluster aka connectivity issue. So answer it must be B

https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html "Any self-managed nodes must be deployed to subnets that have the VPC interface endpoints that you require. If you create a managed node group, the VPC interface endpoint security group must allow the CIDR for the subnets, or you must add the created node security group to the VPC interface endpoint security group."

I Think is A

B is good to go

S3/DynamoDB - VPC endpoint, other service should use interface endpoint so B is incorrect

Because of these two assertions: - Amazon EKS control plane with endpoint private access set to true and endpoint public access set to false to maintain security compliance. ( The company must also put the data plane in private subnets. The best answer is related to Networking, Private Subnets (EKS Ctr Plane is strictly private and Data Plane stick under private subnets) and not related to EKS autodeployment that sure need an IAM policy. So according to me, answer B is the best answer.

Before can launch nodes and register nodes into a EKS cluster, must create an IAM role for those nodes to use when they are launched.