All practice questions

976 questions

All types976 Multiple choice502 Multiple select450 Ordering24

A company's regional API Gateway REST API is protected by an AWS WAF Web ACL. During a security audit, the SysOps administrator identifies a brute-force attempt targeting the `/checkout` endpoint. To mitigate this threat, the administrator must restrict each client IP address to a maximum of $100$ requests per $5$ minutes on the `/checkout` path only. Traffic to other endpoints must not be affected.

Which configuration should the SysOps administrator implement to meet these requirements?

Deploy stateless Network Access Control List (NACL) rules on the VPC subnets to limit traffic to

100

requests per

5

minutes, ensuring outbound rules restrict traffic to only HTTPS port

443

Create an AWS WAF Web ACL rule with a rate-based statement set to a limit of

100

, and configure a scope-down statement that matches the URI path `/checkout`.

Configure an Amazon CloudWatch metric filter for the `/checkout` path that triggers an AWS Config remediation rule, which directly executes an Amazon EventBridge rule to update the API Gateway resource policy.

Modify the API Gateway backend Application Load Balancer target group health check configuration, changing the health check path to `/checkout` and adjusting the threshold to mark targets unhealthy when requests exceed

100

per

5

minutes.

Show answer & explanation

Answer: Create an AWS WAF Web ACL rule with a rate-based statement set to a limit of $100$ , and configure a scope-down statement that matches the URI path `/checkout`.

Answer

Create an AWS WAF Web ACL rule with a rate-based statement set to a limit of

100

, and configure a scope-down statement that matches the URI path `/checkout`.

The correct option correctly uses an AWS WAF rate-based rule with a scope-down statement matching the `/checkout` URI. AWS WAF evaluates the request rate per client IP address over a sliding

5

-minute window and blocks traffic exceeding

100

requests on that path, satisfying the requirements without affecting other endpoints.

Step-by-Step Solution

Select the AWS WAF Web ACL associated with the regional API Gateway.

The Web ACL configuration page is opened.

Threat protection rules must be configured directly within the Web ACL protecting the target API Gateway.

Add a new rule with a rate-based statement set to a threshold of

100

requests.

The rule is set up to count requests per client IP address over a sliding

5

-minute window.

This establishes the client-based rate limiting required to mitigate brute-force attempts.

Configure a scope-down statement within the rate-based rule to evaluate only requests where the URI path matches `/checkout`.

Only requests targeting the `/checkout` path will count towards the rate limit.

This ensures that traffic to other API paths remains unaffected by the rate-based rule.

Key Concept

AWS WAF rate-based rules evaluate the rate of requests from client IP addresses. To apply rate limiting to a subset of requests, a scope-down statement restricts evaluation to matching criteria, such as a specific URI path.

Estimated Time:1m 30s

Question 102Question →

An organization runs a web application on four Amazon EC2 instances, each configured with an Elastic IP address. A SysOps Administrator must configure Amazon Route 53 to distribute client requests randomly across all four instances. The configuration must perform health checks on each instance individually and automatically stop routing traffic to any instance that becomes unhealthy. Which Route 53 configuration will meet these requirements?

Create a single A record using the Simple routing policy that contains all four Elastic IP addresses, and enable health checking on the record.

Create four A records using the Multivalue Answer routing policy, and associate a Route 53 health check with each record.

Create a CNAME record at the zone apex pointing to a Route 53 traffic policy that distributes traffic across the four Elastic IP addresses.

Create four Alias records pointing to the Elastic IP addresses using the Failover routing policy, and associate health checks.

Show answer & explanation

Answer: Create four A records using the Multivalue Answer routing policy, and associate a Route 53 health check with each record.

Answer

Create four A records using the Multivalue Answer routing policy, and associate a Route 53 health check with each record.

The correct option is to create four A records using the Multivalue Answer routing policy and associate a Route 53 health check with each record. This configuration returns multiple healthy values (up to eight) in response to DNS queries, allows Route 53 to check the health of each resource individually, and automatically excludes unhealthy resources from DNS responses. It also allows direct access to each IP address for individual health checking.

Step-by-Step Solution

Determine the resource type and record type requirements.

Since the targets are individual EC2 Elastic IP addresses, standard A records must be used (not Alias records, which require AWS resources like load balancers).

Alias records do not support target IP addresses directly.

Select a routing policy that supports individual health checks for multiple distinct records.

Choose Multivalue Answer routing rather than Simple routing.

Multivalue Answer routing allows associating a health check with each individual A record, whereas Simple routing applies health checks to the record as a whole and cannot selectively remove individual IPs.

Associate a health check with each of the four A records.

Configure Route 53 health checks to monitor each EC2 instance's IP address.

When a health check fails, Route 53 stops returning the corresponding IP address in DNS query responses.

Key Concept

Amazon Route 53 Multivalue Answer routing policy with health checks for active-active DNS load balancing and failover.

Question 103Question →

A company hosts an application on Amazon EC2 instances in a private subnet. The instances must access files in an Amazon S3 bucket within the same AWS Region without traversing the public internet. A SysOps administrator creates an Amazon S3 gateway VPC endpoint to enable this private connection. However, the instances are still unable to communicate with the S3 bucket. Which two configuration steps must the SysOps administrator take to resolve this connectivity issue? (Select TWO.)

Select all that apply

Add a route to the private subnet's route table that targets the gateway VPC endpoint for the Amazon S3 prefix list destination.

Configure the security group of the EC2 instances to allow outbound HTTPS traffic targeting the prefix list of the Amazon S3 gateway endpoint.

Enable private DNS hostnames and DNS resolution options within the VPC settings.

Add a route in the private subnet's route table with a destination of

0.0.0.0/0

targeting the Internet Gateway (IGW).

Configure the private subnet's network ACL to allow outbound HTTPS (

