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

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

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.

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.

A is correct: To deploy a new EKS cluster: 1. Need to have a VPC and at least 2 subnets 2. An IAM role that have permission to create and describe EKS cluster

A is good to go. B is not correct because they already setup connection to control plane.

In Amazon EKS, nodes need to communicate with the EKS control plane. When the Amazon EKS control plane endpoint access is set to private, you need to create interface VPC endpoints in the VPC where your nodes are running. This allows the nodes to access the control plane privately without needing public internet access.