All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is writing an application that must encrypt a $250\text{ KB}$ application configuration file client-side before uploading it to an Amazon S3 bucket. The security policy requires using envelope encryption with an AWS KMS Customer Managed Key (CMK).

Which of the following workflows should the developer implement to meet these requirements?

Call the KMS GenerateDataKey API to obtain a plaintext data key and an encrypted data key. Use the plaintext data key to encrypt the file locally, destroy the plaintext key from memory, and upload the encrypted file along with the encrypted data key to Amazon S3.

Call the KMS Encrypt API directly, passing the configuration file's plaintext bytes and the CMK ID to receive the ciphertext, and then upload the ciphertext to Amazon S3.

Call the KMS GenerateDataKeyWithoutPlaintext API to receive an encrypted data key. Call the KMS Decrypt API with the encrypted data key to retrieve the plaintext data key, encrypt the file locally, and upload both the encrypted file and the encrypted data key to Amazon S3.

Store the configuration file content in AWS Systems Manager Parameter Store as a SecureString parameter referencing the CMK, and configure the application to retrieve it directly using the Parameter Store API.

Show answer & explanation

Answer: Call the KMS GenerateDataKey API to obtain a plaintext data key and an encrypted data key. Use the plaintext data key to encrypt the file locally, destroy the plaintext key from memory, and upload the encrypted file along with the encrypted data key to Amazon S3.

Answer

The correct workflow is to call the KMS GenerateDataKey API to retrieve both the plaintext and encrypted data keys. The plaintext key is used to encrypt the

250\text{ KB}

file client-side, after which it is deleted from memory. The encrypted data key is stored alongside the encrypted file in Amazon S3 for future decryption.

Step-by-Step Solution

Generate a unique data key using the Customer Managed Key (CMK) via the AWS KMS GenerateDataKey API.

AWS KMS returns a plaintext data key and a ciphertext data key encrypted by the CMK.

This establishes the cryptographic key material needed for client-side envelope encryption without passing the large file payload over the network to KMS.

Encrypt the

250\text{ KB}

configuration file locally using the plaintext data key and a symmetric algorithm (e.g., AES-256), then securely delete the plaintext data key from memory.

The file is encrypted into ciphertext, and the plaintext data key is no longer in local memory.

Encrypting locally handles the large file size which exceeds the KMS direct encryption limit of

4\text{ KB}

, and clearing the plaintext key reduces memory exposure risk.

Upload the encrypted configuration file and the ciphertext data key to the Amazon S3 bucket.

Both the encrypted file and the encrypted data key are stored in S3.

Storing the encrypted data key alongside the encrypted file ensures the application can later retrieve the encrypted key and request KMS to decrypt it when reading the file.

Key Concept

AWS KMS Envelope Encryption Workflow

Estimated Time:1m 30s

Question 1182Question →

A developer is deploying a microservice to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. The microservice needs to connect to an Amazon Aurora MySQL database. The database credentials must be rotated automatically every 30 days to comply with organizational security policies. The developer needs to implement a solution that retrieves these credentials securely without hardcoding them or causing application downtime during rotation.

Which two actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Store the database credentials in AWS Secrets Manager and enable automatic rotation using the built-in rotation function for Amazon RDS.

Associate an IAM policy that allows the secretsmanager:GetSecretValue action to the ECS Task Role, and retrieve the credentials dynamically using the AWS SDK in the application code.

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString parameter, and configure a custom AWS Lambda function to rotate the parameter value.

Attach an IAM policy that allows the secretsmanager:GetSecretValue action to the ECS Task Execution Role, and retrieve the credentials dynamically using the AWS SDK in the application code.

Hardcode the database connection string containing the password inside the application code, and initialize the database client directly using these credentials.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and enable automatic rotation using the built-in rotation function for Amazon RDS.; Associate an IAM policy that allows the secretsmanager:GetSecretValue action to the ECS Task Role, and retrieve the credentials dynamically using the AWS SDK in the application code.

Answer

Store the database credentials in AWS Secrets Manager with automatic RDS rotation enabled, and retrieve the credentials dynamically using the AWS SDK in the application code with permissions granted by the ECS Task Role.

To securely manage and rotate database credentials without causing downtime, the credentials should be stored in AWS Secrets Manager. Secrets Manager offers native integration with Amazon RDS to rotate secrets automatically. To access the secret from the container, the application code must query Secrets Manager using the AWS SDK, which requires assigning permissions to the ECS Task Role. Since rotation happens every 30 days, retrieving the credentials dynamically ensures that the application always uses the most current password without requiring task restarts.

Step-by-Step Solution

Choose the correct secrets storage service.

AWS Secrets Manager is selected because the database credentials require automatic rotation and direct RDS integration, which are features native to Secrets Manager and not natively supported by Systems Manager Parameter Store.

This satisfies the security requirement for automatic 30-day rotation without complex custom Lambda logic.

Configure the application to retrieve credentials dynamically.

The application code is configured to use the AWS SDK to retrieve the database credentials from Secrets Manager at runtime rather than injecting them via environment variables at startup.

This prevents application downtime and stale credentials when rotation occurs.

Assign the appropriate IAM role and policy to the ECS container.

An IAM policy granting the secretsmanager:GetSecretValue permission is attached to the ECS Task Role.

The ECS Task Role is the identity assumed by the application code running inside the container to make AWS SDK calls.

Key Concept

AWS Secrets Manager vs Systems Manager Parameter Store, and ECS Task Roles vs Task Execution Roles.

Question 1183Question →

A developer is troubleshooting an application running on Amazon ECS (using AWS Fargate) in AWS Account A. The application needs to retrieve objects from an Amazon S3 bucket in AWS Account B. The S3 objects are encrypted using a Customer Managed Key (CMK) in AWS Key Management Service (AWS KMS) located in Account B. The ECS Task Role in Account A has been configured with an identity-based policy that allows both s3:GetObject on the bucket and kms:Decrypt on the KMS CMK. However, when the containerized application runs, it receives an Access Denied error. Which two configuration changes must the developer make in Account B to resolve this authorization failure?

Select all that apply

