SAP-C02 Continuous Improvement for Existing Solutions 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.

• ✗

  Configure AWS Config rules on the EKS cluster and use AWS CloudTrail to record API calls, then query the data with Amazon Athena during incidents.

  Why it's wrong here

  AWS Config records resource configuration changes and CloudTrail records API activity, which help with audit and drift detection but not with runtime performance or application-level tracing. Querying these sources in Athena during an incident is slow and does not correlate metrics, logs, and traces. This does not automate anomaly detection or reduce diagnosis time.

• ✓

  Deploy the AWS Distro for OpenTelemetry to collect metrics and traces, send them to Amazon CloudWatch with embedded metric format, and enable CloudWatch anomaly detection and ServiceLens for correlated analysis.

  Why this is correct

  AWS Distro for OpenTelemetry collects metrics and traces from EKS workloads and forwards them, while CloudWatch embedded metric format ingests high-cardinality metrics cost-effectively. CloudWatch anomaly detection models normal behavior and flags deviations, and ServiceLens correlates metrics, logs, and traces through a service map. Together they automate detection and cross-signal correlation, directly cutting time to resolution.

• ✗

  Enable Amazon GuardDuty for EKS and configure findings to trigger AWS Lambda functions that restart unhealthy pods automatically.

  Why it's wrong here

  GuardDuty for EKS detects suspicious activity and threats such as compromised credentials or malicious containers, not performance anomalies or application errors. Restarting pods on threat findings does not help engineers diagnose latency or error spikes. This approach addresses security monitoring rather than the observability and correlation needed to reduce mean time to resolution.

• ✗

  Install the CloudWatch agent on each node to collect system metrics, and create static CloudWatch alarms with fixed thresholds for CPU and memory on every service.

  Why it's wrong here

  Static thresholds require engineers to guess appropriate limits for each service and generate false positives or miss gradual degradation. This approach collects infrastructure metrics but does not collect distributed traces or correlate them with logs, so cross-service root cause analysis remains manual. It does not deliver the automated anomaly detection and correlation the requirement demands.

Go deeper

Related to this question