443

) traffic to the Amazon S3 prefix list without adding an inbound rule for ephemeral ports (

1024-65535

Show answer & explanation

Answer: Add a route to the private subnet's route table that targets the gateway VPC endpoint for the Amazon S3 prefix list destination.; Configure the security group of the EC2 instances to allow outbound HTTPS traffic targeting the prefix list of the Amazon S3 gateway endpoint.

Answer

To establish private connectivity to Amazon S3 using a gateway VPC endpoint, you must add a route targeting the VPC endpoint in the private subnet's route table and ensure that the EC2 instances' security group allows outbound HTTPS traffic to the S3 prefix list.

The correct options involve adding a route to the private subnet's route table that targets the gateway VPC endpoint for the S3 prefix list, and configuring the EC2 security group to allow outbound HTTPS traffic to the S3 prefix list. The gateway endpoint relies on the route table association to direct traffic, and stateful security groups must permit outbound traffic to the destination.

Step-by-Step Solution

Associate the S3 gateway endpoint with the private subnet's route table.

A route is added to the route table with the S3 prefix list as the destination and the VPC endpoint ID as the target.

This tells the VPC router to direct any S3-bound traffic from the private subnet to the gateway endpoint instead of the default route.

Update the EC2 instances' security group rules.

An outbound rule is added to allow HTTPS traffic to the S3 prefix list.

Security groups must allow outbound traffic to S3. Using the prefix list minimizes security risk by restricting outbound HTTPS traffic only to AWS-owned S3 IP ranges.

Key Concept

Gateway VPC Endpoint Routing and Security Group Configuration

Estimated Time:2m 0s

Question 104Question →

A SysOps Administrator configures a CloudWatch alarm to monitor the CPUUtilization metric of an Amazon EC2 instance. The alarm is set to trigger if the CPU utilization exceeds $80\%$ for a period of 1 minute. However, the administrator notices that the alarm frequently enters the INSUFFICIENT_DATA state because the instance is using standard monitoring, which only sends metric data to CloudWatch every 5 minutes. Which of the following actions will resolve this issue by ensuring the instance reports CPU metrics every minute?

Enable detailed monitoring for the EC2 instance.

Configure the alarm with a period of 10 seconds to force CloudWatch to collect the metric more frequently.

Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation document to poll the CPU metric every minute.

Reduce the Auto Scaling group cooldown period to 60 seconds to force the instance to update its metrics more frequently.

Show answer & explanation

Answer: Enable detailed monitoring for the EC2 instance.

Answer

Enable detailed monitoring for the EC2 instance.

Enabling detailed monitoring for the EC2 instance changes the metric reporting frequency from the default 5-minute interval to a 1-minute interval. This allows the CloudWatch alarm with a 1-minute period to receive data points consistently and function as designed.

Step-by-Step Solution

Identify the cause of the INSUFFICIENT_DATA state.

The EC2 instance is configured with standard monitoring, which sends metrics to CloudWatch at 5-minute intervals, causing a mismatch with the 1-minute alarm evaluation period.

CloudWatch alarms require at least one data point within the evaluation period to assess the metric state; otherwise, they default to INSUFFICIENT_DATA.

Select the mechanism to increase EC2 metric resolution.

Detailed monitoring must be enabled on the EC2 instance to send metrics at 1-minute intervals.

Detailed monitoring is the native AWS feature designed to increase the frequency of EC2 metrics from 5 minutes to 1 minute.

Key Concept

CloudWatch Standard vs. Detailed Monitoring for EC2

Question 105Question →

A SysOps Administrator is configuring an Amazon CloudWatch metric alarm to monitor the average CPU utilization of an Amazon EC2 Auto Scaling group. The alarm is configured with a period of 60 seconds (1 minute) and an evaluation period of 2. The instances in the Auto Scaling group currently have standard monitoring enabled. The administrator observes that the alarm state frequently fluctuates to INSUFFICIENT_DATA and fails to trigger the configured scaling policies when CPU utilization spikes. What is the correct action to resolve this issue?

Enable detailed monitoring on the EC2 instances in the Auto Scaling group launch template to ensure CPU utilization metrics are published to CloudWatch at 1-minute intervals.

Change the metric statistic from Average to SampleCount so that CloudWatch can aggregate the standard 5-minute metrics into 1-minute intervals.

Configure an Amazon EventBridge rule to capture EC2 CPU metric events and route them directly to the CloudWatch alarm target.

Reduce the Auto Scaling group's cooldown period to less than 60 seconds to allow the metric data to bypass the scaling lock and update the alarm.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instances in the Auto Scaling group launch template to ensure CPU utilization metrics are published to CloudWatch at 1-minute intervals.

Answer

Enable detailed monitoring on the EC2 instances in the Auto Scaling group launch template to ensure CPU utilization metrics are published to CloudWatch at 1-minute intervals.

The correct action is to enable detailed monitoring because standard monitoring only reports EC2 metrics at 5-minute intervals. By default, a CloudWatch alarm with a 1-minute evaluation period will suffer from missing data and enter the INSUFFICIENT_DATA state. Enabling detailed monitoring increases the metric frequency to 1-minute intervals, providing the necessary data points for the alarm to function correctly.

Step-by-Step Solution

Identify the cause of the INSUFFICIENT_DATA state.

The alarm is configured with a 1-minute period and requires 2 consecutive periods. However, standard monitoring only publishes metrics every 5 minutes, resulting in periods without any data points.

CloudWatch needs metric data points for each evaluation period to determine if the threshold has been crossed.

Select the appropriate resolution to increase metric frequency.

Enabling detailed monitoring on the EC2 instances ensures that CPU metrics are sent every 1 minute instead of every 5 minutes.

This guarantees that CloudWatch receives at least one data point per 1-minute period, allowing the alarm to evaluate properly.

Key Concept

CloudWatch Alarms require metric reporting intervals that align with or are more frequent than the alarm's evaluation period to avoid transitioning into the INSUFFICIENT_DATA state.

Estimated Time:1m 30s

Question 106Question →

An operations team is running a containerized transaction service on Amazon ECS. To monitor transaction processing delays, they publish a custom metric named ProcessingLatency to Amazon CloudWatch. They set up a CloudWatch alarm with an evaluation period of 10 seconds to alert them of latency spikes. However, they observe that the alarm remains in an INSUFFICIENT_DATA state during periods of low transaction volume, and even under normal load, it fails to trigger reliably. Which of the following explains why this alarm is failing to function as expected?

Detailed monitoring has not been enabled for the underlying ECS container instances, which limits all custom metric dimensions to a default 5-minute reporting interval.

The custom metric is being published with standard storage resolution (1-minute interval), but the alarm is configured with an evaluation period of 10 seconds.

The custom metric is not associated with an Amazon EventBridge rule that is required to route sub-minute metric data points directly to CloudWatch Alarms.

The ECS service's auto-scaling cooldown period is set to a value shorter than 10 seconds, which causes CloudWatch to suppress metric data points during evaluation.

Show answer & explanation

Answer: The custom metric is being published with standard storage resolution (1-minute interval), but the alarm is configured with an evaluation period of 10 seconds.

Answer

The custom metric is being published with standard storage resolution (1-minute interval), but the alarm is configured with an evaluation period of 10 seconds.

The option specifying that the custom metric is published with standard storage resolution while the alarm is configured with a 10-second period is correct. By default, custom metrics are stored in CloudWatch with a standard resolution of 1 minute. If you configure a CloudWatch alarm with a high-resolution period (such as 10 seconds or 30 seconds), the alarm will look for data points in those small windows. Because standard resolution metrics only receive data points once every 60 seconds, the alarm will frequently have no data to evaluate, leading to an INSUFFICIENT_DATA state. To resolve this, the metric must be published with high-resolution storage (using the StorageResolution parameter set to 1 in the API call) or the alarm period must be adjusted to 60 seconds or longer.

Step-by-Step Solution

Analyze the custom metric publishing frequency.

By default, custom metrics sent to CloudWatch have a standard storage resolution of 1 minute.

To identify if the metric frequency is sufficient to support sub-minute alarm evaluation.

Compare the metric frequency with the alarm evaluation period.

The alarm is configured with a 10-second period, which requires high-resolution data points (1-second resolution) to avoid missing data.

An alarm period of less than 60 seconds requires high-resolution metrics to ensure data is present in each evaluation window.

Determine why the alarm remains in the INSUFFICIENT_DATA state.

Since the metric is standard resolution (1-minute), most 10-second evaluation intervals contain zero data points, leading to the INSUFFICIENT_DATA status.

Without high-resolution storage enabled for the custom metric, sub-minute alarms cannot function correctly.

Key Concept

CloudWatch Custom Metric Storage Resolution and Alarm Periods

Question 107Question →

A SysOps Administrator is setting up monitoring and automated remediation for a standalone Amazon EC2 instance. The administrator needs to configure a CloudWatch alarm to detect CPU utilization spikes and automatically reboot the instance if CPU utilization exceeds 90% for three consecutive 1-minute periods. Which TWO of the following configuration steps are required to achieve this goal?

Select all that apply

Enable detailed monitoring on the EC2 instance to allow CloudWatch to receive metric data at 1-minute intervals.

Configure the CloudWatch alarm to trigger an EC2 Action that reboots the instance when the alarm state is reached.

Keep standard monitoring enabled on the EC2 instance since default EC2 metrics are sent to CloudWatch every 1 minute.

Create an Amazon EventBridge rule that directly monitors the EC2 instance's OS logs to trigger a reboot.

Configure an Auto Scaling lifecycle hook with a 300-second cooldown period to reboot the instance.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instance to allow CloudWatch to receive metric data at 1-minute intervals.; Configure the CloudWatch alarm to trigger an EC2 Action that reboots the instance when the alarm state is reached.

Answer

To achieve the goal, enable detailed monitoring on the EC2 instance and configure the CloudWatch alarm to trigger an EC2 Action that reboots the instance.

Detailed monitoring must be enabled to monitor EC2 metrics at 1-minute intervals. The CloudWatch alarm can then be configured to execute an EC2 Action to reboot the instance automatically when the alarm is triggered.

Step-by-Step Solution

Determine metric granularity requirements.

Standard monitoring provides 5-minute intervals, which cannot satisfy the 1-minute evaluation period. Detailed monitoring must be enabled to get 1-minute metric intervals.

The alarm is configured to evaluate CPU utilization over three consecutive 1-minute periods.

Configure the automated remediation action.

Create a CloudWatch alarm action using the native EC2 Actions to reboot the instance.

CloudWatch alarms can execute native EC2 actions directly without additional event routers or functions.

Key Concept

CloudWatch Detailed Monitoring and Alarm Actions

Question 108Question →

A SysOps Administrator is designing an automated remediation workflow for a critical microservice running on Amazon EC2 instances. The microservice publishes a custom metric named QueueBacklog to Amazon CloudWatch every minute. The administrator needs to configure a CloudWatch metric alarm that triggers an AWS Systems Manager (SSM) Automation document to remediate the backlog when the metric exceeds 500 for three consecutive evaluation periods.

Which two configurations must the administrator perform to meet these requirements? (Select TWO.)

Select all that apply

Configure the CloudWatch metric alarm with a Period of 60 seconds and set the Evaluation Periods to 3.

Create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, and set the rule target to the Systems Manager Automation document.

Enable detailed monitoring on the EC2 instances to allow custom metrics to be collected and processed at 1-minute intervals.

Configure the CloudWatch metric alarm action to publish directly to an Amazon Simple Queue Service (Amazon SQS) queue configured as the event source for the Systems Manager Automation document.

Configure the CloudWatch metric alarm with a Period of 300 seconds to align with the default standard monitoring interval of custom metrics.

Show answer & explanation

Answer: Configure the CloudWatch metric alarm with a Period of 60 seconds and set the Evaluation Periods to 3.; Create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, and set the rule target to the Systems Manager Automation document.

Answer

Configure the CloudWatch metric alarm with a Period of 60 seconds and set the Evaluation Periods to 3, and create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, setting the rule target to the Systems Manager Automation document.

To evaluate a custom metric at 1-minute intervals for three consecutive periods, the CloudWatch alarm must be configured with a period of 60 seconds and an evaluation period of 3. Furthermore, CloudWatch alarms cannot directly initiate Systems Manager Automation documents as an alarm action. To achieve this, an Amazon EventBridge rule must be created to detect the alarm's state change to ALARM and target the Systems Manager Automation document.

Step-by-Step Solution

Set the alarm evaluation period and granularity.

The CloudWatch alarm is configured with a period of 60 seconds (1 minute) and evaluation periods set to 3.

This matches the 1-minute reporting interval of the custom metric and ensures the alarm triggers only after three consecutive 1-minute periods of exceeding the threshold.

Configure the remediation integration path.

An Amazon EventBridge rule is created to match CloudWatch alarm state change events.

Since CloudWatch alarms cannot natively target Systems Manager Automation documents directly as an action, EventBridge must be used to intercept the state change and route the event to the automation target.

Key Concept

CloudWatch Metric Alarms can monitor custom metrics at specific granularities (periods) and require Amazon EventBridge to trigger AWS Systems Manager Automation for automated remediation.

Question 109Question →

A SysOps Administrator is setting up an automated remediation workflow to stop an Amazon EC2 instance when its CPU utilization exceeds 90%. The administrator needs the instance's CPU metric to be evaluated at 1-minute intervals to ensure rapid response, and wants to execute a custom Systems Manager Automation runbook as the remediation action. Which configuration will meet these requirements?

Keep standard monitoring enabled on the EC2 instance. Configure the CloudWatch alarm with a 1-minute period and set the alarm to trigger an Amazon EventBridge rule that executes the Systems Manager Automation runbook.

Enable detailed monitoring on the EC2 instance. Configure the CloudWatch alarm with a 1-minute period and set the alarm to trigger an Amazon EventBridge rule that executes the Systems Manager Automation runbook.

Enable detailed monitoring on the EC2 instance. Configure the CloudWatch alarm to deliver the state change event directly to an Amazon Simple Storage Service (Amazon S3) bucket to initiate the Systems Manager Automation runbook.

Keep standard monitoring enabled on the EC2 instance. Configure the CloudWatch alarm to publish to an Amazon Simple Queue Service (Amazon SQS) queue that directly triggers the Systems Manager Automation runbook.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instance. Configure the CloudWatch alarm with a 1-minute period and set the alarm to trigger an Amazon EventBridge rule that executes the Systems Manager Automation runbook.

Answer

Enable detailed monitoring on the EC2 instance, configure the CloudWatch alarm with a 1-minute period, and set the alarm to trigger an Amazon EventBridge rule that executes the Systems Manager Automation runbook.

To evaluate a metric at 1-minute intervals, detailed monitoring must be enabled on the EC2 instance. Once enabled, the CPU utilization metric is delivered to CloudWatch every minute. The CloudWatch alarm can then be configured with a 1-minute period. To trigger the automated remediation runbook, EventBridge should be used as it natively receives CloudWatch alarm state change events and can target Systems Manager Automation runbooks.

Step-by-Step Solution

Determine the necessary metric reporting frequency for a 1-minute alarm evaluation period.

Detailed monitoring must be enabled on the EC2 instance.

By default, standard monitoring for EC2 instances only sends metrics every 5 minutes. To monitor and alarm at 1-minute intervals, detailed monitoring must be enabled to report at 1-minute granularity.

Identify the correct destination path to execute a Systems Manager Automation runbook when the alarm changes state.

Configure a CloudWatch alarm to send state changes to EventBridge, which targets the Systems Manager Automation runbook.

CloudWatch alarms cannot invoke Systems Manager Automation runbooks directly. Instead, the alarm state change event is intercepted by Amazon EventBridge, which is configured with a rule to target the SSM Automation runbook.

Key Concept

CloudWatch Detailed Monitoring intervals and automated remediation routing via EventBridge

Question 110Question →

A SysOps Administrator is troubleshooting a monitoring setup for a critical transactional API. A custom monitoring daemon on each Amazon EC2 instance in an Auto Scaling group publishes a custom metric named `TransactionLatency` to Amazon CloudWatch every 10 seconds. The metric is published with three dimensions: `InstanceId`, `AutoScalingGroupName`, and `Stage`. To detect latency spikes across the fleet, the administrator creates a CloudWatch metric alarm with a 10-second period, evaluating 3 datapoints, and utilizing the dimension `AutoScalingGroupName = production-asg`. However, the alarm constantly remains in the `INSUFFICIENT_DATA` state, even during peak periods when latency is high. What is the root cause of this issue?

CloudWatch does not automatically aggregate custom metrics across dimensions. Since the metric is published with multiple dimensions including InstanceId, querying it using only the AutoScalingGroupName dimension returns no data.

Detailed monitoring is not enabled for the EC2 instances in the Auto Scaling group, which restricts CloudWatch from evaluating metric alarms with a period of less than 5 minutes.

The CloudWatch alarm is attempting to invoke a scaling policy directly, but high-resolution sub-minute alarms must route through Amazon EventBridge to execute Systems Manager Automation actions.

The Auto Scaling group's cooldown period is set to 300 seconds, which overrides the alarm evaluation frequency and suppresses metrics to prevent scaling thrashing.

Show answer & explanation

Answer: CloudWatch does not automatically aggregate custom metrics across dimensions. Since the metric is published with multiple dimensions including InstanceId, querying it using only the AutoScalingGroupName dimension returns no data.

Answer

CloudWatch custom metrics are uniquely identified by their complete set of dimensions. If a metric is published with multiple dimensions (such as InstanceId, AutoScalingGroupName, and Stage), querying or creating an alarm using only a subset of those dimensions (like AutoScalingGroupName) will fail to retrieve the data. CloudWatch does not perform automatic aggregation across dimensions for custom metrics. To alarm on the aggregate value, the metrics must be published with the desired target dimensions, or aggregated using CloudWatch Metric Math.

Step-by-Step Solution

Analyze how CloudWatch identifies metrics using dimensions.

CloudWatch uniquely identifies a metric by its namespace, metric name, and all of its defined dimensions.

To retrieve or alarm on a metric, the query must specify the exact dimension combination that was used when publishing the metric.

Evaluate why querying with a subset of dimensions fails.

Querying with only the AutoScalingGroupName dimension returns no data because CloudWatch does not automatically aggregate metrics across dimensions (e.g., aggregating away the InstanceId or Stage dimension).

Without exact dimension matching, CloudWatch treats the request as a query for a metric that does not exist, causing the alarm to remain in the INSUFFICIENT_DATA state.

Address the mitigation strategies.

The administrator can either publish the metric twice (once with all dimensions for granular tracking, and once without the InstanceId dimension for fleet aggregation), or use CloudWatch Metric Math with the SEARCH function to aggregate the dimensions dynamically.

This allows the alarm to query a valid, populated metric path representing the aggregate data of the Auto Scaling group.

Key Concept

Metric Dimensions and Custom Metric Aggregation in CloudWatch

Estimated Time:3m 0s

Question 111Question →

A SysOps Administrator is tasked with setting up automated remediation for a critical application running on a fleet of Amazon EC2 instances. The administrator configures an Amazon CloudWatch alarm on the `CPUUtilization` metric to trigger when the CPU usage exceeds $80\%$ for $3$ consecutive periods of $1$ minute. The remediation workflow must trigger an AWS Systems Manager (SSM) Automation runbook to collect application logs and reboot the instances. Currently, standard monitoring is enabled on the EC2 instances. During testing, the alarm remains in the `INSUFFICIENT_DATA` state even when CPU utilization is verified to be at $95\%$ for over $10$ minutes, and the remediation workflow fails to run.

Which combination of actions will resolve this issue and enable the automated remediation workflow to run successfully?

Enable detailed monitoring on the EC2 instances. Configure the CloudWatch alarm action to directly invoke the Systems Manager Automation runbook.

Enable detailed monitoring on the EC2 instances. Configure an Amazon EventBridge rule that detects the CloudWatch alarm state change and targets the Systems Manager Automation runbook.

Keep standard monitoring enabled on the EC2 instances. Configure an Amazon EventBridge rule that detects the CloudWatch alarm state change and targets the Systems Manager Automation runbook.

Enable detailed monitoring on the EC2 instances. Configure the CloudWatch alarm to send a notification to an Amazon Simple Notification Service (Amazon SNS) topic, and configure the SNS topic to directly target the Systems Manager Automation runbook.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instances. Configure an Amazon EventBridge rule that detects the CloudWatch alarm state change and targets the Systems Manager Automation runbook.

Answer

Enable detailed monitoring on the EC2 instances, and configure an Amazon EventBridge rule that detects the CloudWatch alarm state change to target the Systems Manager Automation runbook.

The correct solution requires enabling detailed monitoring on the EC2 instances to publish metric data at

1

-minute intervals, resolving the `INSUFFICIENT_DATA` status. Additionally, an Amazon EventBridge rule must be configured to catch the alarm state transition and trigger the Systems Manager Automation runbook, since CloudWatch alarms cannot invoke Systems Manager Automation directly.

Step-by-Step Solution

Analyze the metric reporting interval requirement.

Standard monitoring publishes CPU utilization metrics every

5

minutes, which cannot satisfy a

1

-minute alarm evaluation period.

To resolve the `INSUFFICIENT_DATA` state for a

1

-minute alarm period, detailed monitoring (

1

-minute interval) must be enabled on the EC2 instances.

Analyze the remediation action target capability.

CloudWatch alarms cannot directly target Systems Manager Automation runbooks.

An Amazon EventBridge rule must be created to intercept the CloudWatch alarm state change event and route it to the Systems Manager Automation runbook.

Key Concept

CloudWatch alarm evaluation intervals require matching metric granularity, and Systems Manager Automation integrations rely on Amazon EventBridge for event-driven orchestration.

Estimated Time:2m 0s

Question 112Question →

A SysOps Administrator created a new trail in AWS CloudTrail to log API activity across an AWS account and configured it to deliver log files to a newly created Amazon S3 bucket. A few hours later, the administrator notices that no log files have been delivered to the S3 bucket. Which of the following configuration issues is the most likely cause of this failure?

The S3 bucket policy does not grant the CloudTrail service principal permission to perform the s3:PutObject action on the bucket.

The IAM identity used to create the trail is missing the iam:PassRole permission to pass the CloudTrail service role.

The AWS account is missing an Amazon EventBridge rule to route CloudTrail events from the default event bus to the destination S3 bucket.

The CloudTrail trail is configured with standard monitoring instead of detailed monitoring, which prevents automatic log file delivery.

Show answer & explanation

Answer: The S3 bucket policy does not grant the CloudTrail service principal permission to perform the s3:PutObject action on the bucket.

Answer

The destination S3 bucket policy does not grant the CloudTrail service principal permission to perform the s3:PutObject action on the bucket.

AWS CloudTrail writes log files directly to the destination Amazon S3 bucket by assuming the CloudTrail service principal identity. To allow this, the S3 bucket policy must contain a statement that grants the 'cloudtrail.amazonaws.com' service principal permission to perform 's3:PutObject' and 's3:GetBucketAcl' actions. If these permissions are missing, CloudTrail cannot deliver the logs, resulting in empty buckets.

Step-by-Step Solution

Identify how AWS CloudTrail authentication and authorization to external resources works.

CloudTrail is an AWS service that delivers log files directly to an Amazon S3 bucket. It does not use an IAM role by default for S3 delivery; it uses a resource-based policy (S3 bucket policy).

This helps determine if the issue lies in an IAM role policy or the S3 bucket policy.

Analyze the permission requirements for the S3 bucket policy.

The bucket policy must explicitly allow the 'cloudtrail.amazonaws.com' principal to call the 's3:PutObject' action on the bucket's prefix path.

Without this policy, CloudTrail will receive an Access Denied error when attempting to write log files, and delivery will fail.

Evaluate the options to find the matching configuration issue.

The option specifying that the S3 bucket policy does not grant the CloudTrail service principal permission to perform the s3:PutObject action matches the correct root cause.

This is the most common reason for failed CloudTrail log delivery when a new bucket is targeted.

Key Concept

AWS CloudTrail log delivery requires the destination S3 bucket policy to grant s3:PutObject permissions to the cloudtrail.amazonaws.com service principal.

Estimated Time:45s

Question 113Question →

A SysOps Administrator is managing an application running on a fleet of Amazon EC2 instances within an Auto Scaling group. The application publishes a custom metric named `TransactionLatency` to Amazon CloudWatch at a standard resolution of $60$ seconds. The administrator has configured a CloudWatch alarm to monitor the $99\text{th}$ percentile ( $p_{99}$ ) of `TransactionLatency` over a period of $1$ minute. The alarm is designed to trigger an AWS Systems Manager (SSM) Automation document to reboot an unhealthy instance if the latency exceeds $800\text{ ms}$ for $3$ consecutive evaluation periods.

During testing, the administrator observes two issues:
1. The alarm frequently transitions to `INSUFFICIENT_DATA` when traffic is very low and no transactions are processed, triggering false notifications.
2. When the latency threshold is breached, the SSM Automation document is never executed, even though the SSM execution role has the correct trust policy.

Which TWO configuration changes should the SysOps Administrator make to address these issues?

Select all that apply

Configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.

Create an Amazon EventBridge rule that detects the CloudWatch alarm state change to ALARM and targets the Systems Manager Automation document.

Enable detailed monitoring on the EC2 instances in the Auto Scaling group to increase the custom metric reporting frequency.

Add the Amazon Resource Name (ARN) of the Systems Manager Automation document directly to the CloudWatch alarm actions list under the ALARM state.

Set the Auto Scaling group's default cooldown period to zero to prevent metric aggregation delays during instance reboots.

Show answer & explanation

Answer: Configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching.; Create an Amazon EventBridge rule that detects the CloudWatch alarm state change to ALARM and targets the Systems Manager Automation document.

Answer

Configure the CloudWatch alarm's missing data treatment to treat missing data as notBreaching, and create an Amazon EventBridge rule that detects the CloudWatch alarm state change to ALARM and targets the Systems Manager Automation document.

To resolve the false notifications caused by the alarm entering the INSUFFICIENT_DATA state during low-traffic periods, the administrator should set the missing data treatment to treat missing data as notBreaching. This ensures the alarm stays in or returns to the OK state when no transactions occur. To resolve the issue with the Systems Manager Automation document not triggering, the administrator must use an Amazon EventBridge rule. CloudWatch alarms cannot directly trigger SSM Automation documents; instead, an EventBridge rule must be configured to match the alarm state transition to ALARM and target the SSM Automation document.

Step-by-Step Solution

Analyze the root cause of the false notifications due to missing metric data.

Determine that during low-traffic periods, no transaction latency data points are published, causing CloudWatch to evaluate the alarm state as INSUFFICIENT_DATA.

To prevent false alarms, the missing data behavior must be configured to transition to a safe state when data is absent.

Configure the missing data treatment for the CloudWatch alarm.

Set the missing data behavior to treat missing data as notBreaching.

Treating missing data as notBreaching ensures the alarm transitions to or stays in the OK state when no transactions are occurring, rather than entering INSUFFICIENT_DATA.

Analyze the root cause of the SSM Automation document execution failure.

Identify that CloudWatch alarms cannot directly target Systems Manager Automation documents from the ALARM actions configuration.

CloudWatch alarms are restricted to routing actions to SNS, EC2 resource actions, Auto Scaling policies, and OpsCenter/Incident Manager.

Establish the correct event routing path for automated remediation.

Create an Amazon EventBridge rule that monitors CloudWatch alarm state transitions to ALARM and triggers the SSM Automation document.

EventBridge is designed to capture CloudWatch alarm state change events and natively route them to Systems Manager Automation for automated remediation.

Key Concept

CloudWatch Alarm Actions and Missing Data Treatment

Estimated Time:3m 0s

Question 114Question →

An organization requires a SysOps Administrator to verify that the AWS CloudTrail log files delivered to an Amazon S3 bucket have not been modified, deleted, or tampered with after delivery. Which CloudTrail feature should be configured to satisfy this requirement?

Configure AWS KMS encryption using a customer managed key.

Enable Multi-Factor Authentication (MFA) Delete on the destination S3 bucket.

Enable log file integrity validation on the trail.

Create an Amazon EventBridge rule that triggers an AWS Lambda function when log files are delivered.

Show answer & explanation

Answer: Enable log file integrity validation on the trail.

Answer

Enable log file integrity validation on the trail.

Enabling log file integrity validation causes CloudTrail to deliver cryptographically signed digest files to the S3 bucket. These digest files can be used with the AWS CLI to verify that the log files have not been modified, deleted, or tampered with since they were delivered by CloudTrail.

Step-by-Step Solution

Identify the core security requirement.

The requirement is to detect if CloudTrail log files have been modified, deleted, or tampered with after delivery.

This establishes that we need a mechanism to verify log integrity.

Evaluate the native features of AWS CloudTrail that support log integrity.

AWS CloudTrail provides a built-in feature called log file integrity validation, which uses SHA-256 for hashing and SHA-256 with RSA for digital signatures.

This feature generates digest files that contain a hash of the log files, allowing verification of whether log files were modified or deleted.

Key Concept

CloudTrail Log File Integrity Validation

Question 115Question →

A SysOps Administrator is configuring an Amazon CloudWatch alarm to monitor the CPU utilization of a standalone Amazon EC2 instance. The administrator wants the alarm to evaluate metrics at 1-minute intervals. However, the alarm remains in the INSUFFICIENT_DATA state because the CPU metric is only being reported every 5 minutes. Which actions must the administrator take to resolve this issue? (Select TWO.)

Select all that apply

Enable detailed monitoring on the EC2 instance.

Configure the CloudWatch alarm with a period of 60 seconds.

Enable high-resolution metrics on the EC2 instance.

Create an Amazon EventBridge rule to poll the EC2 instance CPU metrics every 60 seconds.

Modify the EC2 Auto Scaling group cooldown period to 60 seconds.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instance.; Configure the CloudWatch alarm with a period of 60 seconds.

Answer

Enable detailed monitoring on the EC2 instance and configure the CloudWatch alarm with a period of 60 seconds.

To resolve the insufficient data issue and alarm at a 1-minute frequency, standard EC2 monitoring (5-minute interval) must be upgraded to detailed monitoring, which publishes metrics every 1 minute. Additionally, the CloudWatch alarm itself must be configured with a 60-second evaluation period to match the metric publishing rate.

Step-by-Step Solution

Enable detailed monitoring on the target EC2 instance.

The instance begins publishing CPU utilization metrics at 1-minute intervals rather than the default 5-minute standard monitoring intervals.

CloudWatch cannot alarm at 1-minute periods if data is only available every 5 minutes, resulting in an INSUFFICIENT_DATA state.

Set the alarm period to 60 seconds.

The alarm evaluates the 1-minute data points published by detailed monitoring.

This matches the metric ingestion frequency and allows the alarm to trigger within the desired 1-minute window.

Key Concept

By default, EC2 instances report metrics at a 5-minute frequency (standard monitoring). To evaluate metrics at a 1-minute resolution, detailed monitoring must be enabled on the instance, and the CloudWatch alarm's evaluation period must be configured to 60 seconds.

Question 116Question →

An application team wants to automatically reboot an Amazon EC2 instance when a custom application metric, `TransactionFailureRate`, exceeds a threshold. A SysOps Administrator configures a CloudWatch alarm to monitor this metric. The administrator needs to trigger the `AWS-RestartEC2Instance` Systems Manager (SSM) Automation runbook when the alarm enters the ALARM state, but finds that CloudWatch alarms cannot directly target SSM Automation runbooks. Which configuration should the administrator use to achieve this goal?

Enable detailed monitoring on the EC2 instance to allow the CloudWatch alarm to directly target the Systems Manager Automation runbook.

Create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, and specify the Systems Manager Automation runbook as the target.

Configure the CloudWatch alarm to send an Amazon Simple Queue Service (Amazon SQS) message to a queue, and configure the Systems Manager Automation runbook to poll the queue.

Configure an Auto Scaling group cooldown period on the EC2 instance to pause metric collection while the Systems Manager Automation runbook is executing.

Show answer & explanation

Answer: Create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, and specify the Systems Manager Automation runbook as the target.

Answer

Create an Amazon EventBridge rule that triggers when the CloudWatch alarm state changes to ALARM, and specify the Systems Manager Automation runbook as the target.

The correct configuration uses Amazon EventBridge to bridge the gap because CloudWatch alarms cannot directly target Systems Manager Automation runbooks. When a CloudWatch alarm changes state, it emits an event to the default EventBridge event bus. An EventBridge rule can match this state change event (e.g., transition to ALARM) and trigger the Systems Manager Automation runbook (AWS-RestartEC2Instance) to reboot the target EC2 instance.

Step-by-Step Solution

Identify the destination limits of Amazon CloudWatch alarms.

CloudWatch alarms can natively send notifications to SNS, perform EC2 actions (like reboot), or trigger Auto Scaling policies, but cannot directly invoke Systems Manager Automation runbooks.

This establishes the need for an intermediary service to route the alarm transition event.

Determine the service designed to handle resource state changes and route them to targets.

Amazon EventBridge captures CloudWatch alarm state change events (specifically transitions to the ALARM state) as event patterns.

EventBridge acts as the event router between CloudWatch alarms and other AWS services.

Select the appropriate target for the EventBridge rule.

Configure the Systems Manager Automation runbook (AWS-RestartEC2Instance) as the target of the EventBridge rule, specifying the target EC2 instance ID.

This completes the event-driven workflow to automatically reboot the instance upon alarm trigger.

Key Concept

Integrating CloudWatch Alarms with Systems Manager Automation using EventBridge

Question 117Question →

A SysOps Administrator is configuring a new AWS CloudTrail trail to deliver log files to an Amazon S3 bucket. The logs must be encrypted using a customer managed AWS KMS key. After configuring the trail, the administrator notices that CloudTrail is failing to deliver logs to the S3 bucket. Which of the following configuration changes must the administrator make to resolve this issue? (Select two.)

Select all that apply

Modify the Amazon S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform the s3:PutObject action on the log path.

Modify the customer managed KMS key policy to allow the cloudtrail.amazonaws.com service principal to perform the kms:GenerateDataKey* action.

Attach an IAM policy to the SysOps Administrator's IAM role that grants kms:GenerateDataKey* access to the key, without modifying the KMS key policy.

Configure the Amazon S3 bucket policy to only allow the cloudtrail.amazonaws.com service principal to perform s3:GetObject and s3:ListBucket actions.

Show answer & explanation

Answer: Modify the Amazon S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform the s3:PutObject action on the log path.; Modify the customer managed KMS key policy to allow the cloudtrail.amazonaws.com service principal to perform the kms:GenerateDataKey* action.

Answer

Modify the Amazon S3 bucket policy to allow the cloudtrail.amazonaws.com service principal to perform the s3:PutObject action on the log path, and modify the customer managed KMS key policy to allow the cloudtrail.amazonaws.com service principal to perform the kms:GenerateDataKey* action.

For CloudTrail to deliver logs encrypted with a customer managed KMS key, both the destination S3 bucket and the KMS key must have resource-based policies that grant access to the CloudTrail service principal. Specifically, the S3 bucket policy must allow s3:PutObject, and the KMS key policy must allow kms:GenerateDataKey*.

Step-by-Step Solution

Update the S3 bucket policy to grant s3:PutObject permissions to cloudtrail.amazonaws.com.

CloudTrail has write access to the S3 bucket.

CloudTrail must write logs directly to the target S3 bucket.

Update the KMS key policy to grant kms:GenerateDataKey* permissions to cloudtrail.amazonaws.com.

CloudTrail can generate data keys to encrypt logs using the KMS key.

When a trail uses a customer managed key, CloudTrail requires key policy permissions to generate the keys used for log encryption.

Key Concept

AWS CloudTrail log delivery requires specific resource-based policy configurations on both S3 buckets (for write access) and KMS keys (for encryption capabilities).

Question 118Question →

A SysOps Administrator is managing a production application on Amazon EC2 instances. The instances are running with default monitoring enabled. The administrator configures an Amazon CloudWatch alarm to monitor the CPUUtilization metric of the instances. The alarm is configured with a period of 60 seconds and an evaluation period of 3 consecutive periods. However, the administrator notices that the alarm remains in the INSUFFICIENT_DATA state even when the instances are under high load. Which two actions should the administrator take to resolve this issue and allow the alarm to transition to the ALARM state correctly? (Select TWO.)

Select all that apply

Enable detailed monitoring on the EC2 instances.

Modify the CloudWatch alarm configuration to use a period of 300 seconds (5 minutes) instead of 60 seconds.

Create an Amazon EventBridge rule that triggers a target to pull CPU metrics from the instances every 60 seconds.

Increase the Auto Scaling group cooldown period to ensure that the metrics have sufficient time to populate.

Configure a custom CloudWatch metric filter to aggregate hypervisor log data at 1-minute intervals.

Show answer & explanation

Answer: Enable detailed monitoring on the EC2 instances.; Modify the CloudWatch alarm configuration to use a period of 300 seconds (5 minutes) instead of 60 seconds.

Answer

The administrator should enable detailed monitoring on the EC2 instances, or modify the CloudWatch alarm configuration to use a period of 300 seconds (5 minutes).

To resolve the INSUFFICIENT_DATA state, the alarm period must align with the metric reporting frequency. Standard monitoring for EC2 publishes metrics every 5 minutes (300 seconds), whereas detailed monitoring publishes them every 1 minute (60 seconds). Therefore, the administrator must either enable detailed monitoring to provide 1-minute metrics or change the alarm period to 5 minutes to match standard monitoring.

Step-by-Step Solution

Identify that standard EC2 monitoring delivers metrics to CloudWatch every 5 minutes.

Understanding that a 60-second alarm period will lack data points under default settings.

Aligning data resolution with the alarm evaluation period is necessary to prevent the INSUFFICIENT_DATA state.

Determine the available resolutions to match the metric delivery interval with the alarm period.

Two valid paths: either increase metric delivery frequency or decrease alarm evaluation frequency.

This resolves the lack of data points during the alarm's evaluation window.

Select the configurations that achieve these paths.

Enabling detailed monitoring (increases metric delivery to 1-minute intervals) or changing the alarm period to 300 seconds (decreases evaluation frequency to match the 5-minute standard monitoring).

These are the standard, non-disruptive ways to align metric frequency and alarm duration.

Key Concept

CloudWatch EC2 monitoring intervals (standard vs. detailed) and their alignment with alarm evaluation periods.

Estimated Time:2m 0s

Question 119Question →

An application deployed on Amazon EC2 instances publishes a custom metric named `TransactionLatency` at $10$ -second intervals using the AWS SDK. The metric is sent with three dimensions: `ClusterName`, `Service`, and `Region`. A SysOps Administrator needs to configure an Amazon CloudWatch alarm to trigger if the average latency across all services in the `prod-cluster` cluster exceeds $150\text{ ms}$ for $3$ consecutive $1$ -minute evaluation periods. The administrator creates a CloudWatch alarm for `TransactionLatency` specifying a single dimension of `ClusterName=prod-cluster` and a period of $1\text{ minute}$ . However, the alarm remains in the `INSUFFICIENT_DATA` state even though the services are actively publishing metrics. Which of the following describes the root cause of this issue and the correct resolution?

The Auto Scaling group's scaling cooldown period (set to

300

-seconds) is longer than the alarm evaluation window of

