AWS Certified Solutions Architect Professional SAP-C02 Practice Question
A financial-services company is modernizing a monolithic on-premises application into a containerized, microservices architecture on AWS. The development team has standardized on Kubernetes and runs Prometheus for monitoring and Istio as the service mesh. The new platform must support two workload types:
A public-facing API that experiences unpredictable, spiky traffic.
Internal data-processing services that have steady, CPU-intensive workloads and can tolerate interruptions.
The small platform-engineering team wants to minimize control-plane operations. They also need host-level access on the data-processing nodes to install custom security hardening and wish to maximize cost savings with Amazon EC2 Spot Instances. Rapid, hands-off scaling is the primary concern for the public API.
Which container-hosting strategy best meets these requirements?
Deploy an Amazon ECS cluster that mixes AWS Fargate and EC2 capacity providers. Use Fargate for the public API and EC2 Spot Instances for the data-processing services.
Deploy an Amazon EKS cluster entirely on AWS Fargate. Create separate Fargate profiles for both workload types and use Fargate Spot for the data-processing services.
Deploy an Amazon EKS cluster. Use AWS Fargate profiles for the public-facing API Pods and a managed node group with EC2 Spot Instances for the data-processing services.
Deploy an Amazon EKS cluster that uses two managed node groups: On-Demand Instances for the public-facing API and EC2 Spot Instances for the data-processing services.
The best solution is to run a single Amazon EKS cluster with two managed node groups:
An On-Demand node group for the spiky, public-facing API.
A Spot node group for the interrupt-tolerant, CPU-intensive data-processing services.
Why this works
Kubernetes & Istio compatibility - All workloads run on EC2 nodes, so Istio sidecars that need the NET_ADMIN capability can function; Fargate cannot satisfy this.
Low operational overhead - EKS provides a managed control plane, and managed node groups automate OS patching, rolling updates, health monitoring, and integration with Cluster Autoscaler.
Granular host control - Because the data-processing Pods run on EC2, the team can apply custom OS-level security controls that are impossible with Fargate.
Cost optimization - Using a separate Spot node group allows the processing services to achieve significant savings while leaving the latency-sensitive API on reliable On-Demand capacity.
Why the other options are wrong
Mixing Fargate with EC2 (or using only Fargate) fails the Istio requirement and prevents host-level security hardening.
Choosing Amazon ECS ignores the explicit requirement to stay on Kubernetes.
Running everything on a single Spot-only group would risk API availability, while an On-Demand-only group would miss the cost-saving goal for batch workloads.
Ask Bash
Bash is our AI bot, trained to help you pass your exam. AI Generated Content may display inaccurate information, always double-check anything important.
Why is Kubernetes compatibility key for this architecture?
Open an interactive chat with Bash
What are managed node groups in Amazon EKS?
Open an interactive chat with Bash
How does Amazon EC2 Spot Instances help reduce costs?
Open an interactive chat with Bash
AWS Certified Solutions Architect Professional SAP-C02
Accelerate Workload Migration and Modernization
Your Score:
Report Issue
Bash, the Crucial Exams Chat Bot
AI Bot
Loading...
Loading...
Loading...
IT & Cybersecurity Package Join Premium for Full Access