AWS Certified Developer - Associate
Get started today
Ultimate access to all questions.
Ultimate access to all questions.
A multi-national company leverages AWS Cloud for its technology operations. As part of their infrastructure, they utilize a substantial number of EBS (Elastic Block Store) volumes and have both AWS Config and AWS CloudTrail activated for monitoring and compliance purposes. A manager attempted to identify the user who created a specific EBS volume by examining the CloudTrail event logs but was unsuccessful in doing so.
As a Developer Associate, what would you recommend as the appropriate solution in this scenario?
Explanation:
Overall explanation Correct option:
AWS CloudTrail event logs for 'CreateVolume' aren't available for EBS volumes created during an Amazon EC2 launch - AWS CloudTrail event logs for 'CreateVolume' aren't available for EBS volumes created during an Amazon Elastic Compute Cloud (Amazon EC2) launch.
Incorrect options:
AWS CloudTrail event logs for 'ManageVolume' aren't available for EBS volumes created during an Amazon EC2 launch - Event 'ManageVolume' is a made-up option and has been added as a distractor.
Amazon EBS CloudWatch metrics are disabled - Amazon Elastic Block Store (Amazon EBS) sends data points to CloudWatch for several metrics. Data is only reported to CloudWatch when the volume is attached to an instance. CloudWatch metrics are useful in tracking the status or life cycle changes of an EBS volume, they are not useful in knowing about the metadata of EBS volumes.
EBS volume status checks are disabled - Volume status checks enable you to better understand, track and manage potential inconsistencies in the data on an Amazon EBS volume. They are designed to provide you with the information that you need to determine whether your Amazon EBS volumes are impaired, and to help you control how a potentially inconsistent volume is handled. Our current use case requires us to pull data about EBS volume metadata, which is not possible with this feature.