SAA-C03 Design High-Performing Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Leave the ASG attached to the previous Launch Template version so scale-out is stable.

  Why it's wrong here

  Pinning the ASG to the previous Launch Template version means any new instances spawned during scale-out events will launch without the updated configuration, creating a mixed fleet where some instances run the old settings and others run the new ones. ASG scale-out is meant to reflect the latest desired configuration, and stability should be achieved through controlled rollout mechanisms like instance refresh windows or CloudFormation update policies, not by freezing the template. Delaying the update also exposes the fleet to unresolved bugs or security fixes indefinitely.

• ✓

  Set the ASG to use the latest Launch Template version and optionally start an instance refresh for existing instances.

  Why this is correct

  ASG scale-out uses the configured Launch Template version at instance launch time. Switching the ASG to the latest version ensures new instances are consistent. An instance refresh helps apply changes to running instances safely and predictably.

• ✗

  Manually SSH into each new instance and reconfigure it after it launches.

  Why it's wrong here

  Manually SSHing into each new instance to reconfigure it after launch is inherently unscalable and violates the immutable-infrastructure principle. Auto Scaling groups can add many instances in rapid succession, so manual intervention introduces significant delays, risks missing instances, and causes configuration drift between identical roles. This approach also creates a dependency on human actions during scaling events, which is unreliable in production. The correct practice is to bake configuration into the Launch Template's user data or a custom AMI so instances are fully provisioned at boot.

  When this WOULD be correct

  In a scenario where a legacy system requires one-time manual configuration changes on a few instances (e.g., applying a hotfix that cannot be automated via AMI or user data), and the ASG is not expected to scale frequently, manual SSH could be acceptable for immediate remediation.

• ✗

  Move the configuration changes into a security group rule so the ASG updates them automatically.

  Why it's wrong here

  Security groups are stateful network firewalls that filter traffic based on IP, port, and protocol; they cannot carry or apply application configuration such as runtime parameters, environment variables, or package versions. Moving configuration changes into a security group rule would not cause the ASG or instances to update anything, and it misuses a network-layer control for a completely different purpose. Instance configuration on an ASG is managed exclusively through its Launch Template or Launch Configuration, which supply metadata and startup scripts to each new instance.

  When this WOULD be correct

  If the question asked how to automatically allow new instances to receive traffic from a specific source after scaling out, updating a security group rule would be correct, as security groups apply to all instances in the ASG automatically.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question