3\text{ minutes}

(

3 \times 1\text{ minute}

), which suppresses custom metric data retrieval until the cooldown period expires.

Detailed monitoring must be enabled for the EC2 instances. Custom metrics published at high-resolution require detailed monitoring to be active on the host instances in order to aggregate data at

1

-minute intervals.

CloudWatch does not support automatic aggregation across dimensions. The administrator must use a CloudWatch Metric Math `SEARCH` expression to aggregate the metrics across the omitted dimensions, or publish the metric with only the `ClusterName` dimension.

The custom metric must be routed through an Amazon EventBridge rule to an AWS Systems Manager Automation runbook. High-resolution metrics evaluated over standard periods cannot be processed directly by CloudWatch Alarms without this intermediate automation step.

Show answer & explanation

Answer: CloudWatch does not support automatic aggregation across dimensions. The administrator must use a CloudWatch Metric Math `SEARCH` expression to aggregate the metrics across the omitted dimensions, or publish the metric with only the `ClusterName` dimension.

Answer

CloudWatch does not support automatic aggregation across dimensions. The administrator must use a CloudWatch Metric Math SEARCH expression to aggregate the metrics across the omitted dimensions, or publish the metric with only the ClusterName dimension.

The correct answer states that CloudWatch does not support automatic aggregation across dimensions. Each unique set of dimensions uniquely identifies a metric in CloudWatch. If a metric is published with multiple dimensions (ClusterName, Service, and Region), querying that metric using only a subset (ClusterName) will look for a metric published with only that single dimension. Since no such metric exists, the query returns no data, causing the alarm to remain in the INSUFFICIENT_DATA state. The resolution is to either modify the application to publish the metric with the desired aggregated dimension set, or use Metric Math SEARCH expressions to aggregate the metrics.

Step-by-Step Solution

Analyze how Amazon CloudWatch stores and identifies metrics based on dimensions.

Identify that CloudWatch treats each unique dimension combination as a distinct metric identity, and does not automatically roll up or aggregate metrics by subset dimensions.

This explains why querying a metric with a subset of the published dimensions (e.g., querying only ClusterName when ClusterName, Service, and Region are published) returns no data.

Evaluate the proposed solutions for aggregating multi-dimensional metrics.

Determine that the administrator can either publish the metric with fewer dimensions or use CloudWatch Metric Math with a SEARCH function to dynamically aggregate the metrics in real time.

This identifies the necessary remediation steps to make the aggregate metrics visible to the alarm configuration.

Validate the correct configuration for the CloudWatch alarm.

Ensure that the alarm targets either the exact dimension combination or uses the metric math expression to resolve the INSUFFICIENT_DATA state.

This completes the troubleshooting and resolution process.

Key Concept

CloudWatch Metric Dimensions and Aggregation

Estimated Time:3m 0s

Question 120Question →

A SysOps Administrator is managing a microservices application running on a fleet of Amazon EC2 instances. The fleet size fluctuates dynamically based on demand via an Auto Scaling group. Each instance publishes a custom CloudWatch metric named `RequestLatency` in the namespace `CustomApp` using two dimensions: `InstanceId` and `ServiceName`. The administrator needs to configure a single CloudWatch alarm to alert when the average `RequestLatency` for the service named `InventoryService` exceeds $500$ milliseconds across the entire fleet. Which two configurations or actions should the administrator perform to achieve this? (Select TWO.)

