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.

• ✓

  Create a new launch template with an updated AMI that includes the patch. Update the Auto Scaling group to use the new launch template and perform a rolling update.

  Why this is correct

  Creating a new launch template with a fully patched AMI and updating the Auto Scaling group to use it enables an instance refresh, which performs a rolling replacement of all current instances without downtime. This immutable infrastructure pattern guarantees that every launched instance is patched from the start, eliminating any configuration drift. An instance refresh gradually replaces instances while respecting the ASG's health check and minimum capacity, so application availability is maintained throughout the process.

• ✗

  Remove the instance from the Auto Scaling group, disable health checks on the ALB, and apply the patch manually.

  Why it's wrong here

  Removing the instance from the Auto Scaling group and disabling ALB health checks leaves the instance in service but removes the safety mechanism that would otherwise detect and route around failures. With health checks disabled, the ALB continues to send traffic to the vulnerable instance during the manual patch, and if the patch fails or requires a reboot, the instance may serve an unpatched workload. Manual patching on a running instance also risks an inconsistent state compared to the launch template, and the instance is no longer managed by the ASG's desired count, potentially causing scaling anomalies.

• ✗

  Use AWS Systems Manager Patch Manager to apply the patch on the instance without rebooting, then verify the vulnerability is resolved.

  Why it's wrong here

  Applying a security patch without rebooting is often ineffective because many Amazon Inspector findings, particularly kernel or shared-library CVEs, require a reboot to fully load the patched code and clear the vulnerable versions from memory. While Systems Manager Patch Manager can apply patches, omitting the reboot step means the operating system may still be running the vulnerable kernel or dynamic libraries, and Inspector would continue to flag the finding. Additionally, verifying the vulnerability immediately after a non-reboot patch may show it still present, and rebooting later without a controlled process could cause unexpected downtime in an ASG.

• ✗

  Stop the vulnerable instance, apply the patch, and start it again. Re-register it with the ALB.

  Why it's wrong here

  Stopping the vulnerable instance, applying the patch, and starting it again creates a period of unavailability for that instance, and if the ASG has a desired capacity of one, it results in full application downtime. Moreover, manually stopping an instance that is part of an Auto Scaling group can trigger the ASG to immediately launch a replacement instance to maintain desired capacity, leading to race conditions or duplicate compute costs. Re-registering with the ALB is redundant because the ASG manages registration, but the process still doesn't ensure the patched AMI is captured for future changes, and the instance may be replaced again on the next scale event.

Go deeper

Related to this question