Update the S3 bucket policy in Account B to grant s3:GetObject permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Update the KMS key policy in Account B to grant kms:Decrypt permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Update the S3 bucket policy and KMS key policy in Account B to grant permissions to the Amazon Resource Name (ARN) of the ECS Task Execution Role from Account A.

Modify the ECS Task Role's trust policy in Account A to trust the S3 service principal (s3.amazonaws.com) and the KMS service principal (kms.amazonaws.com).

Update the application code to initialize the AWS SDK client using static credentials of a newly created IAM User in Account B that has full access to S3 and KMS.

Show answer & explanation

Answer: Update the S3 bucket policy in Account B to grant s3:GetObject permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.; Update the KMS key policy in Account B to grant kms:Decrypt permissions to the Amazon Resource Name (ARN) of the ECS Task Role from Account A.

Answer

To resolve the authorization failure, the developer must update the S3 bucket policy in Account B to grant s3:GetObject permissions to the ECS Task Role ARN from Account A, and update the KMS key policy in Account B to grant kms:Decrypt permissions to the ECS Task Role ARN from Account A.

For cross-account access to resource-based services that support encryption (like S3 and KMS), permissions must be configured in both the identity-based policy (the ECS Task Role in Account A) and the resource-based policies (the S3 bucket policy and the KMS key policy in Account B). Since the identity-based policies are already in place, the developer must update both resource policies in Account B to trust the ECS Task Role.

Step-by-Step Solution

Configure cross-account S3 access in Account B.

The S3 bucket policy in Account B is updated to allow the principal ARN matching the ECS Task Role in Account A.

For cross-account access, permissions must be granted on both the identity (ECS Task Role) and the resource (S3 bucket policy).

Configure cross-account KMS key access in Account B.

The KMS key policy in Account B is updated to allow the ECS Task Role from Account A to perform the kms:Decrypt operation.

AWS KMS requires that the key policy itself explicitly trust the external IAM identity; identity-based policies in the external account are insufficient by themselves.

Key Concept

Cross-account authorization requires explicit permissions on both the identity-based policy in the source account and the resource-based policies (bucket policy and KMS key policy) in the destination account.

Estimated Time:2m 0s

Question 1184Question →

A developer is updating a web application running on an AWS Elastic Beanstalk environment. The application is highly sensitive to customer-facing bugs, so the developer wants to test the new version using a small percentage of real production traffic ( $10\%$ ) for a duration of $15$ minutes. If the new version triggers any Amazon CloudWatch alarms during this time, the traffic must immediately route back to the old version. If no alarms are triggered, the remaining $90\%$ of traffic should automatically shift to the new version. Which deployment policy should the developer configure in the Elastic Beanstalk environment?

All at once

Traffic splitting

Immutable

Rolling with additional batch

Show answer & explanation

Answer: Traffic splitting

Answer

Traffic splitting

Traffic splitting is the correct answer because it is the only native AWS Elastic Beanstalk deployment policy that allows developers to perform canary testing. It launches a temporary Auto Scaling group with the new version, routes a specified percentage of traffic (e.g.,

10\%

) to it for a set evaluation period (e.g.,

15

minutes), monitors health using CloudWatch alarms, and automatically rolls back if alarms are triggered, or promotes the deployment to 100\% traffic if successful.

Step-by-Step Solution

Analyze the requirement to route a small fraction (

10\%

) of live production traffic to a new version of the application for validation.

Identify that this represents a canary deployment pattern, which requires splitting load balancer traffic between the existing environment and a new deployment.

This rules out standard rolling, rolling with additional batch, and immutable deployment policies, which update instances without fractional traffic routing.

Evaluate the rollback and promotion criteria (

15

minutes of evaluation using CloudWatch alarms, followed by automatic promotion or rollback).

Determine that the deployment policy must natively support CloudWatch alarm monitoring and automated rollback/promotion based on health status.

Traffic Splitting in Elastic Beanstalk allows configuring a specific evaluation time (e.g.,

15

minutes) and linking CloudWatch alarms to trigger a rollback.

Select the Elastic Beanstalk deployment policy that matches these constraints.

The Traffic Splitting policy is chosen as it is the only native Elastic Beanstalk policy designed specifically for percentage-based traffic shifting and automatic CloudWatch-based rollbacks.

Other policies like Immutable and Rolling with additional batch do not support fractional traffic splitting.

Key Concept

AWS Elastic Beanstalk Traffic Splitting Deployment Policy

Question 1185Question →

An order processing system publishes JSON-formatted logs to Amazon CloudWatch Logs. The logs contain a top-level key named `status`. A representative log event is:

{
"orderId": "1001",
"status": "Failed",
"code": 500
}

Which filter pattern should be applied to the log group to capture these specific events?

{ $.status = "Failed" }

$.status = "Failed"

[status = "Failed"]

{ status == "Failed" }

Show answer & explanation

Answer: { $.status = "Failed" }

Answer

The correct filter pattern is `{ $.status = "Failed" }`.

The correct pattern is `{

.status = "Failed" }` because structured JSON logs in CloudWatch Logs must be queried with patterns enclosed in curly braces. Within the braces, the root object is represented by `

`, followed by the key name (e.g., `$.status`), and a single equals sign `=` is used for string or numeric value comparison.

Step-by-Step Solution

Identify the log format

The log event is structured in JSON format.

JSON logs require different metric filter syntax rules compared to space-delimited text logs.

Determine the root selector and curly braces rule

CloudWatch JSON log filters must be enclosed in curly braces `{}` and refer to the root document using `$`.

Without braces and the root selector, CloudWatch cannot parse the JSON path correctly.

Determine the comparison operator

A single equals sign `=` is used for equality comparison.

CloudWatch Metric Filter syntax specifies `=` as the equality operator for string or numeric matching.

Key Concept

CloudWatch Logs Metric Filter JSON Syntax

Question 1186Question →

A developer is deploying a containerized application on Amazon ECS using the AWS Fargate launch type. The application is designed to poll an Amazon SQS queue and process incoming messages. The task definition uses the awslogs log driver to send container logs to Amazon CloudWatch Logs. During deployment, the task fails to launch, and the AWS Management Console displays the following error:

ResourceInitializationError: unable to pull secrets or registry auth: execution role does not have permissions to pull from ECR

The developer verifies that two IAM roles are associated with the task definition: ApplicationTaskExecutionRole and ApplicationTaskRole.

Which action must the developer take to resolve the container startup failure and ensure the application can poll the SQS queue once running?

Attach a policy allowing ecr:GetDownloadUrlForLayer and ecr:BatchGetImage to the ApplicationTaskExecutionRole, and attach a policy allowing sqs:ReceiveMessage and sqs:DeleteMessage to the ApplicationTaskRole.

Attach a policy allowing ecr:GetDownloadUrlForLayer and ecr:BatchGetImage to the ApplicationTaskRole, and attach a policy allowing sqs:ReceiveMessage and sqs:DeleteMessage to the ApplicationTaskExecutionRole.

Attach a policy containing ECR, SQS, and CloudWatch permissions to the ApplicationTaskExecutionRole, and configure the ApplicationTaskRole trust policy to allow it to assume the ApplicationTaskExecutionRole.

Attach a policy allowing ecr:GetDownloadUrlForLayer and sqs:ReceiveMessage to the ApplicationTaskExecutionRole, and leave the ApplicationTaskRole unconfigured since Fargate tasks run in a shared security context.

Show answer & explanation

Answer: Attach a policy allowing ecr:GetDownloadUrlForLayer and ecr:BatchGetImage to the ApplicationTaskExecutionRole, and attach a policy allowing sqs:ReceiveMessage and sqs:DeleteMessage to the ApplicationTaskRole.

Answer

Attach ECR pull permissions to the ApplicationTaskExecutionRole, and attach SQS permissions to the ApplicationTaskRole.

The Task Execution Role is utilized by the ECS container agent to perform actions on behalf of the task before the container starts, such as pulling the image from Amazon ECR and writing logs to CloudWatch. The Task Role is assumed by the application running inside the container to make AWS SDK calls, such as polling the Amazon SQS queue. Therefore, ECR permissions must be attached to the Task Execution Role, and SQS permissions must be attached to the Task Role.

Step-by-Step Solution

Analyze the error message from the ECS console.

The error shows that the ECS agent failed to pull the image from ECR due to insufficient permissions on the execution role.

The ECS Task Execution Role is responsible for task lifecycle operations managed by the ECS agent before the containerized application starts.

Identify the role needed for application-level AWS API calls.

The application container needs to poll the SQS queue at runtime, which requires SQS permissions.

The ECS Task Role is the role assumed by the containerized application at runtime to make calls to AWS services.

Determine the correct permission assignments.

Attach ecr:GetDownloadUrlForLayer and ecr:BatchGetImage to the ApplicationTaskExecutionRole, and sqs:ReceiveMessage/sqs:DeleteMessage to the ApplicationTaskRole.

This adheres to the principle of least privilege and correctly separates container execution agent credentials from runtime application credentials.

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role

Estimated Time:2m 0s

Question 1187Question →

An e-commerce backend running on AWS Lambda needs to store sensitive customer profile data in an Amazon RDS database. Due to compliance requirements, the application must encrypt the profile data client-side before sending it to the database. The size of each profile is approximately $350\text{ KB}$ .

Which of the following steps must the developer perform in the application code to implement this client-side encryption? (Select TWO)

Select all that apply

Call the KMS GenerateDataKey API using a customer managed key to obtain a plaintext data key and an encrypted data key.

Encrypt the customer profile data locally using the plaintext data key, and then delete the plaintext data key from memory.

Send the profile data directly to the KMS Encrypt API using a customer managed key.

Call the KMS GenerateDataKeyWithoutPlaintext API to obtain the plaintext data key and use it to encrypt the profile data locally.

Download the private key material of the customer managed key from AWS Systems Manager Parameter Store to encrypt the profile data locally.

Show answer & explanation

Answer: Call the KMS GenerateDataKey API using a customer managed key to obtain a plaintext data key and an encrypted data key.; Encrypt the customer profile data locally using the plaintext data key, and then delete the plaintext data key from memory.

Answer

Call the KMS GenerateDataKey API using a customer managed key to obtain a plaintext data key and an encrypted data key, and encrypt the customer profile data locally using the plaintext data key, and then delete the plaintext data key from memory.

For payloads larger than 4 KB, such as a 350 KB customer profile, developers must use envelope encryption. This involves calling the KMS GenerateDataKey API to obtain both a plaintext data key and an encrypted data key. The plaintext key is used to encrypt the data locally in the application, and is then immediately deleted from memory for security. The encrypted data key is stored alongside the encrypted data.

Step-by-Step Solution

Evaluate payload size limits.

The profile data size is 350 KB. Because this exceeds the 4 KB limit of the KMS Encrypt API, client-side envelope encryption must be used.

Direct KMS encryption APIs are designed for small payloads (under 4 KB).

Generate data keys using KMS.

Invoke the KMS GenerateDataKey API, specifying the customer managed key. KMS returns a plaintext data key and an encrypted data key.

The plaintext key is required for local encryption, and the encrypted data key is saved to allow future decryption.

Perform local encryption and cleanup.

Encrypt the customer profile data locally using the plaintext data key, and then delete the plaintext data key from application memory.

Encrypting locally secures the data before database transit, and removing the plaintext key from memory protects against memory exposure.

Key Concept

AWS KMS Envelope Encryption

Estimated Time:1m 30s

Question 1188Question →

A developer is configuring an Amazon ECS service on AWS Fargate to deploy a containerized application. The Docker image is hosted in a private Amazon Elastic Container Registry (ECR) repository located in a separate, central AWS account. The Fargate tasks will run in a private subnet within the developer's AWS account. Which configuration is required to allow the ECS service to successfully pull the container image and deploy the application?

Configure the ECS Task Role in the developer's account with permissions to call ecr:GetAuthorizationToken and pull the image. Update the central ECR repository policy to allow access to the developer's ECS Task Role ARN, and configure VPC endpoints for ECR and Amazon S3.