Select all that apply

Modify the application code to publish the RequestLatency metric a second time using only the ServiceName dimension, and configure the CloudWatch alarm to monitor this new metric.

Configure the CloudWatch alarm using a Metric Insights query: SELECT AVG(RequestLatency) FROM SCHEMA("CustomApp", ServiceName) WHERE ServiceName = 'InventoryService'.

Configure the CloudWatch alarm to monitor RequestLatency in the CustomApp namespace, specifying the ServiceName dimension as InventoryService and leaving the InstanceId dimension blank.

Configure a CloudWatch Metric Math expression using the SUM function to automatically aggregate RequestLatency across all dynamic InstanceId values.

Enable detailed monitoring on all EC2 instances in the Auto Scaling group so that CloudWatch automatically aggregates custom namespace metrics at 1-minute intervals.

Show answer & explanation

Answer: Modify the application code to publish the RequestLatency metric a second time using only the ServiceName dimension, and configure the CloudWatch alarm to monitor this new metric.; Configure the CloudWatch alarm using a Metric Insights query: SELECT AVG(RequestLatency) FROM SCHEMA("CustomApp", ServiceName) WHERE ServiceName = 'InventoryService'.

Answer

To monitor the aggregate latency of a custom metric across a dynamic fleet of instances, the administrator should either configure the CloudWatch alarm using a Metric Insights query to aggregate the metrics, or modify the application code to publish the metric a second time without the instance ID dimension.

