Exam AWS Certified DevOps Engineer - Professional DOP-C02 topic 1 question 24 discussion

Both Amazon CloudWatch's recover action and EC2 Auto Recovery are designed to respond to system status check failures, not instance status check failures. System status check failures indicate issues with the underlying hardware, while instance status check failures are often related to issues within your instance (like an OS-level issue). If the requirement is to handle unresponsiveness due to both system-level and instance-level issues, neither option A nor C would fully meet the requirement. In that case, AWS OpsWorks with auto healing (Option B) could be a better fit since OpsWorks allows you to configure more complex health checks and could recover from both system-level and instance-level issues. So, if you want to handle both types of unresponsiveness, Option B would be the most comprehensive solution.

OpsWorks has now been retired, so don't expect to see this question. However, the answer appears to be B. A: doesn't make sense because S3 notifications only happen if the S3 objects are modified. C: same argument as A D: impossible.

Every options are wrong at this moment. Opsworks reached EOL. Other options do not make any sense.

The best approach is C, using EC2 Auto Recovery to monitor and recover the instance if it becomes unresponsive, combined with S3 event notifications to ensure the application metadata is properly retrieved after the instance is back online.

B seem correct

Identical with Question #: 102

To automatic restart, must pull artifact for proactive

B: is correct: AWS opsworks auto healing will monitor the healthiness of EC2. If there is failure, restart EC2 and pull data from S3 to EC2 A: incorrect because no mention of method to trigger S3 and S3 will not trigger by itself C: incorrect because no mention of method to trigger S3 and S3 will not trigger by itself D: Cloud formation only for deploy, this task is about opswork

OpWorks is deprecated now , So will it be part of exam ? What is the point of learning of service that are not , going to use.

OpWorks is EOL now, however, I think this is the correct answer currenty.

A and C are wrong because S3 event notification destination is lambda, sqs and sns topic, you can't directly push metadata to EC2; D is wrong because although user data can retrieve s3 metadata, it can't restart automatically.

B. It doesn't make sense for an S3 event notification to be triggered by an EC2 instance being restarted. The OpsWorks autohealing capability can detect failed instances and replace them. After the auto-healed instance is back online, OpsWorks triggers a Configure lifecycle event on the instance. The metadata from S3 could be retrieved by the lifecycle event with a recipe. https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html https://docs.aws.amazon.com/opsworks/latest/userguide/workingcookbook-events.html https://github.com/awsdocs/aws-opsworks-user-guide/blob/master/doc_source/create-custom-configure.md

B, not simplest one but the only that meets requirements. For A - how can you push data from S3 to EC2? Data needs to be pulled from EC2.

A for me By creating a CloudWatch alarm for the StatusCheckFailed metric, the system can detect if the instance becomes unresponsive. The recover action can then be triggered to automatically stop and start the instance, ensuring it restarts or relaunches when necessary. Additionally, an S3 event notification can be set up to push the metadata to the instance once it is back up and running. This ensures that the application metadata is retrieved and available after the restart

B seems to be more feasible in this case.

https://aws.amazon.com/about-aws/whats-new/2022/03/amazon-ec2-default-automatic-recovery/

I'd say the answer is A ..you can configure Amazon CloudWatch to monitor the EC2 instance and trigger an automatic restart or relaunch if it becomes unresponsive. You can set up a CloudWatch alarm to monitor the instance's CPU utilization, network traffic, or other metrics, and define an action to take if the alarm is triggered, such as rebooting the instance or terminating and relaunching it.