Modify the ECS Task Execution Role's trust policy to trust the central AWS account ID. Configure the central ECR repository to assume this role when retrieving images, and configure VPC endpoints for ECR and Amazon S3.

Configure the ECS Task Execution Role in the developer's account with permissions to call ecr:GetAuthorizationToken and pull the image. Update the central ECR repository policy to allow access to the developer's ECS Task Execution Role ARN, and configure VPC endpoints for ECR and Amazon S3.

Hardcode the central account's IAM user credentials in the task definition's container environment variables to authenticate the container registry pull, and configure VPC endpoints for ECR and Amazon S3.

Show answer & explanation

Answer: Configure the ECS Task Execution Role in the developer's account with permissions to call ecr:GetAuthorizationToken and pull the image. Update the central ECR repository policy to allow access to the developer's ECS Task Execution Role ARN, and configure VPC endpoints for ECR and Amazon S3.

Answer

Configure the ECS Task Execution Role in the developer's account with permissions to call ECR APIs and pull the image, update the central ECR repository policy to trust this role, and establish VPC endpoints for ECR and Amazon S3.

The correct configuration uses the ECS Task Execution Role because the ECS container agent is responsible for pulling the image and authenticating with Amazon ECR. Since the ECR repository is in another account, the repository policy in that central account must trust the Task Execution Role ARN from the developer's account. Finally, because the Fargate task runs in a private subnet, VPC endpoints for ECR and S3 (or a NAT Gateway) are required for the ECS agent to communicate with ECR.

Step-by-Step Solution

Determine which role is responsible for pulling container images in ECS.

The ECS Task Execution Role is identified as the role used by the ECS container agent to perform lifecycle tasks such as pulling images and writing logs, whereas the ECS Task Role provides permissions to the application code itself.

This establishes that permissions must be attached to the Task Execution Role rather than the Task Role.

Configure permissions for cross-account ECR access.

The ECS Task Execution Role in the developer's account is granted ECR read permissions, and the ECR repository policy in the central account is updated to allow the developer's Task Execution Role ARN to perform ecr actions.

This allows the ECS agent to authenticate and pull the image across AWS accounts.

Ensure network connectivity to ECR and S3 from the private subnet.

VPC endpoints for ECR and S3 are created in the developer's VPC.

Because the Fargate tasks run in a private subnet, they require private endpoints to communicate with ECR and download the container image layers stored in S3.

Key Concept

Distinction between ECS Task Role and Task Execution Role in cross-account ECR deployments

Question 1189Question →

A developer has deployed a React-based inventory management portal hosted on a static website on AWS Amplify. The portal needs to send `PATCH` requests to an Amazon API Gateway REST API that integrates with a backend AWS Lambda function using a Lambda Proxy integration.

When the portal attempts to invoke the endpoint, the browser console displays a CORS preflight block error. Additionally, when testing the API directly using a CLI tool, the response returns a `502 Bad Gateway` error. The Lambda function execution logs show that the function completes successfully, but it returns a serialized JSON string containing only the inventory data.

Which two actions should the developer take to resolve these issues? (Select two.)

Select all that apply

Configure the OPTIONS method in API Gateway to return the appropriate CORS headers for the preflight request.

Modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers', ensuring 'Access-Control-Allow-Origin' is included in the headers.

Add the 'Access-Control-Allow-Origin' header to the response headers of the static website hosting configuration in AWS Amplify.

Change the integration type to Lambda Custom integration and format the Lambda function's return payload as a raw plain-text string.

Implement a Lambda Authorizer that inspects the 'Origin' header and returns an IAM policy allowing the 'execute-api:Invoke' action for the domain.

Show answer & explanation

Answer: Configure the OPTIONS method in API Gateway to return the appropriate CORS headers for the preflight request.; Modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers', ensuring 'Access-Control-Allow-Origin' is included in the headers.

Answer

To resolve these errors, the developer must configure the OPTIONS method in API Gateway to handle the preflight request and modify the backend Lambda function to return a structured JSON object containing 'statusCode', 'body', and 'headers' (including the 'Access-Control-Allow-Origin' header).

For CORS to work with a Lambda Proxy integration, the browser must receive the appropriate CORS headers for both the preflight OPTIONS request and the actual request. Configuring the OPTIONS method in API Gateway ensures that preflight requests are answered with the correct CORS headers. For the actual request, because a Lambda Proxy integration is used, the backend Lambda function is responsible for returning the response payload in a structured JSON format containing 'statusCode', 'body', and 'headers', with the 'Access-Control-Allow-Origin' header explicitly set inside the headers map. This resolves both the preflight CORS block and the 502 Bad Gateway integration error.

Step-by-Step Solution

Configure the OPTIONS method in API Gateway.

The browser successfully receives CORS headers during the preflight OPTIONS request, allowing it to proceed with the actual cross-origin request.

Before sending non-simple HTTP requests (such as PATCH), browsers send a preflight OPTIONS request to verify CORS permissions.

Modify the Lambda function response format.

The Lambda function returns a valid JSON object matching the proxy integration structure, containing 'statusCode', 'body', and 'headers'.

Lambda Proxy integrations require a strict response payload format; failing to provide this schema causes API Gateway to return a 502 Bad Gateway error.

Include the Access-Control-Allow-Origin header in the Lambda function's response headers.

The browser receives the Access-Control-Allow-Origin header with the actual PATCH response, satisfying the CORS policy constraint.

Under Lambda Proxy integrations, API Gateway does not automatically inject CORS headers into integration responses, meaning the backend code must supply them.

Key Concept

Handling CORS preflight configurations and Lambda Proxy response integration requirements in Amazon API Gateway.

Estimated Time:2m 30s

Question 1190Question →

A developer is troubleshooting a serverless application where an Amazon SQS queue triggers an AWS Lambda function to process batch invoice reports. Under normal load, the invoices are processed successfully. However, during peak hours when processing times increase, the developer notices that some invoices are generated multiple times. CloudWatch logs show that the Lambda function occasionally runs for up to $45$ seconds before completion, which is close to its configured timeout. The SQS queue's visibility timeout is currently set to $30$ seconds. Which configuration change will resolve this duplicate processing issue?

Increase the SQS queue's visibility timeout to at least

270

seconds.

Reduce the Lambda function's execution timeout to

25

seconds.

Configure a Dead-Letter Queue (DLQ) on the SQS queue with a maxReceiveCount of

1

Increase the SQS queue's visibility timeout to

50

seconds.

Show answer & explanation

Answer: Increase the SQS queue's visibility timeout to at least $270$ seconds.

Answer

Increase the SQS queue's visibility timeout to at least

270

seconds.

The correct option addresses the timeout mismatch by setting the SQS visibility timeout to

270

seconds, which satisfies the AWS best practice of maintaining the queue's visibility timeout at least

6

times the Lambda function's timeout. This prevents SQS from delivering the same message to another Lambda execution thread while the active thread is still processing the invoice.

Step-by-Step Solution

Identify the relationship between the Lambda function's timeout and the SQS queue's visibility timeout.

The Lambda function timeout is

45

seconds, but the SQS visibility timeout is only

30

seconds.

When the visibility timeout is shorter than the Lambda execution time, SQS makes the message visible to other consumers while the current Lambda execution is still running, causing duplicate processing.

Apply the AWS recommended formula for SQS-to-Lambda integration timeouts.

Visibility Timeout

\geq 6 \times

Lambda Timeout.

The safety margin of

6

times the function timeout allows Lambda to retry the function if it is throttled or returns an error while processing a previous batch.

Calculate the minimum visibility timeout required.

6 \times 45\text{ seconds} = 270\text{ seconds}

This is the minimum duration the visibility timeout should be set to prevent duplicate processing during peak hours.

Key Concept

SQS visibility timeout configuration when integrated with Lambda

Question 1191Question →

A developer is designing a data archival application that needs to encrypt database export files that are approximately $45\text{ MB}$ in size before uploading them to an Amazon S3 bucket. The security policy requires client-side envelope encryption using an AWS KMS customer managed key.

Which of the following application workflows satisfies these requirements with the minimum number of AWS KMS API requests?

Call the KMS GenerateDataKey API to obtain a plaintext data key and an encrypted copy of the data key. Encrypt the database export file using the plaintext data key, discard the plaintext data key from memory, and upload the encrypted file along with the encrypted data key to S3.

Call the KMS Encrypt API directly, passing the database export file as the plaintext payload, and upload the resulting ciphertext to S3.

Call the KMS GenerateDataKeyWithoutPlaintext API to obtain the encrypted data key. Call the KMS Decrypt API to retrieve the plaintext data key, encrypt the file, and upload the encrypted file along with the encrypted data key to S3.

Create a secure string parameter in Systems Manager Parameter Store containing a static symmetric key, retrieve it using the GetParameter API, encrypt the file client-side, and upload the encrypted file to S3.

Show answer & explanation

Answer: Call the KMS GenerateDataKey API to obtain a plaintext data key and an encrypted copy of the data key. Encrypt the database export file using the plaintext data key, discard the plaintext data key from memory, and upload the encrypted file along with the encrypted data key to S3.

Answer

The correct workflow involves calling the KMS GenerateDataKey API, which returns both the plaintext data key and the encrypted data key in a single API call. The plaintext key is used to encrypt the

45\text{ MB}

file client-side, and then it is immediately discarded from memory for security. The encrypted data key is uploaded to Amazon S3 alongside the encrypted file so that authorized users can decrypt it later by calling the KMS Decrypt API.

Step-by-Step Solution

Determine the file size constraint and the appropriate encryption method.

Since the database export file is

45\text{ MB}

, it exceeds the

4\text{ KB}

limit of the KMS Encrypt API, requiring client-side envelope encryption.

KMS has direct payload limits, meaning large files must be encrypted locally using a symmetric data key generated by KMS.

Select the KMS API call that generates both the plaintext and encrypted keys in one request.

GenerateDataKey returns both the plaintext key and the ciphertext key in a single API call.

This minimizes the number of KMS API calls compared to calling GenerateDataKeyWithoutPlaintext followed by Decrypt.

Define the client-side encryption and storage workflow.

Encrypt the file with the plaintext key, delete the plaintext key from memory, and upload the encrypted file and encrypted key together.

This ensures the plaintext key is not exposed after encryption, and the encrypted key is available for future decryption operations.

Key Concept

AWS KMS Envelope Encryption Workflow and API Selection

Estimated Time:1m 30s

Question 1192Question →

An AWS Lambda function written in Node.js queries an Amazon DynamoDB table using the AWS SDK for JavaScript (v3). The function's configuration has active tracing enabled. However, when viewing traces in the AWS X-Ray console, only the Lambda service and function segments are displayed, while the downstream queries to DynamoDB are completely missing. What action must be taken to ensure that these DynamoDB queries are recorded as part of the traces?

Rely on the active tracing setting of the Lambda function to automatically intercept and trace all downstream AWS SDK calls without changing the application code

Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK

Initialize the DynamoDB client by passing hardcoded IAM credentials into the client constructor to authorize tracing requests to the X-Ray daemon

Increase the Lambda function's timeout configuration to allow the execution context to remain active longer, giving the background processes more time to flush traces

Show answer & explanation

Answer: Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK

Answer

Wrap the DynamoDB client instance in the Lambda function code using the captureAWSv3Client function from the AWS X-Ray SDK.

The correct action is to wrap the DynamoDB client using captureAWSv3Client from the AWS X-Ray SDK. Active tracing on AWS Lambda provides tracing for the environment and runtime execution but does not automatically capture downstream requests made by client libraries. To record queries made with the AWS SDK for JavaScript (v3), the client instance must be wrapped explicitly.

Step-by-Step Solution

Identify the cause of the missing downstream DynamoDB traces.

The AWS SDK client is not instrumented to forward context to AWS X-Ray.

Although active tracing is enabled on the Lambda function itself, this only covers the environment and the function execution. It does not automatically hook into internal SDK clients.

Select the correct SDK instrumentation method for AWS SDK for JavaScript (v3).

Use the captureAWSv3Client utility from the AWS X-Ray SDK.

In SDK v3, tracing requires wrapping the specific client instances (like the DynamoDB client) with the X-Ray library to construct downstream subsegments.

Key Concept

Instrumenting AWS SDK clients with AWS X-Ray SDK in AWS Lambda

Question 1193Question →

A developer has installed and configured the Unified CloudWatch Agent on a fleet of Amazon EC2 instances to stream application logs to Amazon CloudWatch Logs. However, after starting the agent, the developer notices that no log groups or log streams are being created in the CloudWatch console.

Which TWO actions should the developer take to troubleshoot and resolve this issue?

Select all that apply

Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy.

Check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

Verify that the Metric Filter patterns associated with the target log group match the format of the incoming logs.

Ensure that the application Nginx service execution timeout is configured to match the CloudWatch log streaming visibility window.

Modify the IAM trust policy of the EC2 instance role to allow the logs.amazonaws.com service principal to assume the role.

Show answer & explanation

Answer: Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy.; Check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

Answer

Verify that the IAM role attached to the EC2 instances contains the permissions from the CloudWatchAgentServerPolicy AWS-managed policy, and check the CloudWatch agent log file on the EC2 instances for configuration errors or AWS API credential issues.

The correct steps to troubleshoot missing logs in CloudWatch when using the Unified CloudWatch Agent are verifying the IAM permissions of the EC2 instance (which must include permissions to publish logs) and checking the agent's local log file for errors. The CloudWatchAgentServerPolicy contains the required permissions, and the local agent log file provides diagnostic details.

Step-by-Step Solution

Identify the service permissions required for the agent to publish logs.

Confirm that the EC2 instance must be allowed to perform logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents, which are provided by the CloudWatchAgentServerPolicy.

Without these permissions, the agent cannot write logs to CloudWatch.

Locate and review the agent's local logs on the host operating system.

Check the local log file for permission denied errors or configuration errors.

Local agent logs are the primary diagnostic source when logs fail to publish to AWS.

Key Concept

CloudWatch Logs Ingestion and Troubleshooting

Question 1194Question →

A developer is writing an AWS CloudFormation template to deploy a web application on an Amazon EC2 instance. The application requires a database password that needs automatic rotation, as well as several software packages. The developer wants to ensure that any updates to the software configuration in the template are automatically applied to the instance without replacing it.

Which two actions should the developer take to meet these requirements?

Select all that apply

Define the software configuration in the AWS::CloudFormation::Init resource metadata, run cfn-init in the UserData property to perform the initial installation, and configure the cfn-hup daemon to monitor changes.

Use a dynamic reference in the CloudFormation template to retrieve the database password from AWS Secrets Manager.

Store the database password in Systems Manager Parameter Store and retrieve it via a dynamic reference, utilizing its native scheduled parameter rotation features.

Install the packages by writing custom scripts in the EC2 UserData property, and instruct administrators to manually update the instance via SSH when template configurations change.

Execute the cfn-init script with the --rollback flag in UserData to monitor the stack status and roll back configuration files if a stack update enters the ROLLBACK_IN_PROGRESS state.

Show answer & explanation

Answer: Define the software configuration in the AWS::CloudFormation::Init resource metadata, run cfn-init in the UserData property to perform the initial installation, and configure the cfn-hup daemon to monitor changes.; Use a dynamic reference in the CloudFormation template to retrieve the database password from AWS Secrets Manager.

Answer

Use the AWS::CloudFormation::Init resource metadata along with the cfn-init script and cfn-hup daemon to install and update software configurations, and use AWS Secrets Manager with dynamic references to securely store and automatically rotate the database password.

The correct options involve configuring the software installation using the CloudFormation metadata framework (AWS::CloudFormation::Init, cfn-init, and cfn-hup) to detect and apply updates automatically, and using AWS Secrets Manager to retrieve rotated database passwords dynamically.

Step-by-Step Solution

Select the appropriate storage for secret parameters that require rotation.

Identify AWS Secrets Manager as the solution because it supports automatic rotation of credentials, unlike Systems Manager Parameter Store.

Ensures the database password is secure and complies with security requirements for rotation.

Select the mechanism for applying and updating EC2 packages without recreating the instance.

Combine AWS::CloudFormation::Init, the cfn-init helper script in UserData, and the cfn-hup daemon running on the instance.

This configuration allows the instance to pull metadata changes and apply updates dynamically.

Key Concept

AWS CloudFormation helper scripts and dynamic references for secret management.

Question 1195Question →

An application deployed in an Amazon ECS container on AWS Fargate uses the awslogs log driver to stream stdout logs to an Amazon CloudWatch Logs log group. The application outputs logs in JSON format, but the container's logging framework prepends a plaintext timestamp to each log line, resulting in log events formatted as follows:

`2026-07-14T12:00:00Z {"level": "ERROR", "response": {"status_code": 504, "error": "Gateway Timeout"}}`

The developer created a CloudWatch Metric Filter with the pattern `{ $.response.status_code = 504 }` to monitor these errors, but the metric is not registering any data. Which two actions should the developer take to resolve this issue and ensure the metrics are accurately captured?

Select all that apply

Configure the application's logging framework to output raw JSON without prepended plaintext.

Update the metric filter pattern to use a space-delimited text pattern, such as `[timestamp, json_payload = *status_code": 504*]`.

Modify the metric filter pattern to `$.response.status_code = 504` without curly braces.

Migrate the application to AWS Lambda and implement a try-catch block inside the handler code to intercept execution timeouts and log a custom 504 error payload.

Add logs:PutLogEvents permissions to the ECS Task Role to authorize the metric filter to publish metrics to CloudWatch.

Show answer & explanation

Answer: Configure the application's logging framework to output raw JSON without prepended plaintext.; Update the metric filter pattern to use a space-delimited text pattern, such as `[timestamp, json_payload = *status_code": 504*]`.

Answer

Configure the application's logging framework to output raw JSON without prepended plaintext, or update the metric filter pattern to use a space-delimited text pattern.

The correct options target the underlying parsing failure: either by rendering the log events as valid JSON so the JSON metric filter pattern can function, or by using a space-delimited pattern to extract the JSON substring and match the status code within it.

Step-by-Step Solution

Analyze why the JSON metric filter pattern is failing to match the log events.

The log event is prepended with a plaintext timestamp, which invalidates the JSON structure of the log event and prevents CloudWatch Logs from parsing it as valid JSON.

CloudWatch Logs JSON metric filters only work on log events that are valid JSON objects from the very first character.

Identify the first valid solution: modify the log format produced by the application.

Removing the prepended plaintext timestamp makes the entire log event a valid JSON object starting with curly braces.

This allows the existing JSON metric filter pattern to parse and match the JSON fields correctly.

Identify the second valid solution: adjust the metric filter pattern to match the actual log format without modifying the application configuration.

Using a space-delimited filter pattern successfully parses the timestamp and matches the JSON string payload.

This maps the log event fields to position-based tokens, where the first token is the timestamp and the second is the JSON payload containing the targeted status code.

Key Concept

CloudWatch Logs Metric Filters require strict syntax matching: JSON filters require valid JSON log events enclosed in curly braces, while mixed or non-JSON logs must be parsed using space-delimited filter patterns.

Question 1196Question →

A developer is designing a serverless e-commerce application that must manage highly dynamic user shopping carts and preferences. The session data must be retrieved with low latency ( $< 10\text{ ms}$ ), must scale automatically to handle millions of concurrent users, and must be automatically deleted after $30\text{ minutes}$ of user inactivity.

Which TWO strategies should the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Store the session data in an Amazon DynamoDB table and enable Time to Live (TTL) on a timestamp attribute.

Store the session data in an Amazon ElastiCache for Redis cluster and use the Redis EXPIRE command to set a TTL on the session keys.

Store the session data in the global execution context of the application's AWS Lambda functions to cache it in memory between invocations.

Store the session data in an Amazon DynamoDB table and retrieve active sessions using Scan operations filtered by session state.

Store the session data in AWS Systems Manager Parameter Store and configure AWS Secrets Manager to automatically rotate the sessions.

Show answer & explanation

Answer: Store the session data in an Amazon DynamoDB table and enable Time to Live (TTL) on a timestamp attribute.; Store the session data in an Amazon ElastiCache for Redis cluster and use the Redis EXPIRE command to set a TTL on the session keys.

Answer

Store the session data in an Amazon DynamoDB table with Time to Live (TTL) enabled, or store the session data in an Amazon ElastiCache for Redis cluster using the EXPIRE command to automatically expire keys.

Storing session data in Amazon DynamoDB with TTL and storing session data in Amazon ElastiCache for Redis using the EXPIRE command are correct because both offer the required low latency, high scalability, and support automatic expiration of data after a period of inactivity. DynamoDB TTL deletes items automatically based on a timestamp, and Redis EXPIRE deletes keys after a specified number of seconds.

Step-by-Step Solution

Analyze the requirements for session storage.

The application requires low latency, automatic scaling to support high traffic, and auto-expiration after 30 minutes of inactivity.

To narrow down candidate AWS services that support key-value lookups, high throughput, and automatic TTL-based cleanup.

Evaluate DynamoDB with TTL.

DynamoDB scales automatically, offers low latency, and automatically deletes expired items when TTL is enabled on an attribute.

To confirm that DynamoDB TTL satisfies all design constraints.

Evaluate ElastiCache for Redis with EXPIRE.

Redis is an in-memory database providing sub-millisecond latency and supports setting key expirations natively via the EXPIRE command.

To confirm that ElastiCache for Redis satisfies all design constraints.

Key Concept

Implementing session state management with automatic TTL-based cleanup in highly scalable databases and in-memory caches.

Question 1197Question →

A high-traffic API is hosted on an AWS Elastic Beanstalk environment. The development team is preparing to deploy a major update. The deployment must satisfy the following operational requirements:

* The system must maintain at least its baseline capacity at all times to prevent performance degradation.
* A fast rollback mechanism must be available to restore the previous version within minutes if post-deployment health checks or alarms fail.
* The update must be contained within the existing environment without provisioning a separate, duplicate Elastic Beanstalk environment or performing a CNAME swap.

Which TWO of the following deployment strategies should the developer select to satisfy these requirements? (Select TWO.)

Select all that apply

Immutable deployment

Traffic splitting deployment

Rolling deployment

Rolling with additional batch deployment

Blue/green deployment

Show answer & explanation

Answer: Immutable deployment; Traffic splitting deployment

Answer

Immutable deployment and Traffic splitting deployment are the correct strategies.

Immutable deployment and Traffic splitting deployment both launch a temporary Auto Scaling group to deploy the new application version alongside the existing instances. This maintains

100\%

of the baseline capacity during deployment. If the deployment fails (e.g., health checks fail or CloudWatch alarms trigger), Elastic Beanstalk can perform a fast rollback by immediately terminating the temporary instances and routing all traffic back to the original instances, without requiring external DNS changes or CNAME swaps.

Step-by-Step Solution

Analyze the capacity requirement.

Since baseline capacity must be maintained at

100\%

at all times, strategies like Rolling and All-at-once, which take existing instances out of service, are eliminated.

This leaves Immutable, Traffic splitting, Rolling with additional batch, and Blue/green as candidates.

Analyze the environment boundary constraint.

The requirement states that the update must be contained within the existing environment without a CNAME swap.

This eliminates Blue/green deployment, which requires creating a separate Elastic Beanstalk environment and performing a CNAME swap.

Analyze the rollback speed requirement.

Rolling with additional batch requires a full redeployment of the previous version to rollback, which is slow. Immutable and Traffic splitting deploy to a temporary Auto Scaling group, enabling rapid rollback by terminating the new instances and reverting routing.

This identifies Immutable and Traffic splitting as the only two strategies that meet all requirements.

Key Concept

AWS Elastic Beanstalk Deployment Strategies

Question 1198Question →

A developer has a Node.js application deployed in Docker containers on Amazon ECS. The application writes data to an Amazon DynamoDB table using the AWS SDK for JavaScript (v3) and calls an external payment processing API over HTTPS using the Node.js native https module. The developer has deployed the AWS X-Ray daemon container as a sidecar in the ECS task definition and verified that the daemon is running and receiving data. However, the X-Ray console only shows the container node without any downstream nodes for DynamoDB or the payment API.

Which two actions should the developer take to ensure that both the DynamoDB calls and the external HTTPS API calls are instrumented and visible in the X-Ray service map?

Select all that apply

Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK.

Call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

Hardcode the AWS access key and secret access key in the X-Ray SDK configuration using AWS.config.update().

Configure the API Gateway integration type as a custom integration rather than a proxy integration to pass X-Ray headers.

Increase the visibility timeout of the SQS queue that processes the messages to allow the X-Ray daemon more time to flush its buffer.

Show answer & explanation

Answer: Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK.; Call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

Answer

Instrument the DynamoDB client using the captureAWSv3Client function from the AWS X-Ray SDK, and call the captureHTTPsGlobal function from the AWS X-Ray SDK to automatically trace downstream HTTPS calls.

To achieve distributed tracing in Node.js applications, the AWS SDK client must be instrumented explicitly (via captureAWSv3Client for SDK v3), and native HTTP/HTTPS modules must be wrapped (via captureHTTPsGlobal) to capture downstream third-party service calls.

Step-by-Step Solution

Identify the AWS SDK instrumentation method for JavaScript SDK v3.

Determine that wrapping the DynamoDB client with the captureAWSv3Client function from the AWS X-Ray SDK enables tracing for DynamoDB calls.

By default, the SDK clients are not instrumented and their requests are not sent to the X-Ray daemon.

Identify the HTTP/HTTPS tracing method for external API calls in Node.js.

Determine that invoking captureHTTPsGlobal at the entry point of the application instruments the native HTTP/HTTPS modules.

This allows the X-Ray SDK to intercept and record downstream HTTP/HTTPS requests to the payment API.

Key Concept

To trace downstream calls in AWS X-Ray, developers must instrument both the AWS SDK clients and any HTTP/HTTPS clients using the language-specific AWS X-Ray SDK.

Question 1199Question →

An organization's deployment pipeline fails during a step that executes an AWS CloudFormation stack template. The pipeline is configured to update a stack that has a status of ROLLBACK_COMPLETE following a failed initial creation attempt. Which actions should a developer take to resolve this issue and enable a successful deployment? (Choose two.)

Select all that apply

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state.

Resolve the underlying resource configuration issue that caused the initial creation failure.

Initiate a stack update operation using the corrected template directly on the existing stack.

Add the cloudformation:UpdateStack permission to the trust policy of the IAM service role.

Run a drift detection operation on the stack and import the failed resources to force the state to UPDATE_COMPLETE.

Show answer & explanation

Answer: Delete the CloudFormation stack in the ROLLBACK_COMPLETE state.; Resolve the underlying resource configuration issue that caused the initial creation failure.

Answer

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state and resolve the underlying resource configuration issue that caused the initial creation failure.

To resolve a failed initial deployment that resulted in a ROLLBACK_COMPLETE state, the developer must delete the stack and fix the root cause of the failure. CloudFormation does not allow updates to stacks that failed their initial creation (ROLLBACK_COMPLETE). Once the stack is deleted and the template/environment issues are resolved, the pipeline can successfully trigger a new stack creation.

Step-by-Step Solution

Analyze the CloudFormation event logs to identify the resource and reason that caused the initial creation failure.

The root cause of the deployment failure is understood.

Understanding why the initial deployment failed is necessary to correct the template or parameters.

Delete the failed stack that is in the ROLLBACK_COMPLETE state.

The stack name is freed up, and the failed stack is removed.

Stacks that fail initial creation reach ROLLBACK_COMPLETE and cannot be updated. They must be deleted before a new stack can be created.

Fix the template or environment issues and trigger the CI/CD pipeline to redeploy.

A new stack is successfully created.

Running the pipeline with the corrected configuration creates a fresh stack without hitting the previous errors.

Key Concept

Managing CloudFormation stack states and resolving failed initial creations in a CI/CD pipeline.

Question 1200Question →

A developer is deploying a containerized application to Amazon Elastic Kubernetes Service (Amazon EKS). The application requires access to a database password for an Amazon RDS DB instance and an API key for a third-party service. The database password must be rotated every 30 days. The third-party API key changes infrequently, and the developer wants to access it with minimum latency and cost. Which combination of steps should the developer take to retrieve these configurations securely and cost-effectively? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager and configure automatic rotation using an AWS Lambda function.

Store the third-party API key as a SecureString parameter in AWS Systems Manager Parameter Store and retrieve it via the application.

Store the database password in Systems Manager Parameter Store and enable native Parameter Store automatic rotation.

Store the third-party API key in AWS Secrets Manager to leverage its built-in rotation and access rate capabilities.

Hardcode the database password and the API key directly into the Kubernetes deployment manifest file as environment variables.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and configure automatic rotation using an AWS Lambda function.; Store the third-party API key as a SecureString parameter in AWS Systems Manager Parameter Store and retrieve it via the application.

Answer

Store the database password in AWS Secrets Manager with Lambda rotation, and store the third-party API key as a SecureString parameter in AWS Systems Manager Parameter Store.

The correct combination involves storing the database password in AWS Secrets Manager because it natively supports automatic rotation via Lambda, and storing the third-party API key in AWS Systems Manager Parameter Store as a SecureString parameter because standard parameters are free and ideal for infrequently changing secrets.

Step-by-Step Solution

Analyze requirements for the database password.

The database password requires automatic rotation every 30 days. AWS Secrets Manager natively supports automatic rotation (using an AWS Lambda function) and is the correct choice.

Parameter Store does not support automated secret rotation natively.

Analyze requirements for the third-party API key.

The API key changes infrequently, does not require automated rotation, and must be accessed with minimal cost. AWS Systems Manager Parameter Store (specifically standard SecureString parameters) is free of charge and provides low latency.

Using Secrets Manager for this key would incur unnecessary monthly fees.

Key Concept

Selecting between AWS Secrets Manager and Systems Manager Parameter Store based on rotation, cost, and lifecycle requirements.

PreviousPage 60 / 78Next

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