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.

In the launch template, you can only select one instance type. You can however override the Launch Template in the ASG configuration and specify multiple instance types.

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.

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.

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.

attribute-based instance types

Correct C.

its a B

" with the LEAST number of configuration changes in the future?" means we need to use attribute-based instance types. Otherwise as new instance types get created, and older ones get retired, we need to re-configure launch config again.