Practice Free DVA-C02 Exam Online Questions
Question #91
A company is building a serverless application on AWS. The application uses Amazon API Gateway and AWS Lambda. The company wants to deploy the application to its development, test, and production environments.
Which solution will meet these requirements with the LEAST development effort?
- A . Use API Gateway stage variables and create Lambda aliases to reference environment-specific resources.
- B . Use Amazon ECS to deploy the application to the environments.
- C . Duplicate the code for each environment. Deploy the code to a separate API Gateway stage.
- D . Use AWS Elastic Beanstalk to deploy the application to the environments.
Correct Answer: A
A
Explanation:
Requirement Summary:
Deploy serverless application using:
API Gateway
AWS Lambda
Need dev, test, and prod environments
Want least development effort
Evaluate Options:
Option A: API Gateway stage variables + Lambda aliases
Most efficient and scalable
API Gateway supports stage variables (like env)
Lambda supports aliases (e.g., dev, test, prod)
You can configure each stage to point to a different alias of the same function version Enables versioning, isolation, and low effort management Option B: Use Amazon ECS
Overkill for a serverless setup
ECS is container-based, not serverless
Introduces unnecessary complexity
Option C: Duplicate code for each environment
High operational overhead and poor maintainability
Option D: Use Elastic Beanstalk
Not applicable: Elastic Beanstalk is for traditional app hosting, not optimal for Lambda + API Gateway
Lambda Aliases: https: //docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html
API Gateway Stage Variables:
https: //docs.aws.amazon.com/apigateway/latest/developerguide/stage-variables.html
A
Explanation:
Requirement Summary:
Deploy serverless application using:
API Gateway
AWS Lambda
Need dev, test, and prod environments
Want least development effort
Evaluate Options:
Option A: API Gateway stage variables + Lambda aliases
Most efficient and scalable
API Gateway supports stage variables (like env)
Lambda supports aliases (e.g., dev, test, prod)
You can configure each stage to point to a different alias of the same function version Enables versioning, isolation, and low effort management Option B: Use Amazon ECS
Overkill for a serverless setup
ECS is container-based, not serverless
Introduces unnecessary complexity
Option C: Duplicate code for each environment
High operational overhead and poor maintainability
Option D: Use Elastic Beanstalk
Not applicable: Elastic Beanstalk is for traditional app hosting, not optimal for Lambda + API Gateway
Lambda Aliases: https: //docs.aws.amazon.com/lambda/latest/dg/configuration-aliases.html
API Gateway Stage Variables:
https: //docs.aws.amazon.com/apigateway/latest/developerguide/stage-variables.html
Question #92
A developer is building a microservices-based application by using Python on AWS and several AWS services The developer must use AWS X-Ray The developer views the service map by using the console to view the service dependencies. During testing, the developer notices that some services are missing from the service map
What can the developer do to ensure that all services appear in the X-Ray service map?
- A . Modify the X-Ray Python agent configuration in each service to increase the sampling rate
- B . Instrument the application by using the X-Ray SDK for Python. Install the X-Ray SDK for all the services that the application uses
- C . Enable X-Ray data aggregation in Amazon CloudWatch Logs for all the services that the application uses
- D . Increase the X-Ray service map timeout value in the X-Ray console
Correct Answer: B
B
Explanation:
AWS X-Ray SDK: The primary way to enable X-Ray tracing within applications. The SDK sends data about requests and subsegments to the X-Ray daemon for service map generation.
Instrumenting All Services: To visualize a complete microservice architecture on the service map, each relevant service must include the X-Ray SDK.
Reference: AWS X-Ray Documentation: https: //docs.aws.amazon.com/xray/
X-Ray SDK for Python: https: //docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python.html
B
Explanation:
AWS X-Ray SDK: The primary way to enable X-Ray tracing within applications. The SDK sends data about requests and subsegments to the X-Ray daemon for service map generation.
Instrumenting All Services: To visualize a complete microservice architecture on the service map, each relevant service must include the X-Ray SDK.
Reference: AWS X-Ray Documentation: https: //docs.aws.amazon.com/xray/
X-Ray SDK for Python: https: //docs.aws.amazon.com/xray/latest/devguide/xray-sdk-python.html
Question #93
A company has an application that runs on Amazon EC2 instances. The application needs to use dynamic feature flags that will be shared with other applications. The application must poll on an interval for new feature flag values. The values must be cached when they are retrieved.
Which solution will meet these requirements in the MOST operationally efficient way?
- A . Store the feature flag values in AWS Secrets Manager. Configure an Amazon ElastiCache node to cache the values by using a lazy loading strategy in the application. Update the application to poll for the values on an interval from ElastiCache.
- B . Store the feature flag values in an Amazon DynamoDB table. Configure DynamoDB Accelerator (DAX) to cache the values by using a lazy loading strategy in the application. Update the application to poll for the values on an interval from DynamoDB.
- C . Store the feature flag values in AWS AppConfig. Configure AWS AppConfig Agent on the EC2 instances to poll for the values on an interval. Update the application to retrieve the values from the AppConfig Agent localhost endpoint.
- D . Store the feature flag values in AWS Systems Manager Parameter Store. Configure the application to poll on an interval. Configure the application to use the AWS SDK to retrieve the values from Parameter Store and to store the values in memory.
Correct Answer: C
C
Explanation:
Feature flags are a classic configuration-management use case: values change over time, multiple applications share them, and clients should retrieve updates efficiently with local caching. AWS AppConfig (part of AWS Systems Manager) is purpose-built to deploy and manage application configuration and feature flags. It provides controlled rollout, validation, and centralized configuration management. For operational efficiency, AWS offers the AWS AppConfig Agent for compute environments such as EC2.
With option C, the AppConfig Agent runs on each EC2 instance and polls AppConfig on a configured interval for updates. The agent maintains a local cache and exposes the current configuration through a localhost HTTP endpoint. The application then reads the feature flag values from the local endpoint, which is fast and reduces direct calls to AWS APIs. This meets both requirements: periodic polling for new values and caching once retrieved, while minimizing application changes and centralizing operational control in AppConfig.
Option D (Parameter Store + in-memory cache) can work, but it pushes more responsibility into each application: polling logic, caching behavior, error handling, and consistency.
Option A misuses Secrets Manager (intended for secrets, not dynamic flags) and adds ElastiCache operational overhead.
Option B similarly adds DAX and DynamoDB infrastructure and is not a standard feature-flag pattern; it also requires the app to implement polling and caching logic, reducing operational efficiency.
Therefore, C is the most operationally efficient solution: store flags in AWS AppConfig, run the AppConfig Agent on EC2 to handle polling and caching, and have the application read flags from the agent’s localhost endpoint.
C
Explanation:
Feature flags are a classic configuration-management use case: values change over time, multiple applications share them, and clients should retrieve updates efficiently with local caching. AWS AppConfig (part of AWS Systems Manager) is purpose-built to deploy and manage application configuration and feature flags. It provides controlled rollout, validation, and centralized configuration management. For operational efficiency, AWS offers the AWS AppConfig Agent for compute environments such as EC2.
With option C, the AppConfig Agent runs on each EC2 instance and polls AppConfig on a configured interval for updates. The agent maintains a local cache and exposes the current configuration through a localhost HTTP endpoint. The application then reads the feature flag values from the local endpoint, which is fast and reduces direct calls to AWS APIs. This meets both requirements: periodic polling for new values and caching once retrieved, while minimizing application changes and centralizing operational control in AppConfig.
Option D (Parameter Store + in-memory cache) can work, but it pushes more responsibility into each application: polling logic, caching behavior, error handling, and consistency.
Option A misuses Secrets Manager (intended for secrets, not dynamic flags) and adds ElastiCache operational overhead.
Option B similarly adds DAX and DynamoDB infrastructure and is not a standard feature-flag pattern; it also requires the app to implement polling and caching logic, reducing operational efficiency.
Therefore, C is the most operationally efficient solution: store flags in AWS AppConfig, run the AppConfig Agent on EC2 to handle polling and caching, and have the application read flags from the agent’s localhost endpoint.
Question #94
An ecommerce company is developing a serverless application to track user activities. The company needs to track each type of activity with a timestamp and a unique product ID. The company also must track actions that are associated with each activity, such as product views, shopping cart actions, purchases, and checkout processes.
The company is planning a marketing campaign based on each user’s activity. A developer needs to implement a partitioning strategy for an Amazon DynamoDB table to meet the data storage and access requirements for the application. The strategy must maximize provisioned throughput efficiency while minimizing the risk of throttling.
Which solution will meet these requirements?
- A . Create a composite primary key. Set the user ID as the partition key and the timestamp as the sort key.
- B . Create a composite primary key. Set the product ID as the partition key and the associated actions as the sort key.
- C . Use the product ID as the partition key. Create an Application Auto Scaling policy to update the table’s provisioned throughput when the table exceeds its capacity usage target.
- D . Create an AWS Lambda function that adds a counter attribute that increases by one for each new record. Use the counter attribute as the partition key.
Correct Answer: A
A
Explanation:
For this workload, the access pattern is centered on each user’s activity history over time (the company is planning a marketing campaign based on each user’s activity). In DynamoDB, the most effective way to store and query time-ordered events per entity is to use a composite primary key where the entity identifier is the partition key and a time attribute is the sort key. Therefore, using user ID as the partition key groups all events for a given user together, and using timestamp as the sort key allows efficient retrieval in chronological order and supports range queries (for example, “activities in the last 7 days” or “between two dates”).
This design also helps maximize provisioned throughput efficiency and reduce throttling risk because it distributes data across partitions based on the partition key values (user IDs). With many users, writes and reads naturally spread across multiple partition key values rather than concentrating on a small set. The sort key further enables multiple activity records per user without overwriting items and supports precise queries without scanning.
Option B (product ID as partition key) does not align with the stated marketing need (per-user activity). It would cluster all users’ actions for a popular product into the same partition key, increasing the chance of hot partitions and throttling.
Option C also risks hot partitions for popular product IDs; auto scaling helps capacity management but does not fix poor key distribution or hot-key access patterns.
Option D (monotonic counter as partition key) is particularly problematic: sequential keys can create uneven distribution and a throughput bottleneck pattern, and it does not support user-centric queries efficiently.
Thus, A best matches the data model (user events over time), supports efficient queries, and reduces throttling risk by distributing workload across user IDs.
A
Explanation:
For this workload, the access pattern is centered on each user’s activity history over time (the company is planning a marketing campaign based on each user’s activity). In DynamoDB, the most effective way to store and query time-ordered events per entity is to use a composite primary key where the entity identifier is the partition key and a time attribute is the sort key. Therefore, using user ID as the partition key groups all events for a given user together, and using timestamp as the sort key allows efficient retrieval in chronological order and supports range queries (for example, “activities in the last 7 days” or “between two dates”).
This design also helps maximize provisioned throughput efficiency and reduce throttling risk because it distributes data across partitions based on the partition key values (user IDs). With many users, writes and reads naturally spread across multiple partition key values rather than concentrating on a small set. The sort key further enables multiple activity records per user without overwriting items and supports precise queries without scanning.
Option B (product ID as partition key) does not align with the stated marketing need (per-user activity). It would cluster all users’ actions for a popular product into the same partition key, increasing the chance of hot partitions and throttling.
Option C also risks hot partitions for popular product IDs; auto scaling helps capacity management but does not fix poor key distribution or hot-key access patterns.
Option D (monotonic counter as partition key) is particularly problematic: sequential keys can create uneven distribution and a throughput bottleneck pattern, and it does not support user-centric queries efficiently.
Thus, A best matches the data model (user events over time), supports efficient queries, and reduces throttling risk by distributing workload across user IDs.
Question #95
A developer is setting up a deployment pipeline. The pipeline includes an AWS CodeBuild build stage that requires access to a database to run integration tests. The developer is using a buildspec.yml file to configure the database connection. Company policy requires automatic rotation of all database credentials.
Which solution will handle the database credentials MOST securely?
- A . Retrieve the credentials from variables that are hardcoded in the buildspec.yml file. Configure an AWS Lambda function to rotate the credentials.
- B . Retrieve the credentials from an environment variable that is linked to a SecureString parameter in AWS Systems Manager Parameter Store. Configure Parameter Store for automatic rotation.
- C . Retrieve the credentials from an environment variable that is linked to an AWS Secrets Manager secret. Configure Secrets Manager for automatic rotation.
- D . Retrieve the credentials from an environment variable that contains the connection string in plaintext. Configure an Amazon EventBridge event to rotate the credentials.
Correct Answer: C
C
Explanation:
The most secure way to handle database credentials for a CodeBuild stage―especially with a company requirement for automatic rotation―is to store credentials in AWS Secrets Manager and reference the secret securely from the CodeBuild environment. Secrets Manager is purpose-built to store, retrieve, and rotate secrets such as database credentials, API keys, and tokens. It encrypts secrets at rest (using AWS KMS), supports fine-grained IAM access control, and integrates with services like CodeBuild through environment variables and runtime retrieval.
With CodeBuild, the developer can configure environment variables to reference a Secrets Manager secret (rather than embedding credentials in buildspec.yml). This ensures that the build process retrieves the latest rotated credentials at runtime, reducing exposure risk and eliminating manual credential updates.
Option B is weaker because Systems Manager Parameter Store (SecureString) is a secure storage mechanism, but automatic rotation is not a native Parameter Store feature in the same way it is in Secrets Manager for database credentials. Secrets Manager provides managed rotation workflows (often via Lambda rotation functions) and scheduling that directly matches the requirement.
Options A and D violate secure handling practices by hardcoding credentials or storing plaintext connection strings. Both approaches significantly increase risk of exposure through source control, build logs, or environment inspection. Additionally, bolting on rotation via Lambda or EventBridge does not address the primary weakness of hardcoded/plaintext secret distribution.
Therefore, AWS Secrets Manager with automatic rotation, referenced securely from CodeBuild environment variables, is the most secure solution.
C
Explanation:
The most secure way to handle database credentials for a CodeBuild stage―especially with a company requirement for automatic rotation―is to store credentials in AWS Secrets Manager and reference the secret securely from the CodeBuild environment. Secrets Manager is purpose-built to store, retrieve, and rotate secrets such as database credentials, API keys, and tokens. It encrypts secrets at rest (using AWS KMS), supports fine-grained IAM access control, and integrates with services like CodeBuild through environment variables and runtime retrieval.
With CodeBuild, the developer can configure environment variables to reference a Secrets Manager secret (rather than embedding credentials in buildspec.yml). This ensures that the build process retrieves the latest rotated credentials at runtime, reducing exposure risk and eliminating manual credential updates.
Option B is weaker because Systems Manager Parameter Store (SecureString) is a secure storage mechanism, but automatic rotation is not a native Parameter Store feature in the same way it is in Secrets Manager for database credentials. Secrets Manager provides managed rotation workflows (often via Lambda rotation functions) and scheduling that directly matches the requirement.
Options A and D violate secure handling practices by hardcoding credentials or storing plaintext connection strings. Both approaches significantly increase risk of exposure through source control, build logs, or environment inspection. Additionally, bolting on rotation via Lambda or EventBridge does not address the primary weakness of hardcoded/plaintext secret distribution.
Therefore, AWS Secrets Manager with automatic rotation, referenced securely from CodeBuild environment variables, is the most secure solution.
Question #96
A social media application is experiencing high volumes of new user requests after a recent marketing campaign. The application is served by an Amazon RDS for MySQL instance. A solutions architect examines the database performance and notices high CPU usage and many "too many connections" errors that lead to failed requests on the database. The solutions architect needs to address the failed requests.
Which solution will meet this requirement?
- A . Deploy an Amazon DynamoDB Accelerator (DAX) cluster. Configure the application to use the DAX cluster.
- B . Deploy an RDS Proxy. Configure the application to use the RDS Proxy.
- C . Migrate the database to an Amazon RDS for PostgreSQL instance.
- D . Deploy an Amazon ElastiCache (Redis OSS) cluster. Configure the application to use the ElastiCache cluster.
Correct Answer: B
B
Explanation:
Why Option B is Correct: RDS Proxy manages database connections efficiently, reducing overhead on the RDS instance and mitigating "too many connections" errors.
Why Other Options are Incorrect:
Option A: DAX is for DynamoDB, not RDS.
Option C: Migration to PostgreSQL does not address the current issue.
Option D: ElastiCache is useful for caching but does not solve connection pool issues.
AWS Documentation
Reference: Amazon RDS Proxy
B
Explanation:
Why Option B is Correct: RDS Proxy manages database connections efficiently, reducing overhead on the RDS instance and mitigating "too many connections" errors.
Why Other Options are Incorrect:
Option A: DAX is for DynamoDB, not RDS.
Option C: Migration to PostgreSQL does not address the current issue.
Option D: ElastiCache is useful for caching but does not solve connection pool issues.
AWS Documentation
Reference: Amazon RDS Proxy
Question #97
A software company is migrating a single-page application from on-premises servers to the AWS Cloud by using AWS Amplify Hosting. The application relies on an API that was created with an existing GraphQL schema. The company needs to migrate the API along with the application.
Which solution will meet this requirement with the LEAST amount of configuration?
- A . Create a new API by using the Amplify CLI’s amplify import api command. Select REST as the service to use. Add the existing schema to the new API.
- B . Create a new API in Amazon API Gateway by using the existing schema. Use the Amplify CLI’s amplify add api command. Select the API as the application’s backend environment.
- C . Create a new API in AWS AppSync by using the existing schema. Use the Amplify CLI’s amplify import api command. Select the API as the application’s backend environment.
- D . Create a new API by using the Amplify CLI’s amplify add api command. Select GraphQL as the service to use. Add the existing schema to the new API.
Correct Answer: D
D
Explanation:
AWS Amplify’s most direct support for GraphQL APIs is through AWS AppSync, and the Amplify CLI can generate and configure an AppSync GraphQL API directly from a schema with minimal setup. The requirement says the API already has an existing GraphQL schema, and the goal is to migrate it with the least configuration effort.
Option D is the simplest: run amplify add api, choose GraphQL, and provide the existing schema. Amplify then provisions the AppSync API, sets up the schema, creates the backend resources (depending on chosen data sources), and wires the configuration into the Amplify project so the SPA can consume the API.
Option A is incorrect because it selects REST and does not align with an existing GraphQL schema.
Option B is incorrect because API Gateway is not the native GraphQL service and would require additional mapping/proxy logic―more configuration.
Option C can be valid if an AppSync API already exists and you want to import it, but the question asks to “migrate the API along with the application” with least configuration. Creating it directly in Amplify is typically less configuration than creating separately and importing.
Therefore, using Amplify CLI to add a GraphQL API and supply the existing schema is the least-config approach.
D
Explanation:
AWS Amplify’s most direct support for GraphQL APIs is through AWS AppSync, and the Amplify CLI can generate and configure an AppSync GraphQL API directly from a schema with minimal setup. The requirement says the API already has an existing GraphQL schema, and the goal is to migrate it with the least configuration effort.
Option D is the simplest: run amplify add api, choose GraphQL, and provide the existing schema. Amplify then provisions the AppSync API, sets up the schema, creates the backend resources (depending on chosen data sources), and wires the configuration into the Amplify project so the SPA can consume the API.
Option A is incorrect because it selects REST and does not align with an existing GraphQL schema.
Option B is incorrect because API Gateway is not the native GraphQL service and would require additional mapping/proxy logic―more configuration.
Option C can be valid if an AppSync API already exists and you want to import it, but the question asks to “migrate the API along with the application” with least configuration. Creating it directly in Amplify is typically less configuration than creating separately and importing.
Therefore, using Amplify CLI to add a GraphQL API and supply the existing schema is the least-config approach.
Question #98
An application that runs on AWS receives messages from an Amazon Simple Queue Service (Amazon SQS) queue and processes the messages in batches. The application sends the data to another SQS queue to be consumed by another legacy application. The legacy system can take up to 5 minutes to process some transaction data.
A developer wants to ensure that there are no out-of-order updates in the legacy system. The developer cannot alter the behavior of the legacy system.
Which solution will meet these requirements?
- A . Use an SQS FIFO queue. Configure the visibility timeout value.
- B . Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the DelaySeconds values.
- C . Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the visibility timeout value.
- D . Use an SQS FIFO queue. Configure the DelaySeconds value.
Correct Answer: A
A
Explanation:
An SQS FIFO queue is a type of queue that preserves the order of messages and ensures that each message is delivered and processed only once1. This is suitable for the scenario where the developer wants to ensure that there are no out-of-order updates in the legacy system.
The visibility timeout value is the amount of time that a message is invisible in the queue after a consumer receives it2. This prevents other consumers from processing the same message simultaneously. If the consumer does not delete the message before the visibility timeout expires, the message becomes visible again and another consumer can receive it2.
In this scenario, the developer needs to configure the visibility timeout value to be longer than the maximum processing time of the legacy system, which is 5 minutes. This will ensure that the message remains invisible in the queue until the legacy system finishes processing it and deletes it. This will prevent duplicate or out-of-order processing of messages by the legacy system.
A
Explanation:
An SQS FIFO queue is a type of queue that preserves the order of messages and ensures that each message is delivered and processed only once1. This is suitable for the scenario where the developer wants to ensure that there are no out-of-order updates in the legacy system.
The visibility timeout value is the amount of time that a message is invisible in the queue after a consumer receives it2. This prevents other consumers from processing the same message simultaneously. If the consumer does not delete the message before the visibility timeout expires, the message becomes visible again and another consumer can receive it2.
In this scenario, the developer needs to configure the visibility timeout value to be longer than the maximum processing time of the legacy system, which is 5 minutes. This will ensure that the message remains invisible in the queue until the legacy system finishes processing it and deletes it. This will prevent duplicate or out-of-order processing of messages by the legacy system.
Question #99
An ecommerce startup is preparing for an annual sales event. As the traffic to the company’s application increases, the development team wants to be notified when the Amazon EC2 instance’s CPU utilization exceeds 80%.
Which solution will meet this requirement?
- A . Create a custom Amazon CloudWatch alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
- B . Create a custom AWS CloudTrail alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
- C . Create a cron job on the EC2 instance that invokes the –describe-instance-information command on the host instance every 15 minutes and sends the results to an Amazon SNS topic.
- D . Create an AWS Lambda function that queries the AWS CloudTrail logs for the CPUUtilization metric every 15 minutes and sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
Correct Answer: A
A
Explanation:
Step-by-Step Breakdown:
Requirement Summary:
Get notified when EC2 CPU Utilization > 80%
Option A: CloudWatch Alarm with SNS
Correct and standard AWS practice
CloudWatch automatically collects EC2 metrics, including CPUUtilization.
You can set a CloudWatch Alarm with a threshold (80% in this case).
Then, trigger an SNS notification to email, SMS, Lambda, etc.
Option B: AWS CloudTrail alarm
Incorrect: CloudTrail logs API activity, not performance metrics.
It doesn’t track metrics like CPU utilization.
Option C: Cron job on EC2 running –describe-instance-information
Incorrect: This doesn’t give CPU usage.
Also inefficient, and polling is bad practice when CloudWatch already monitors this natively.
Option D: Lambda function querying CloudTrail for CPU usage
Incorrect and conceptually flawed.
CloudTrail does not store performance metrics; CloudWatch does.
CloudWatch Alarms for EC2:
https: //docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
EC2 Metrics in CloudWatch:
https: //docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
Amazon SNS Notification Setup: https: //docs.aws.amazon.com/sns/latest/dg/sns-email-notifications.html
A
Explanation:
Step-by-Step Breakdown:
Requirement Summary:
Get notified when EC2 CPU Utilization > 80%
Option A: CloudWatch Alarm with SNS
Correct and standard AWS practice
CloudWatch automatically collects EC2 metrics, including CPUUtilization.
You can set a CloudWatch Alarm with a threshold (80% in this case).
Then, trigger an SNS notification to email, SMS, Lambda, etc.
Option B: AWS CloudTrail alarm
Incorrect: CloudTrail logs API activity, not performance metrics.
It doesn’t track metrics like CPU utilization.
Option C: Cron job on EC2 running –describe-instance-information
Incorrect: This doesn’t give CPU usage.
Also inefficient, and polling is bad practice when CloudWatch already monitors this natively.
Option D: Lambda function querying CloudTrail for CPU usage
Incorrect and conceptually flawed.
CloudTrail does not store performance metrics; CloudWatch does.
CloudWatch Alarms for EC2:
https: //docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html
EC2 Metrics in CloudWatch:
https: //docs.aws.amazon.com/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
Amazon SNS Notification Setup: https: //docs.aws.amazon.com/sns/latest/dg/sns-email-notifications.html
Question #100
A developer created several AWS Lambda functions that write data to a single Amazon S3 bucket.
The developer configured all the Lambda functions to send logs and metrics to Amazon CloudWatch.
The developer receives reports that one of the Lambda functions writes data to the bucket very
slowly. The developer needs to measure the latency between the problematic Lambda function and the S3 bucket.
Which solution will meet this requirement?
- A . Enable AWS X-Ray on the Lambda function. In the generated trace map. select the line between Lambda and Amazon S3.
- B . Query the Lambda function’s log file in Amazon CloudWatch Logs Insights. Return the average of the auto-discovered ©duration field.
- C . Enable CloudWatch Lambda Insights on the function. View the latency graph that CloudWatch Lambda Insights provides.
- D . Enable AWS X-Ray on the Lambda function. Select Amazon S3 in the latency graph to view the latency histogram.
Correct Answer: A