DOP-C02 Security and Compliance 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.

• ✗

  Patch the instance manually via SSH, then create a new AMI from it and update the launch configuration.

  Why it's wrong here

  Manually patching the instance over SSH and then creating a new AMI ignores the fact that the Auto Scaling group (ASG) launch configuration/template is the source of truth for instance fleet composition. Even if you update the launch configuration afterward, this approach does not define a repeatable, auditable patching pipeline; manual SSH patching is also error-prone and leaves no audit trail. Additionally, any instances already running will remain on the old AMI unless you explicitly terminate them, and the manual steps are not integrated with AWS Systems Manager or other automation for future patching cycles.

• ✗

  Detach the instance from the Auto Scaling group, patch it, and reattach it.

  Why it's wrong here

  Detaching the instance from the Auto Scaling group, patching it, and reattaching it only fixes that single running instance and does nothing to correct the root cause—the launch template still references a vulnerable AMI. New instances launched by the ASG will continue to use the old, unpatched AMI, so the vulnerability persists at the fleet level. Moreover, while a detached instance is outside the ASG, it is no longer protected by scaling policies and health checks; if the ASG had scaled, it might launch new instances from the vulnerable template, and the reattach process does not guarantee the instance passes ELB health checks or maintains the same configuration.

• ✗

  Use AWS Systems Manager Patch Manager to patch the instance and then set the instance to not receive future updates.

  Why it's wrong here

  Using AWS Systems Manager Patch Manager to patch the instance is a good operational practice, but setting the instance to not receive future updates is counterproductive for security and does not address the AMI used by the launch template. The patch is applied only to the currently running instance; the ASG launch template still points to an unpatched AMI, so any new instance launched for scaling or replace will be vulnerable. Furthermore, disabling future updates creates a security risk because the instance will miss critical patches, and the manual step to prevent updates must be applied to every instance, making it unscalable and inconsistent across a dynamic fleet.

• ✓

  Create a new AMI with the patch, update the Auto Scaling group's launch template, and terminate instances one by one to trigger replacement.

  Why this is correct

  This is the correct approach because it maintains a clean, versioned baseline: you create a new AMI that includes the patch, update the Auto Scaling group's launch template to reference that AMI, and then perform a rolling replacement of existing instances. Terminating instances one by one (or using instance refresh) ensures that the ASG launches new instances from the patched AMI, maintaining availability and minimizing disruption during the update. This aligns with infrastructure-as-code and immutable infrastructure practices, ensuring that all current and future instances are consistently patched and that the launch template is the single source of truth.

Go deeper

Related to this question