AWS Certified Solutions Architect Professional SAP-C02 Practice Question

An Amazon EC2 Auto Scaling group that uses a mixed-instances policy meets every stated need:

• Low-latency networking - Launching the ASG in a cluster placement group keeps instances in the same AZ rack segment, achieving the high-bandwidth, sub-millisecond latency required.
• Key isolation - Enabling Nitro Enclaves in the launch template creates an isolated execution environment that even root on the parent instance cannot access and that integrates natively with AWS KMS. Nitro Enclaves is supported on Intel, AMD, and Graviton instance families.
• Graviton adoption with x86 compatibility - A mixed-instances ASG can reference multiple launch templates (one Arm64 AMI for M6g, one x86_64 AMI for M6i) and use instance weights so that capacity can be satisfied by either architecture, allowing a gradual, risk-free migration.
• Horizontal scaling & rolling updates - Auto Scaling handles scale-out/scale-in based on metrics, and Instance Refresh (or rolling updates in CloudFormation) provides zero-downtime deployments with minimal management.

The other options fail at least one requirement:

• ECS Fargate cannot run Nitro Enclaves and cannot guarantee sub-millisecond latency between tasks, so it does not satisfy the key-isolation or latency needs.
• Dedicated Hosts with CloudHSM isolate keys but add significant cost and operational overhead, and this option fails to address the requirement for a phased migration to Graviton.
• Lambda-based rewrite removes control over intra-function network latency, is not an ideal architectural fit for this type of sustained compute workload, and offers no enclave-like isolation for the key-handling service.

Therefore, the mixed-instances EC2 Auto Scaling solution is the only one that covers every constraint with the lowest operational burden.