AWS Certified Solutions Architect Professional SAP-C02 Practice Question
Your organization is migrating several on-premises Kubernetes microservices to AWS. Each microservice team will receive its own AWS account. A central networking account already owns a VPC and an Amazon EFS file system that must remain in place. Security and platform teams have issued these requirements:
- Cluster capacity (patching, scaling, operating system updates) must incur the least possible manual effort.
- Pods must never use node instance credentials; each microservice must receive only the AWS permissions it needs.
- The existing Amazon EFS file system must be available to the microservices as persistent, POSIX-compatible shared storage.
- Network administrators must retain ownership of subnets and route tables, but application teams must be able to deploy workloads from their own accounts.
Which architecture best meets all of these requirements?
Implement a self-managed Kubernetes cluster on EC2 instances launched in a shared subnet of the networking account. Configure cross-account SSH access for each team, mount the EFS file system directly on the hosts, and use security groups on the nodes to isolate traffic.
Deploy an Amazon EKS cluster in every workload account with self-managed EC2 nodes, peer each cluster's VPC to the networking account, mount the EFS file system by exporting it over NFS, and store static AWS access keys in Kubernetes secrets for applications that call AWS services.
Provision a single Amazon EKS cluster in the networking account with managed EC2 node groups. Disable IAM roles for service accounts so that pods use the node instance profile, and attach the EFS file system by installing the NFS client on every node.
Create a centralized Amazon EKS cluster in the networking account. Configure an AWS Fargate profile for each microservice namespace, share the VPC subnets with workload accounts by using AWS Resource Access Manager, mount the existing Amazon EFS file system with the Amazon EFS CSI driver, and map every Kubernetes service account to its own IAM role by using IAM roles for service accounts.