Which solutions will fix the problem?
(Choose three.)
Switch the EKS nodes from Amazon EC2 to AWS Fargate.
Add an inbound rule to the EFS file system’s security group to allow NFS traffic from the EKS cluster.
Create an IAM role that allows the Amazon EFS CSI driver to interact with the file system
Set up AWS DataSync to configure file transfer between the EFS file system and the EKS nodes.
Create a mount target for the EFS file system in the subnet of the EKS nodes.
Disable encryption or the EFS file system.
Explanations:
Switching from Amazon EC2 to AWS Fargate will not resolve the mounting issue, as Fargate has its own limitations regarding persistent storage, and this scenario specifically involves EC2 instances.
Adding an inbound rule to the EFS file system’s security group to allow NFS traffic (TCP on port 2049) from the EKS cluster is essential, as it ensures that the EC2 instances can communicate with the EFS file system to mount it.
Creating an IAM role that allows the Amazon EFS CSI driver to interact with the file system is necessary because the CSI driver requires appropriate permissions to manage the EFS mounts on behalf of the application.
AWS DataSync is a service used for transferring data between storage systems; it is not relevant for mounting the EFS file system to EC2 instances in this context.
Creating a mount target for the EFS file system in the same subnet as the EKS nodes is crucial, as EFS requires mount targets in each availability zone where the instances reside to provide access.
Disabling encryption on the EFS file system is not a solution for mounting issues. If the application requires encrypted storage, it should be configured accordingly, as encryption does not affect the mounting capability.
It seems to me that the answer is:
Add an inbound rule to the EFS file system’s security group to allow NFS traffic from the EKS cluster.