The correct answer is A: Deploy Amazon EKS using a local cluster configuration on an AWS Outposts server installed in the on-premises data center for the production workloads.

Explanation

The question requires a solution where:

• Development/test environments use standard Amazon EKS (control plane in AWS cloud).
• Production workloads need both the EKS control plane and data plane (worker nodes) hosted on-premises.
• It must be an AWS-managed Kubernetes solution (AWS handles the control plane) with minimal operational overhead (avoid customer-managed control planes).

Why Option A?

• Amazon EKS on AWS Outposts supports two configurations:
  • Extended clusters: Control plane runs in the AWS Region (cloud); data plane (nodes) runs on Outposts (on-premises). This requires reliable connectivity to the Region and does not meet the "control plane on-premises" requirement.
  • Local clusters: Both the Kubernetes control plane and data plane run entirely on the Outposts hardware in the customer's data center. The control plane is still fully managed by AWS (running on EC2 instances provisioned on the Outpost), providing high availability, automated upgrades/patching for the control plane, and the same EKS APIs/tools as cloud EKS.
• This delivers AWS-managed Kubernetes with minimal operational overhead — AWS manages the control plane (no etcd, API server, or scheduler management for the customer), while the entire cluster runs locally for latency, compliance, or disconnection tolerance.
• Outposts uses AWS-designed hardware installed on-premises, which fits the "hosted on-premises" need perfectly. The company already has dev/test on cloud EKS, so this provides consistency with minimal new operational burden.

Why Not the Others?

• B: EKS Anywhere on company's hardware — This installs EKS Anywhere (based on EKS Distro) on the customer's own bare-metal or virtualized hardware. The entire cluster (including control plane) is customer-managed. AWS provides automation tooling and best practices, but you handle lifecycle, upgrades, patching, HA, and operations for the control plane. This increases operational overhead significantly compared to a fully AWS-managed control plane, so it does not best meet the "AWS-managed" + "minimal operational overhead" criteria.
• C: Extended cluster on Outposts — Control plane stays in the AWS Region (cloud), while only nodes are on-premises. This violates the explicit requirement that the control plane must be hosted on-premises.
• D: EKS Anywhere on Outposts — EKS Anywhere can technically run on Outposts hardware, but this still results in a customer-managed control plane (same drawbacks as B). It does not leverage the native AWS-managed local cluster capability of EKS on Outposts, leading to higher operational overhead. Outposts is better utilized with native EKS local clusters for management benefits.

Key Comparison Summary (for SAP Exam Context)

Local clusters on Outposts strike the ideal balance for production: full on-premises hosting + AWS-managed control plane + consistency with cloud EKS tooling (kubectl, IAM, observability, etc.).

This aligns with AWS best practices for regulated/low-latency workloads that need on-premises execution without taking on full Kubernetes control plane operations. For the exam, remember the distinction between local vs. extended clusters on Outposts, and how EKS Anywhere shifts more responsibility to the customer.