Back to AWS Certified Developer - Associate (DVA-C02)

Troubleshooting and Optimization

Perform root cause analysis, instrument code for observability, and optimize application performance (~18% of exam).

Covers assisting in root cause analysis including debugging code defects, interpreting metrics/logs/traces, querying logs, implementing custom metrics with CloudWatch EMF, reviewing application health with dashboards, troubleshooting deployment failures, and debugging service integration issues. Also covers instrumenting code for observability including differences between logging/monitoring/observability, effective logging strategies, custom metrics emission, tracing annotations, notification alerts, AWS tracing tools, structured logging, and health checks/readiness probes. Additionally covers optimizing applications including concurrency concepts, performance profiling, memory and compute sizing, subscription filter policies, request header caching, application-level caching, resource usage optimization, and identifying performance bottlenecks through logs.
5 minutes 5 Questions

Troubleshooting and Optimization are critical skills for AWS Certified Developer - Associate certification, focusing on identifying issues and improving application performance within AWS environments. **Troubleshooting** involves systematically diagnosing and resolving problems in AWS application…

Concepts covered: X-Ray segments and subsegments, Distributed tracing, CloudWatch alarms and notifications, Amazon SNS for alerting, Quota limit notifications, Deployment completion notifications, AWS CloudTrail for API logging, Structured logging for applications, JSON logging format, Application health checks, Readiness probes, Liveness probes, Concurrency concepts, Lambda concurrency management, Reserved concurrency, Application performance profiling, Amazon CodeGuru Profiler, Determining optimal memory allocation, Compute power optimization, Lambda Power Tuning, SNS subscription filter policies, SQS message filtering, CloudFront cache behavior, Caching based on request headers, Application-level caching, Cache invalidation strategies, Resource usage optimization, Cold start optimization, Analyzing performance issues, Identifying performance bottlenecks, Debugging code defects, Interpreting application metrics, Interpreting application logs, Interpreting application traces, Amazon CloudWatch Logs Insights, Querying logs for relevant data, CloudWatch embedded metric format (EMF), Custom CloudWatch metrics, CloudWatch dashboards, CloudWatch Container Insights, CloudWatch Application Insights, Troubleshooting deployment failures, Service output logs analysis, Debugging service integration issues, Logging vs monitoring vs observability, Effective logging strategies, Log levels and log aggregation, Emitting custom metrics from code, AWS X-Ray tracing, X-Ray annotations and metadata

Test mode:
Start practice test
DVA-C02 - Troubleshooting and Optimization Example Questions

Test your knowledge of Troubleshooting and Optimization

Question 1

Which Kubernetes liveness probe type sends a request to a specified port to verify the container is accepting connections?

Correct Answer: tcpSocket probe

The tcpSocket probe is the correct answer. This Kubernetes liveness probe type works by attempting to establish a TCP connection to a specified port on the container. If the connection can be established successfully, the probe is considered successful, indicating the container is accepting connections on that port. The kubelet will attempt to open a socket to your container on the specified port, and if it can establish a connection, the container is considered healthy.

The httpGet probe is incorrect because while it does send a request to a port, it specifically performs an HTTP GET request and expects an HTTP response with a status code between 200 and 399. It's not just checking if the port accepts connections - it's validating HTTP endpoint responses.

The exec probe is incorrect because it executes a command inside the container and checks the exit code. It doesn't inherently send requests to ports - it runs arbitrary commands specified in the probe configuration.

The grpc probe is incorrect because while it does connect to a port, it specifically uses the gRPC health checking protocol and requires the application to implement the gRPC Health Checking Protocol. It's designed specifically for gRPC services, not just general port connectivity checks.

Question 2

A travel booking platform operates on AWS and uses a microservices architecture with multiple Lambda functions processing reservations. The DevOps team has configured CloudWatch alarms to monitor application health. They created an alarm on a custom metric called 'BookingErrors' with a threshold of 10 errors, using the Sum statistic with a 5-minute period and 1 evaluation period. The alarm is connected to an SNS topic with both email and SMS subscriptions. During a database connectivity issue, the application experienced errors but the alarm remained in OK state. Investigation revealed that the Lambda functions were publishing the BookingErrors metric using the PutMetricData API with a dimension of 'Environment=Production'. However, when the DevOps engineer created the alarm, they specified the metric name correctly but configured the alarm with a dimension of 'Env=Production'. The metric data shows clear spikes above the threshold during the incident timeframe. What is the primary reason the alarm failed to transition to ALARM state during this incident?

Correct Answer: The alarm is monitoring a different metric because CloudWatch treats metrics with different dimension names as completely separate metrics

The primary reason the alarm failed to transition to ALARM state is that CloudWatch treats metrics with different dimension names as completely separate metrics.

In CloudWatch, a metric is uniquely identified by its namespace, metric name, AND dimensions (both dimension names and values). In this scenario:

  • The Lambda functions were publishing metrics with the dimension 'Environment=Production'
  • The alarm was configured to monitor the metric with dimension 'Env=Production'

Because the dimension NAME is different ('Environment' vs 'Env'), CloudWatch considers these to be two entirely different metrics. The alarm was essentially monitoring a metric that had no data points being published to it, while the actual error data was being published to a different metric with the 'Environment' dimension.

This is a critical CloudWatch concept - dimensions are case-sensitive and must match exactly in both name and value for the alarm to evaluate the correct metric data.

The other answers are incorrect:

  • The Sum statistic does not require multiple datapoints to accumulate - it simply sums the values within each evaluation period. A single datapoint above the threshold would trigger the alarm if configured with 1 evaluation period.

  • Custom metrics from Lambda do not have special propagation delays that would prevent alarm evaluation. Custom metrics are available for alarm evaluation as soon as they are published via PutMetricData.

  • Metric resolution (standard 1-minute or high-resolution 1-second) does not cause threshold comparison failures. CloudWatch can evaluate alarms on metrics regardless of the resolution used when publishing, as long as the metric identity (namespace, name, and dimensions) matches.

Question 3

A payment processing company has deployed an AWS Lambda function using .NET 8 runtime that validates credit card transactions. The function imports Entity Framework Core for data access, Newtonsoft.Json for serialization, and custom fraud detection modules, creating a 42 MB deployment package. The function operates within a VPC to communicate with an on-premises fraud detection system through AWS Direct Connect. Transaction logs reveal that merchants processing their first transaction after store opening (which varies by timezone across 15 countries) experience 13-16 second authorization delays, while transactions during active shopping periods complete in 750ms. The function is configured with 2560 MB memory. Network analysis confirms VPC Elastic Network Interface creation contributes 5-6 seconds, while .NET runtime initialization and dependency loading account for 7-8 seconds. The company processes 2,000 transactions per second during global peak hours but only 20-30 per minute during the quietest global period (around 4 AM UTC). Management requires all transaction authorizations to complete in under 3 seconds to meet payment network SLA requirements. Given the global merchant distribution with unpredictable store opening times, which optimization strategy would most effectively address the cold start latency requirements?

Correct Answer: Configure Provisioned Concurrency with Application Auto Scaling to maintain a baseline of warm instances that scales based on scheduled patterns aligned with major timezone business hours

The correct answer is to configure Provisioned Concurrency with Application Auto Scaling to maintain a baseline of warm instances that scales based on scheduled patterns aligned with major timezone business hours.

Let's analyze the problem:
- Cold start latency is 13-16 seconds total (5-6 seconds for VPC ENI creation + 7-8 seconds for .NET runtime initialization)
- SLA requirement is under 3 seconds for all transactions
- The challenge is unpredictable store opening times across 15 countries with varying timezones
- Traffic varies dramatically from 2,000 TPS at peak to 20-30 per minute during quiet periods

Provisioned Concurrency with Application Auto Scaling is the optimal solution because:
1. Provisioned Concurrency pre-initializes execution environments, completely eliminating both the VPC ENI attachment time AND the .NET runtime initialization time
2. Application Auto Scaling allows the provisioned capacity to dynamically adjust based on scheduled scaling policies aligned with business hours across different timezones
3. This approach balances cost (scaling down during truly quiet periods) while maintaining readiness for unpredictable first transactions when stores open
4. It addresses both cold start components: network (VPC ENI) and runtime initialization

Why the other options are incorrect:

Lambda SnapStart is only available for Java runtimes (specifically Java 11 and Java 17 managed runtimes). It does NOT support .NET 8 runtime, making this option technically impossible for this scenario.

Configuring Provisioned Concurrency with a static value matching peak concurrent executions would be extremely costly. With 2,000 TPS at peak but only 20-30 per minute during quiet periods, maintaining peak-level provisioned concurrency 24/7 would result in massive over-provisioning and unnecessary costs during off-peak hours.

VPC Lattice and connection pooling would not solve the core cold start problem. VPC Lattice is for service-to-service networking, not for eliminating Lambda cold starts. While it might help with some network aspects, it doesn't address the fundamental issue of ENI attachment during cold starts or the .NET runtime initialization time. The cold start would still occur.

More Troubleshooting and Optimization questions
1497 questions (total)
Start 100 question test