To alarm on the average latency of a service across a dynamic fleet of instances, the SysOps Administrator must overcome the limitation that CloudWatch does not automatically aggregate custom metrics across dimensions. Modifying the application code to publish the metric with only the ServiceName dimension creates an aggregated metric stream that can be directly alarmed on. Alternatively, using a CloudWatch Metric Insights SQL query allows real-time aggregation over the dynamic InstanceId dimension, outputting a single aggregated time series suitable for an alarm.

Step-by-Step Solution

Identify how CloudWatch handles custom metrics with multiple dimensions.

Recognize that CloudWatch treats every unique combination of dimensions as a separate metric stream, meaning it does not automatically aggregate custom metrics across dimensions.

This explains why querying the metric by omitting the InstanceId dimension in a standard alarm configuration results in missing data.

Evaluate application-side changes to support aggregate monitoring.

Understand that publishing the metric twice—once with both dimensions and once with only the ServiceName dimension—creates an aggregated stream.

This allows the SysOps Administrator to configure a standard CloudWatch alarm directly on the single-dimension metric stream representing the whole fleet.

Evaluate query-side aggregation using CloudWatch Metric Insights.

Construct a SQL query that aggregates the metric across the dynamic InstanceId dimension and filters by ServiceName.

CloudWatch Metric Insights enables real-time query aggregation, and CloudWatch alarms can be created directly on queries that return a single time series.

Key Concept

CloudWatch Custom Metric Dimensions and Aggregation

PreviousPage 6 / 49Next

All practice questions

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept