DOP-C02 Incident and Event Response 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.

• ✓

  Use AWS Systems Manager Run Command to execute the script.

  Why this is correct

  AWS Systems Manager Run Command is the correct choice because it uses the SSM Agent already installed on the EC2 instance to execute a script as a one-shot, non-interactive command. It does not require SSH, opening port 22, or managing SSH keys, and it works across multiple instances concurrently with rate control and output logging. Run Command is purpose-built for exactly this ad-hoc script execution scenario, and it leverages the instance's IAM role for permissions, avoiding any need for bastion hosts or direct network access.

• ✗

  Use AWS OpsWorks to run the script as a Chef recipe.

  Why it's wrong here

  AWS OpsWorks is a configuration management service that uses Chef or Puppet to define and maintain the state of entire stacks over time, not to execute a one-off script on demand. Running a script as a Chef recipe would require creating a cookbook, uploading it to a custom or community cookbook repository, and then associating it with a layer and lifecycle event; you cannot simply tell OpsWorks 'run this script now' without SSH or a manual trigger. Even if you forced a recipe via a lifecycle event, OpsWorks would attempt to converge the whole instance against the cookbook state, making it a heavy, slow, and architecturally wrong tool for a single ad-hoc command. Therefore, OpsWorks is unsuitable for this scenario because it is not designed for quick, temporary script execution.

• ✗

  Use EC2 Instance Connect to SSH into the instance and run the script.

  Why it's wrong here

  EC2 Instance Connect requires you to provision SSH access to the instance, which means the security group must allow inbound SSH on port 22 and the instance must have an SSH key or Instance Connect's temporary key mechanism properly configured. This approach would then open an interactive SSH session, forcing you to manually type or paste the script, and it only works for a single instance at a time—it does not scale to fleet-wide execution without additional orchestration. Additionally, the question explicitly states that SSH is not directly available to the instance (the company uses Systems Manager for fleet management, implying no public SSH access), so EC2 Instance Connect would fail because the instance would be unreachable over SSH. Even if SSH were technically possible, this method violates the stated constraint of using Systems Manager and introduces unnecessary security risk by opening an administrative port.

• ✗

  Use AWS Systems Manager Session Manager to open a shell and run the script.

  Why it's wrong here

  AWS Systems Manager Session Manager is an interactive shell capability that streams a live, two-way session to an instance through the SSM Agent; it is not designed for one-shot, non-interactive script execution like Run Command. While Session Manager does not require SSH or a public IP, you would have to manually connect, await the shell prompt, paste the script, and then monitor for completion—a process that is error-prone and unsuitable for fleet-wide automation or scheduled execution. Session Manager also lacks the built-in features of Run Command such as rate limits, concurrency controls, output collection in S3 or CloudWatch, and the ability to target multiple instances via tags or resource groups. Because the requirement is to simply execute a script once, Run Command is the appropriate Systems Manager tool; Session Manager is meant for interactive troubleshooting, not a fire-and-forget script execution.

Go deeper

Related to this question