A SysOps Administrator is configuring monitoring for a containerized microservices applica… — AWS Certified SysOps Administrator - Associate

A SysOps Administrator is configuring monitoring for a containerized microservices application that writes logs to an Amazon CloudWatch Logs group in JSON format. A typical log event with a successful response looks like this:

{
"tenantId": "tenant-12",
"requestPath": "/checkout",
"responseCode": 200,
"executionTimeMs": 1250
}

For requests that fail due to an early gateway timeout, the `executionTimeMs` field is omitted from the JSON payload:

{
"tenantId": "tenant-12",
"requestPath": "/checkout",
"responseCode": 504
}

The Administrator needs to create a metric filter to track the latency of failed gateway requests (where `responseCode` is $502$ or $504$ ). The resulting metric must be named `GatewayLatency` in the custom namespace `AppMetrics`, with the dimension `Tenant` mapped to `tenantId` and the dimension `Path` mapped to `requestPath`. When the `executionTimeMs` field is missing, the metric must record a value of $1500$ milliseconds. Metric points should not be published for successful requests or other status codes.

Which configuration combination should the SysOps Administrator implement to meet these requirements?

Set the filter pattern to `{ $.responseCode = 502 ||$ .responseCode = 504 }`. In the metric transformation, set the metric value to ` $.executionTimeMs` and the default value to$ 1500 $. Configure the dimensions `Tenant` and `Path` to use the JSON paths `$ .tenantId` and `$.requestPath`, respectively.Answer
B
Set the filter pattern to `{ ( $.responseCode = 502 ||$ .responseCode = 504) && $.executionTimeMs EXISTS }`. In the metric transformation, set the metric value to `$ .executionTimeMs` and the default value to $1500$ . Configure the dimensions `Tenant` and `Path` to use the JSON paths ` $.tenantId` and `$ .requestPath`, respectively.
C
Set the filter pattern to `{ $.responseCode = 502 ||$ .responseCode = 504 }`. In the metric transformation, set the metric value to ` $.executionTimeMs` and leave the default value empty. Enable Detailed Monitoring on the underlying application hosts to automatically report the fallback value of$ 1500 $at a$ 1$-minute aggregation interval.
D
Set the filter pattern to `{ $.responseCode = 502 ||$ .responseCode = 504 }`. Create an Amazon EventBridge rule that triggers an AWS Systems Manager Automation runbook to extract the missing latency field and call the PutMetricData API to publish the custom metric with a value of $1500$ .

Answer

Set the filter pattern to `{

.responseCode = 502 ||

.responseCode = 504 }`. In the metric transformation, set the metric value to `

.executionTimeMs` and the default value to

1500

. Configure the dimensions `Tenant` and `Path` to use the JSON paths `

.tenantId` and `$.requestPath`, respectively.

The correct configuration uses the filter pattern to select only the logs representing gateway errors (status codes

502

504

). In the metric transformation, setting the metric value to the JSON path of the latency field and specifying a default value of

1500

ensures that if the log event matches the filter pattern but lacks the latency field, CloudWatch still publishes the metric point with the value of

1500

using the tenant and path dimensions.

Step-by-Step Solution

Determine the correct CloudWatch Logs JSON filter pattern to select only the gateway timeout errors.

The correct pattern is `{

.responseCode = 502 ||

.responseCode = 504 }`, which matches log events with either response status code.

We must isolate events that represent gateway failures before extracting execution time or applying default logic.

Identify the target metric extraction value and the required behavior for missing fields.

The metric value path is `

.executionTimeMs`. To publish

1500

when this field is missing,

1500$ must be defined as the metric transformation's 'Default value'.

CloudWatch Logs metric filters use the default value only when the pattern matches the log event but the specified JSON path does not exist in that event.

Map the required dimensions using JSON paths.

Configure dimension key-value pairs: `Tenant` mapped to `

.tenantId` and `Path` mapped to `

.requestPath`.

This allows CloudWatch to publish the custom metric under the correct dimension categories extracted dynamically from the matching log events.

Evaluate the configuration logic to ensure missing field events are processed.

If the filter pattern does not check for field existence (i.e. does not use `EXISTS`), the log event matches, the dimensions are extracted, and the default value is successfully published.

Including `EXISTS` in the filter pattern would filter out the target logs before the metric transformation can apply the default value fallback.

Key Concept

CloudWatch Logs Metric Filters allow SysOps Administrators to extract metrics and custom dimensions from structured JSON logs. When log events match a filter pattern but lack the JSON field specified in the metric value, CloudWatch publishes the metric with the defined default value using the dimensions extracted from that log event.

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic