Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 295 discussion

It's C. You change the instance type/size in the launch template not the ASG. ASG can change the min/max size, not instance type.

The answer used to be C, but now it's B. But not for the reasons others here have mentioned. The question states that "The Auto Scaling group configuration uses only one type of instance". This implies the ASG config has implemented instance overrides, which - you guessed it - overrides the instance type that's specified in the launch template. You could cut new versions of launch templates until you're blue in the face, it wont make a lick of difference if the ASG config is overriding the instance type. And because ASGs can be modified, I reckon that puts a nail in C's coffin, making B the new correct answer. I think this is the first question (out of 400+) where the moderator-selected solution was correct and the community-voted solution was incorrect.

With EC2 Attribute-based Instance Selection (ABIS), you can: Define desired vCPU, memory, and other instance characteristics (e.g., architecture, burstable/non-burstable). Let EC2 automatically choose instance types that match those attributes. Auto Scaling automatically selects the best available instance type, considering price and availability. This eliminates the need to manually maintain a list of instances — it adapts as AWS adds or removes instance types. ✅ Least configuration maintenance. ✅ Improves cost-efficiency. ✅ Improves resilience to Spot or On-Demand availability changes.

A out since “similar” still be under utilized. B reported information about utilization look sexy, B is feasible, but specify “an instance type” would not be flexible as C C using launch template, specify CPU and memory instead of instance type => AWS will select suitable instance type, this is for the "future" requirement D seems overkill

Why Option C is Less Optimal: Single Instance Type Limitation: By specifying CPU and memory requirements for a single instance type, you limit the flexibility of your Auto Scaling group. If the chosen instance type does not fully match the application's varying load, it may result in either underutilization or performance issues. No Cost Optimization: This option does not take advantage of cost differences among different instance types. Without multiple instance types, you miss out on opportunities to select more cost-effective options based on current pricing and utilization needs. Future Configuration Changes: While specifying the right instance type initially is good, it doesn't address changing application requirements or price fluctuations over time. It could still require adjustments in the future if the chosen instance type becomes less cost-effective or if application requirements change.

Perhaps it’s an older question that AWS intended for us to solve using C. But nowadays days its B for the reasons explained by some of the people in this thread. I would be really surprised to see this question in the exam, but if I will - I'll definitely go with B

Correct answer is A: This solution allows for a mix of instance types, which can help optimize costs and increase utilization. By using similar instance types, it ensures compatibility with the application's requirements. This approach requires the least number of configuration changes in the future as it provides flexibility to automatically use different instance types as they become available or as prices change. B. This option limits the Auto Scaling group to a single instance type again, which doesn't provide flexibility for future changes. C. Specifying CPU and memory requirements without instance types may lead to unexpected instance selections and potential compatibility issues. D. Using a script with the AWS Price List Bulk API could lead to frequent changes and may select instance types that aren't optimal for the application's needs.

C for me

I’ve tested it myself in the AWS Console – correct answer is “B”. To change the instance type you have 3 options, and all of them require modifying the ASG’s config: 1. Create a new revision of the current launch template, then change the ASG config to use it. 2. Create a new launch template, then change the ASG config to use it. 3. Use the option “Override launch template” in the ASG config. If you only create a new revision of the launch template, the ASG will continue to use the old revision. The state that you cannot change the instance type from the ASG config is NOT true and anybody can verify it in the AWS Console.

Option C

C: Auto scaling group is built on top of launch template, you can reference AMI in template, but not in auto scaling group

AWS does not allow to edit launch configuration. If you notice, we define instance type at time of launch configuration. So if you want to change instance type in Auto Scaling group than you need to create new launch configuration for that.

C is wrong. Let's assume a scenario where the optimal hardware requirement for a program under load is 4GB of RAM for every 1 CPU. However, you have specified only one type of instance with 1CPU and 1GB RAM. Even if you choose Option C and apply load balancing, having 4 instances of 1CPU and 1GB RAM (totaling 4CPU and 4GB RAM) will still result in an issue of low CPU utilization.

Key to the Answer is "Modify". Launch templates are immutable; after you create a launch template, you can't modify it. Instead, you can create a new version of the launch template that includes any changes you require. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/manage-launch-template-versions.html

b IS ANS Minimal configuration changes: This solution only requires modifying the Auto Scaling group configuration to add the new, more efficient instance type and remove the old, underutilized type. This minimizes future maintenance and reduces the risk of introducing errors. Scalability and flexibility: The Auto Scaling group will automatically scale up and down based on demand, even with the new instance type. This ensures high availability and cost-effectiveness. Future-proof: This approach doesn't rely on specific instance types or the AWS Price List Bulk API, making it more adaptable to future changes and updates in the AWS ecosystem.

we cannot change/modify launch config or launch template

It could be B or C, but "LEAST number of configuration changes in the future" makes it C.