All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is designing a containerized microservice that runs on Amazon ECS. The microservice must store sensitive customer data in an Amazon DynamoDB table. Due to compliance requirements, the data must be encrypted client-side before it is sent to DynamoDB. The developer wants to use envelope encryption with an AWS KMS customer managed key to minimize KMS API calls and encrypt the data efficiently. Which two API operations must the developer implement in the microservice code to manage the keys for this client-side encryption and decryption workflow? (Select TWO.)

Select all that apply

kms:GenerateDataKey

kms:Decrypt

kms:GenerateDataKeyWithoutPlaintext

kms:Encrypt

ssm:GetParameter

Show answer & explanation

Answer: kms:GenerateDataKey; kms:Decrypt

Answer

The correct answer consists of the operations kms:GenerateDataKey and kms:Decrypt.

The correct operations are kms:GenerateDataKey and kms:Decrypt. In envelope encryption, the application calls kms:GenerateDataKey to obtain a plaintext data key (to encrypt the payload locally) and a ciphertext data key (to store alongside the encrypted payload). To decrypt the data, the application calls kms:Decrypt with the ciphertext data key to retrieve the plaintext data key, which is then used to decrypt the payload locally.

Step-by-Step Solution

Analyze the requirement for client-side envelope encryption and decryption of DynamoDB items using a customer managed key.

Identify that the application needs to dynamically generate a unique symmetric data key for each item, encrypt the payload locally, store the encrypted key with the item, and retrieve the plaintext key for decryption later.

This establishes the workflow where the KMS customer managed key is only used to protect the data keys, not the database payloads directly.

Determine the API operation required for the encryption phase.

Identify kms:GenerateDataKey as the API call that provides the plaintext key for immediate local encryption and the ciphertext key for storage.

Using kms:GenerateDataKeyWithoutPlaintext would require an additional round-trip to decrypt the key, and kms:Encrypt violates envelope encryption by sending the payload itself to KMS.

Determine the API operation required for the decryption phase.

Identify kms:Decrypt as the API call used to decrypt the stored ciphertext data key back to its plaintext form.

The microservice retrieves the ciphertext key from the DynamoDB item and must call kms:Decrypt before it can decrypt the customer data locally.

Key Concept

Envelope encryption workflow with AWS KMS

Estimated Time:1m 30s

Question 222Question →

A developer is configuring an AWS CodeBuild project that runs integration tests. These tests require credentials to access an Amazon RDS PostgreSQL database. The database credentials must be rotated automatically every $30$ days. How should the developer store and retrieve these credentials to meet the requirements with the least operational overhead?

Store the credentials in AWS Systems Manager Parameter Store as a SecureString parameter, and configure a custom AWS Lambda function triggered by an Amazon EventBridge scheduled rule to handle rotation.

Store the credentials in AWS Secrets Manager, configure automatic rotation using the built-in AWS Lambda rotation template for Amazon RDS, and reference the secret in the CodeBuild project's buildspec file.

Store the credentials in AWS Systems Manager Parameter Store as a String parameter, and enable Parameter Store's native database rotation integration to update the credentials every

30

days.

Store the credentials as plaintext environment variables in the AWS CodeBuild project configuration, and run a custom CLI script during the pre_build phase to update the credentials.

Show answer & explanation

Answer: Store the credentials in AWS Secrets Manager, configure automatic rotation using the built-in AWS Lambda rotation template for Amazon RDS, and reference the secret in the CodeBuild project's buildspec file.

Answer

Storing the credentials in AWS Secrets Manager is the correct approach. Secrets Manager provides native integration with Amazon RDS, allowing automatic credential rotation using built-in Lambda templates without writing custom code. CodeBuild can securely fetch these credentials dynamically during the build run by referencing them in the buildspec file.

Step-by-Step Solution

Evaluate the requirement for automatic rotation of database credentials every

30

days.

Identify that AWS Secrets Manager provides native, out-of-the-box support for rotating Amazon RDS credentials using built-in AWS Lambda templates.

Using native features minimizes custom code and operational overhead compared to manual or custom-coded solutions.

Compare Secrets Manager and Systems Manager Parameter Store for credential rotation.

Acknowledge that Parameter Store (even with SecureString parameters) lacks built-in automatic rotation templates for RDS, requiring custom Lambda functions and EventBridge rules.

This step eliminates options proposing Parameter Store due to the higher operational overhead requirement.

Integrate the secret retrieval into the AWS CodeBuild pipeline.

Reference the secret using Secrets Manager syntax in the buildspec file of the CodeBuild project.

This ensures the build environment retrieves the latest rotated credentials securely at runtime without exposing them in configuration logs or plaintext variables.

Key Concept

AWS Secrets Manager built-in rotation vs Systems Manager Parameter Store capabilities

Question 223Question →

A client-side SvelteKit dashboard application hosted on `https://admin.service.internal` sends a `DELETE` request to an Amazon API Gateway REST API. The request fails, and the browser console displays a CORS preflight error indicating that the `Access-Control-Allow-Origin` header is missing. The REST API is configured with a Lambda Proxy Integration and a custom Lambda Authorizer on the `DELETE` method. The developer has already used the API Gateway Console to enable CORS on the resource, which created an `OPTIONS` method. Which two actions must the developer take to resolve this issue?

Select all that apply

Configure the OPTIONS method on the resource to use NONE for its Authorization type in API Gateway, then redeploy the API.

Update the backend Lambda function mapped to the DELETE method to include the Access-Control-Allow-Origin header in the headers object of the returned JSON payload.

Configure an Integration Response in the API Gateway Console for the DELETE method to map the Access-Control-Allow-Origin header to the client's origin.

Modify the custom Lambda Authorizer code to validate the authorization header and return an Allow policy for the OPTIONS method.

Modify the CORS configuration on the S3 bucket where the SvelteKit application is hosted to permit DELETE methods from API Gateway.

Show answer & explanation

Answer: Configure the OPTIONS method on the resource to use NONE for its Authorization type in API Gateway, then redeploy the API.; Update the backend Lambda function mapped to the DELETE method to include the Access-Control-Allow-Origin header in the headers object of the returned JSON payload.

Answer

To resolve the CORS preflight block, the developer must set the Authorization type of the OPTIONS method to NONE in the API Gateway Console, and modify the backend Lambda function for the DELETE method to return the Access-Control-Allow-Origin header in its response headers.

CORS preflight (OPTIONS) requests are initiated by the browser to determine whether the target server permits the cross-origin request. Because these preflight requests lack credentials, they cannot pass authorizers. Consequently, the OPTIONS method must have its Authorization set to NONE. Furthermore, under a Lambda Proxy Integration, API Gateway relies entirely on the backend payload structure to formulate the HTTP response. The developer must return the Access-Control-Allow-Origin header directly from the backend Lambda function to satisfy browser security validations during the subsequent DELETE request.

Step-by-Step Solution

Disable authorization on the preflight method.

Change the Authorization setting for the preflight OPTIONS method to NONE in the API Gateway Console and redeploy the API. This permits browser preflight checks to pass without requiring authorization tokens.

Browsers perform CORS preflight checks using OPTIONS requests, which do not include authorization credentials.

Inject CORS headers into the backend Lambda response.

Modify the Lambda function handling the DELETE method to return 'Access-Control-Allow-Origin': 'https://admin.service.internal' (or '*') in the headers object of the response payload.

When using Lambda Proxy Integration, API Gateway bypasses console integration response headers, meaning the backend code must supply the required CORS headers directly.

Key Concept

Handling CORS preflight authorization and header injection in API Gateway Lambda Proxy integrations.

Estimated Time:3m 0s

Question 224Question →

A health tracking application named FitPulse records real-time heart rate data from millions of user devices. The application writes telemetry records directly to an Amazon DynamoDB table configured with provisioned write capacity. The table uses `DeviceType` (with values such as `Watch`, `Band`, or `Ring`) as the partition key and `Timestamp` as the sort key. During a global fitness event, write activity surges, and the application receives a high volume of `ProvisionedThroughputExceededException` errors. CloudWatch metrics show that the total consumed Write Capacity Units (WCUs) are well below the table's total provisioned WCU limit. Which of the following is the most effective solution to resolve this throttling issue and ensure even write distribution across the partitions?

Modify the application to retrieve records using parallel Scan operations on the DynamoDB table to bypass partition throughput limits.

Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.

Increase the visibility timeout of the Amazon SQS queue that buffers incoming writes to

12

hours to allow the DynamoDB table more time to process the backlog.

Hardcode the IAM User's access key and secret access key in the application's SDK client initialization code to reduce credential retrieval latency during write surges.

Show answer & explanation

Answer: Redesign the partition key schema to use a high-cardinality attribute such as `DeviceId` and, if write volumes for a single device are extremely high, append a random or calculated numeric suffix to the partition key.

Answer

Redesigning the partition key schema to use a high-cardinality attribute distributes the database write load across many partitions. In Amazon DynamoDB, provisioned capacity is distributed across physical partitions. If a low-cardinality attribute like `DeviceType` is used as the partition key, all writes for a given device type will target the same partition, causing a hot partition that exceeds the per-partition limit (

1000

WCUs) even if the table-level provisioned capacity is not fully consumed. Appending a random or calculated numeric suffix to the partition key (write sharding) further distributes writes across multiple partitions when a single entity's write rate exceeds the per-partition limit.

Step-by-Step Solution

Analyze the CloudWatch metrics showing that total consumed throughput is below the table's total provisioned limits while `ProvisionedThroughputExceededException` errors are occurring.

Identify that the issue is a hot partition rather than an overall table capacity exhaustion.

Provisioned capacity in DynamoDB is divided across physical partitions, meaning a single partition can exceed its individual limit (

1000

WCUs or

3000

RCUs) even if the table-wide threshold is not breached.

Evaluate the primary key design (`DeviceType` as partition key and `Timestamp` as sort key).

Recognize that `DeviceType` has low cardinality (few distinct values like `Watch`, `Band`, or `Ring`), causing heavy write volumes to target only a few partitions.

Low-cardinality keys lead to uneven data distribution and partition overloading.

Redesign the schema to use a high-cardinality attribute like `DeviceId` as the partition key, and apply write sharding if necessary.

Ensure even key distribution across DynamoDB's physical partitions.

Using a high-cardinality key like `DeviceId` combined with a random or calculated suffix spreads the write requests uniformly across all physical partitions, resolving the hot partition throttling.

Key Concept

Resolving DynamoDB partition throttling by designing a high-cardinality partition key schema to avoid hot partitions.

Estimated Time:2m 0s

Question 225Question →

A developer is configuring a machine learning pipeline in Amazon SageMaker. The pipeline needs to retrieve a personal access token (PAT) to pull training code from a private Git repository. This PAT must be rotated monthly and accessed by pipelines running across multiple AWS accounts in the same organization. Additionally, the pipeline needs to retrieve non-sensitive training hyperparameters (such as learning rate and batch size) that are only used within the local AWS account. How should the developer store these values to meet the requirements securely and cost-effectively?

Store the private Git repository token in AWS Secrets Manager and attach a resource-based policy to the secret to allow cross-account access. Store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Store the private Git repository token as a SecureString parameter in AWS Systems Manager Parameter Store and attach a resource-based policy to the parameter to allow cross-account access. Store the hyperparameters in AWS Secrets Manager.

Hardcode the private Git repository token directly in the SageMaker pipeline's script, and store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Store both the private Git repository token and the hyperparameters in AWS Secrets Manager, enabling automatic rotation for both to centralize secret management.

Show answer & explanation

Answer: Store the private Git repository token in AWS Secrets Manager and attach a resource-based policy to the secret to allow cross-account access. Store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Answer

The correct answer correctly identifies that AWS Secrets Manager should be used for the private Git repository token because it natively supports resource-based policies for cross-account sharing and automatic rotation. It also correctly identifies that Systems Manager Parameter Store is the most cost-effective service for storing non-sensitive hyperparameters, avoiding unnecessary Secrets Manager costs.

Step-by-Step Solution

Analyze the requirements for the private Git repository token.

Identify that the token is sensitive, needs automatic monthly rotation, and requires cross-account access.

This determines the best security service to use based on features like resource-based policies and rotation.

Analyze the requirements for the hyperparameters.

Identify that the hyperparameters are non-sensitive configuration data, do not require rotation, and are only accessed locally.

This helps select the most cost-effective storage option for non-sensitive configurations.

Compare AWS Secrets Manager and Systems Manager Parameter Store features and cost.

AWS Secrets Manager is selected for the token because it supports resource-based policies for cross-account access and automatic rotation. Systems Manager Parameter Store is selected for the hyperparameters because standard parameters are free and suitable for non-sensitive data.

Ensures the solution is both secure and optimized for cost.

Key Concept

Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on rotation, cross-account access, and cost-efficiency.

Estimated Time:1m 30s

Question 226Question →

A developer is setting up an in-place deployment of a web application to Amazon EC2 instances using AWS CodeDeploy. The application revision bundle is stored in a private Amazon S3 bucket. During the deployment, the process fails during the DownloadBundle lifecycle event with an Access Denied error. Which action should the developer take to resolve this failure?

Grant s3:GetObject permissions for the S3 bucket to the CodeDeploy service role associated with the deployment group.

Define a validation script under the BeforeAllowTraffic lifecycle hook in the appspec.yml file to manually pull the bundle from S3.

Attach an IAM role that grants s3:GetObject permissions for the S3 bucket to the IAM instance profile of the EC2 instances.

Store the S3 bucket credentials in Systems Manager Parameter Store and write a script in the BeforeInstall hook to retrieve them to download the bundle.

Show answer & explanation

Answer: Attach an IAM role that grants s3:GetObject permissions for the S3 bucket to the IAM instance profile of the EC2 instances.

Answer

Attach an IAM role that grants s3:GetObject permissions for the S3 bucket to the IAM instance profile of the EC2 instances.

The correct answer is to attach an IAM role with S3 read permissions to the EC2 instances' instance profile. In AWS CodeDeploy, the CodeDeploy agent runs directly on the EC2 instances. During the DownloadBundle deployment lifecycle event, this agent pulls the application revision bundle from Amazon S3. To authorize this request, the agent utilizes the permissions from the instance profile attached to the EC2 instance, not the CodeDeploy service role.

Step-by-Step Solution

Identify which component is downloading the application revision.

The CodeDeploy agent running locally on the Amazon EC2 instances downloads the application revision bundle from the specified Amazon S3 bucket.

Understanding which entity performs the action helps determine which IAM identity needs the permission.

Determine the credential source for the CodeDeploy agent.

The CodeDeploy agent uses the permissions attached to the EC2 instance's IAM instance profile.

Since the agent runs on the instance, it relies on the EC2 instance profile to authenticate and authorize its requests to other AWS services like Amazon S3.

Grant the minimum required S3 permission to the EC2 instance profile.

Add an IAM policy granting s3:GetObject permissions for the target S3 bucket to the role associated with the EC2 instance profile.

This allows the agent to fetch the bundle successfully during the DownloadBundle event.

Key Concept

CodeDeploy Agent Credentials and EC2 Instance Profiles

Question 227Question →

An AWS Lambda function in Account A ( $111122223333$ ) is configured to download files from an Amazon S3 bucket located in Account B ( $444455556666$ ). The S3 bucket is encrypted using an AWS KMS customer managed key also located in Account B. The Lambda function's IAM execution role in Account A has an identity-based policy that grants permission for the `s3:GetObject` and `kms:Decrypt` actions. When the Lambda function runs, it fails to retrieve objects and receives an Access Denied error. Which two actions must be taken in Account B to resolve this authorization failure?

Select all that apply

Modify the Amazon S3 bucket policy in Account B to grant the `s3:GetObject` permission to the Lambda execution role in Account A.

Modify the AWS KMS key policy in Account B to grant the `kms:Decrypt` permission to the Lambda execution role in Account A.

Update the trust policy of the Lambda execution role in Account A to trust the `kms.amazonaws.com` service principal.

Configure the Lambda function to use an Amazon Cognito Identity Pool to retrieve temporary credentials to access the AWS KMS key.

Hardcode temporary access credentials generated from Account B directly in the Lambda function's initialization code.

Show answer & explanation

Answer: Modify the Amazon S3 bucket policy in Account B to grant the `s3:GetObject` permission to the Lambda execution role in Account A.; Modify the AWS KMS key policy in Account B to grant the `kms:Decrypt` permission to the Lambda execution role in Account A.

Answer

To resolve the authorization failure, the S3 bucket policy in Account B must be updated to grant the Lambda execution role `s3:GetObject` permissions, and the KMS key policy in Account B must be updated to grant the Lambda execution role `kms:Decrypt` permissions.

For cross-account resource access where KMS encryption is involved, the target resource policies must grant access. Specifically, the S3 bucket policy in Account B must permit `s3:GetObject` to the Lambda execution role in Account A. Additionally, because the S3 object is encrypted with a customer managed KMS key in Account B, the KMS key policy in Account B must explicitly permit the `kms:Decrypt` action for the external Lambda role. Local IAM policies in Account A cannot grant access to external KMS keys without the key policy delegating that permission.

Step-by-Step Solution

Examine the S3 cross-account access requirements.

For cross-account access to Amazon S3, both the identity-based policy in the source account (Account A) and the resource-based bucket policy in the destination account (Account B) must explicitly allow the operation.

Since the resource is in a different account, AWS evaluates both policies to determine authorization.

Examine the KMS cross-account access requirements.

For cross-account access to a customer managed KMS key, the KMS key policy in the owning account (Account B) must explicitly grant permission to the external account or IAM principal.

Unlike same-account KMS access where the key policy can delegate authorization to IAM policies, cross-account access requires explicit permission in the key policy itself.

Key Concept

Cross-account authorization requires resource-based policies (S3 bucket policy and KMS key policy) in the target account to explicitly trust and grant permissions to the IAM identity in the source account.

Question 228Question →

A developer is configuring a serverless application where an AWS Lambda function processes messages from an Amazon SQS queue. The function performs CPU-intensive video transcoding that takes up to $3$ minutes to complete per message. During initial testing, the Lambda function's timeout is set to the default of $15$ seconds, resulting in execution timeouts. Additionally, the developer needs to prevent messages from being received and processed multiple times by other concurrent Lambda invocations while a message is currently being processed. Which configuration changes will resolve the execution timeouts and prevent duplicate message processing?

Configure the Lambda function's timeout to

180

seconds, and set the Amazon SQS queue's visibility timeout to at least

1080

seconds.

Configure the Lambda function's timeout to

180

seconds, and set the Amazon SQS queue's visibility timeout to

30

seconds.

Configure the Lambda function's timeout to

15

seconds, and set the Amazon SQS queue's visibility timeout to

90

seconds.

Configure the Lambda function's timeout to

1080

seconds, and set the Amazon SQS queue's visibility timeout to

180

seconds.

Show answer & explanation

Answer: Configure the Lambda function's timeout to $180$ seconds, and set the Amazon SQS queue's visibility timeout to at least $1080$ seconds.

Answer

Configure the Lambda function's timeout to

180

seconds, and set the Amazon SQS queue's visibility timeout to at least

1080

seconds.

The correct configuration is to set the Lambda function's timeout to

180

seconds (to accommodate the

3

-minute processing time) and the SQS visibility timeout to at least

1080

seconds. According to AWS best practices, the visibility timeout of an SQS queue triggering a Lambda function should be configured to at least

6

times the Lambda function's timeout to prevent message processing loops and duplication due to throttling or retries.

Step-by-Step Solution

Analyze the processing time requirement of the backend task.

The video transcoding task requires up to

3

minutes (

180

seconds) to complete. The Lambda function's timeout must be set to at least

180

seconds to prevent execution failures.

If the Lambda function's timeout is shorter than the task execution time, the environment terminates the execution before completion, causing the task to fail.

Determine the required SQS queue visibility timeout configuration.

The visibility timeout of the SQS queue must be set to at least

6

times the timeout of the Lambda function, which is

6 \times 180

seconds =

1080

seconds.

AWS recommends setting the SQS visibility timeout to at least

6

times the Lambda function timeout. This provides a safety margin so that if a Lambda function is throttled or fails, the message does not immediately become visible to other consumers before the current invocation finishes or retries.

Key Concept

AWS Lambda integration with Amazon SQS and visibility timeout configuration guidelines

Estimated Time:2m 0s

Question 229Question →

A developer is migrating a Python application from an Amazon EC2 instance to an Amazon EKS cluster. The application uses the AWS SDK for Python (Boto3) to access an Amazon DynamoDB table. On the EC2 instance, the application successfully used the instance profile credentials. In the EKS cluster, the application fails to authenticate, resulting in a NoCredentialsError.

The EKS ServiceAccount has been annotated with the role ARN arn:aws:iam::123456789012:role/my-dynamodb-role, and the environment variables AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE are correctly injected into the container. However, the application code initializes the client using boto3.Session(aws_access_key_id=access_key, aws_secret_access_key=secret_key) where the keys are read from a configuration file that is not present on EKS.

Which two changes should the developer make to resolve this authentication issue and securely run the application on EKS? (Select two.)

Select all that apply

Modify the Python code to initialize the Boto3 client using the default session: boto3.client('dynamodb').

Configure the IAM role's trust policy to trust the EKS cluster's OIDC provider and allow the sts:AssumeRoleWithWebIdentity action.

Modify the IAM role's trust policy to trust the eks.amazonaws.com service principal and allow the sts:AssumeRole action.

Update the Python code to manually parse the web identity token file, call the sts:AssumeRole API, and configure static credentials in the Boto3 client constructor.

Configure AWS Systems Manager Parameter Store to store the IAM role's temporary credentials and retrieve them using the Boto3 client on application startup.

Show answer & explanation

Answer: Modify the Python code to initialize the Boto3 client using the default session: boto3.client('dynamodb').; Configure the IAM role's trust policy to trust the EKS cluster's OIDC provider and allow the sts:AssumeRoleWithWebIdentity action.

Answer

Initialize the Boto3 client using the default session (boto3.client('dynamodb')) and configure the IAM role's trust policy to trust the EKS cluster's OIDC provider using the sts:AssumeRoleWithWebIdentity action.

To successfully migrate the application to Amazon EKS using IAM Roles for Service Accounts (IRSA), two components are required. First, the application code must utilize the SDK's default credential provider chain (e.g., using default client initialization without passing static keys) so that the SDK automatically detects the environment variables injected by EKS (AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE) and retrieves temporary credentials. Second, the IAM role's trust policy must trust the EKS cluster's OIDC identity provider and allow the sts:AssumeRoleWithWebIdentity action, enabling the token to be exchanged for temporary IAM credentials.

Step-by-Step Solution

Remove explicit credential arguments from the Boto3 client initialization code.

The application code is modified from using boto3.Session(aws_access_key_id=..., aws_secret_access_key=...) to using the default constructor boto3.client('dynamodb').

This enables the AWS SDK's default credential provider chain to look for credentials in the EKS environment, specifically using the injected AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE environment variables.

Configure OIDC trust for the IAM role.

The IAM role's trust policy is updated to include the EKS OIDC identity provider URL as a trusted federated principal.

This allows EKS pods to exchange their service account tokens for temporary AWS credentials using the Security Token Service (STS).

Allow the sts:AssumeRoleWithWebIdentity action in the trust policy.

The trust policy grants permissions for the sts:AssumeRoleWithWebIdentity action to the OIDC identity provider principal.

Without this action allowed, the STS exchange will fail, causing authentication errors when the SDK tries to assume the role.

Key Concept

AWS SDK credential resolution and IAM Roles for Service Accounts (IRSA) configuration using OIDC and sts:AssumeRoleWithWebIdentity.

Question 230Question →

A developer is implementing a new backend service using an Amazon API Gateway REST API with a Lambda proxy integration. To ensure that API Gateway can successfully process the response and forward it to the client, the Lambda function must return a JSON payload with a specific structure. Which JSON payload structure must the Lambda function return to represent a successful HTTP response?

{
"isBase64Encoded": false,
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": "{\"message\": \"Success\"}"
}

{
"statusCode": 200,
"body": {
"message": "Success"
}
}

{
"httpStatus": 200,
"message": "Success"
}

{
"headers": {
"Content-Type": "application/json"
},
"body": "{\"message\": \"Success\"}"
}

Show answer & explanation

Answer:
{
"isBase64Encoded": false,
"statusCode": 200,
"headers": {
"Content-Type": "application/json"
},
"body": "{\"message\": \"Success\"}"
}

Answer

The correct JSON structure contains `isBase64Encoded`, `statusCode`, `headers`, and a stringified `body` field.

The correct payload contains a status code of

200

, headers, and a stringified JSON body. For Lambda proxy integrations, API Gateway expects a response with a numeric `statusCode`, key-value `headers` map, and a string-formatted `body` property.

Step-by-Step Solution

Analyze the integration type configured in API Gateway.

The integration type is Lambda proxy integration.

This determines whether API Gateway automatically parses the output (custom integration) or requires a strict pre-defined JSON payload structure (proxy integration).

Identify the mandatory response parameters for Lambda proxy integrations.

The backend Lambda function must return `statusCode` (integer), `headers` (map of string to string), and `body` (string).

These fields are parsed directly by API Gateway to construct the HTTP response for the client.

Verify the datatype of the `body` field.

The payload in the `body` field must be serialized as a string.

API Gateway does not parse a JSON object directly inside the `body` field; passing an object instead of a string results in a

502

Bad Gateway error.

Key Concept

Lambda Proxy Integration Response Format

Estimated Time:45s

Question 231Question →

A developer is implementing a serverless worker using an AWS Lambda function triggered by an Amazon SQS queue. During performance testing, the developer observes that messages are frequently being processed multiple times by parallel Lambda executions. The Lambda function has an execution timeout of $45$ seconds, whereas the SQS queue has a visibility timeout of $30$ seconds. Which modification will prevent the messages from being processed multiple times?

Increase the SQS queue visibility timeout to at least

270

seconds.

Increase the AWS Lambda execution timeout to

90

seconds.

Hardcode administrative AWS IAM credentials in the Lambda function's initialization code.

Associate the AWS Lambda function with a custom VPC and deploy it across private subnets without a NAT Gateway.

Show answer & explanation

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

Answer

Increase the SQS queue visibility timeout to at least

270

seconds.

Increasing the SQS queue visibility timeout to at least

270

seconds is correct because AWS recommends setting the visibility timeout of the source SQS queue to at least

6

times the execution timeout of the target Lambda function. This prevents messages from becoming visible again to other consumers while a Lambda function is still actively processing them.

Step-by-Step Solution

Identify the cause of duplicate message processing.

The current SQS visibility timeout of

30

seconds is shorter than the Lambda execution timeout of

45

seconds. SQS makes the message visible to other consumers before the active Lambda function finishes processing and deletes it.

To prevent other Lambda instances from picking up the same message, the visibility timeout must cover the maximum time the Lambda execution could take.

Calculate the recommended SQS visibility timeout.

AWS recommends setting the SQS visibility timeout to at least

6

times the Lambda function timeout. For a

45

-second Lambda timeout, this calculation is

6 \times 45 = 270

seconds.

This formula builds in a safety buffer for potential Lambda retries and execution variance.

Key Concept

SQS visibility timeout vs Lambda timeout configuration

Question 232Question →

A backend application running on Amazon EC2 instances must access an Amazon DynamoDB table using the AWS SDK. The developer needs to configure the application to retrieve temporary credentials automatically without using any long-lived credentials. Which configuration should the developer implement?

Store the access key and secret access key of an IAM user in AWS Secrets Manager, and configure the application to retrieve them at startup to initialize the SDK client.

Query the Instance Metadata Service (IMDS) endpoint directly from the application code to retrieve temporary credentials, and pass them explicitly to the SDK client constructor.

Attach an IAM role with DynamoDB permissions to the EC2 instance profile, and construct the SDK client using the default constructor without passing explicit credentials.

Create an IAM execution role, assign its ARN to the AWS_ROLE_ARN environment variable, and write application code that uses the AWS Security Token Service (STS) to assume the role at startup.

Show answer & explanation

Answer: Attach an IAM role with DynamoDB permissions to the EC2 instance profile, and construct the SDK client using the default constructor without passing explicit credentials.

Answer

Attaching an IAM role with DynamoDB permissions to the EC2 instance profile, and constructing the SDK client using the default constructor without passing explicit credentials.

Attaching an IAM role to the EC2 instance profile is the recommended best practice. The AWS SDK's default credential provider chain automatically looks for credentials provided by the EC2 Instance Metadata Service (IMDS) when no credentials are explicitly configured in the code. This completely removes the need for long-lived credentials and manages the rotation of temporary credentials automatically.

Step-by-Step Solution

Create an IAM role with a policy allowing the required DynamoDB operations and attach it to an EC2 instance profile.

An IAM role is created that can be assumed by EC2 instances to generate temporary security credentials.

This establishes authorization policies without creating long-lived IAM user keys.

Associate the instance profile with the EC2 instances hosting the application.

The application running on the instances can access the EC2 Instance Metadata Service (IMDS) to fetch temporary credentials.

This makes the temporary credentials securely accessible to the runtime environment.

Initialize the AWS SDK client in the application code using the default constructor without passing explicit access keys.

The AWS SDK automatically invokes the default credential provider chain, which searches for credentials starting from environment variables down to the instance metadata service.

Using the default credentials chain avoids hardcoding credentials and guarantees automated retrieval and rotation.

Key Concept

AWS SDK Default Credential Provider Chain and EC2 Instance Profiles

Question 233Question →

A developer is building a serverless web API using Amazon API Gateway and AWS Lambda with a Lambda Proxy integration. Which two actions must the developer take to ensure the Lambda function correctly receives client requests and returns successful responses? (Select TWO.)

Select all that apply

Format the Lambda function's return object to contain the 'statusCode', 'headers', and 'body' properties.

Access incoming request details, such as query string parameters, directly from the 'event' input parameter of the Lambda handler.

Configure API Gateway integration response mapping templates to format the JSON response structure.

Hardcode AWS IAM user credentials in the Lambda function code to authorize the integration between API Gateway and Lambda.

Deploy the Lambda function in a public VPC subnet with a public IP address to allow API Gateway to communicate with it.

Show answer & explanation

Answer: Format the Lambda function's return object to contain the 'statusCode', 'headers', and 'body' properties.; Access incoming request details, such as query string parameters, directly from the 'event' input parameter of the Lambda handler.

Answer

The developer must format the Lambda function's return object to contain the 'statusCode', 'headers', and 'body' properties, and access incoming request details, such as query string parameters, directly from the 'event' input parameter of the Lambda handler.

For Lambda Proxy integrations, the Lambda function must return a response matching the expected JSON structure containing 'statusCode', 'headers', and 'body'. Additionally, all incoming request details (such as path parameters and query strings) are accessible via the 'event' parameter passed to the Lambda handler.

Step-by-Step Solution

Analyze the integration type between API Gateway and AWS Lambda.

The scenario specifies Lambda Proxy integration, which means API Gateway passes the raw request directly to Lambda and expects a specific output format from Lambda.

This determines how inputs are read and how outputs must be structured.

Determine how input parameters are read in the Lambda function.

The input parameters like query string parameters are mapped into the 'event' argument passed to the handler.

With Lambda Proxy integration, API Gateway automatically packages request details into the 'event' parameter.

Determine how the response is constructed by the Lambda function.

The function must return a JSON object with 'statusCode', 'headers', and 'body' keys.

Without this structure, API Gateway will throw a 502 Bad Gateway error as it cannot parse the response.

Key Concept

API Gateway Lambda Proxy Integration requirements

Question 234Question →

A developer is configuring a REST API in Amazon API Gateway using a Lambda proxy integration with a backend AWS Lambda function. Which two requirements or behaviors apply to this integration type? (Select TWO.)

Select all that apply

The Lambda function response must be formatted as a JSON object with statusCode, headers, and body keys.

API Gateway passes the entire client HTTP request to the Lambda function as a structured event parameter.

The developer must configure mapping templates in API Gateway to format the request payload before it reaches the Lambda function.

The developer must configure integration response mappings in API Gateway to bind function returns to specific HTTP status codes.

The developer must configure a custom Lambda authorizer to handle user authentication via Amazon Cognito User Pools.

Show answer & explanation

Answer: The Lambda function response must be formatted as a JSON object with statusCode, headers, and body keys.; API Gateway passes the entire client HTTP request to the Lambda function as a structured event parameter.

Answer

The correct options are that the Lambda function response must be formatted as a JSON object with statusCode, headers, and body keys, and API Gateway passes the entire client HTTP request to the Lambda function as a structured event parameter.

In a Lambda proxy integration, API Gateway automatically forwards the entire HTTP request to the Lambda function as a structured event object, and the Lambda function must return the response in a specific JSON format containing statusCode, headers, and body keys.

Step-by-Step Solution

Analyze the integration type configured in API Gateway.

The integration is identified as a Lambda Proxy Integration.

This choice of integration dictates how data is passed and how responses must be structured.

Evaluate how API Gateway handles incoming request details under this integration model.

API Gateway automatically forwards all request details (headers, query parameters, path variables, and body) directly to the Lambda function inside the event payload without template mappings.

This is a native behavior designed to simplify request handling on the API Gateway side.

Evaluate how the backend Lambda function must return its output.

The function must return a JSON object with the specific structure containing statusCode, headers, and body so API Gateway knows how to construct the HTTP response.

This shifts the responsibility of defining HTTP status codes and headers from API Gateway's integration settings to the application code in Lambda.

Key Concept

API Gateway Lambda Proxy Integration behavior and requirements

Question 235Question →

A developer is locally testing a Node.js microservice that integrates with Amazon S3. The developer wants the service to run using the AWS credentials of a development account, which are configured under a custom profile named `[dev]` in the local `~/.aws/credentials` file.

The developer's workstation also has the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` set to credentials representing a secondary testing AWS account.

The client is initialized as follows:

javascript
import { S3Client } from "@aws-sdk/client-s3";
const s3Client = new S3Client({ profile: "dev" });

During test execution, the developer notices that S3 requests are being sent to the secondary testing account instead of the development account.

Why is the S3 client using the incorrect credentials, and how should this be resolved?

The `profile` parameter is not a valid configuration option for the `S3Client` constructor. The SDK falls back to the default credential provider chain, which prioritizes the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables. To resolve this, the developer must import the `fromIni` provider from `@aws-sdk/credential-providers` and pass it to the constructor: `new S3Client({ credentials: fromIni({ profile: 'dev' }) })`.

The default credential provider chain is failing to load the `[dev]` profile because active environment variables override shared credential files. To bypass the default chain, the developer must hardcode the development account's access key and secret key directly into the client initialization options: `new S3Client({ credentials: { accessKeyId: 'AKIAIOSFODNN7EXAMPLE', secretAccessKey: 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' } })`.

The `profile` parameter is ignored because credentials containing sensitive keys must be loaded from a secure storage service. To resolve this, the developer must upload the credentials to the AWS Systems Manager Parameter Store as a SecureString parameter and configure the S3 client to retrieve them dynamically by providing the parameter ARN in the constructor options.

The SDK is unable to assume the IAM role associated with the `[dev]` profile because the IAM User's policy is missing a trust relationship with the local machine. To resolve this, the developer must update the IAM role's trust policy to allow the `sts:AssumeRole` action for the local machine's IP address and specify the role ARN in the client configuration.

Show answer & explanation

Answer: The `profile` parameter is not a valid configuration option for the `S3Client` constructor. The SDK falls back to the default credential provider chain, which prioritizes the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables. To resolve this, the developer must import the `fromIni` provider from `@aws-sdk/credential-providers` and pass it to the constructor: `new S3Client({ credentials: fromIni({ profile: 'dev' }) })`.

Answer

The S3 client constructor in the AWS SDK for JavaScript v3 does not accept a direct `profile` parameter. As a result, the SDK uses the default credential provider chain, which checks environment variables before the shared credentials file. Since active environment variables exist, the SDK utilizes those credentials instead. To resolve the issue, the developer must import and configure the client with the `fromIni` credential provider from `@aws-sdk/credential-providers` to load the custom profile explicitly.

The client constructor in the AWS SDK for JavaScript v3 does not accept a direct `profile` parameter. Consequently, the initialization falls back to the default credential provider chain. The default chain prioritizes environment variables (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`) over files. To use a custom profile, the developer must explicitly supply the `fromIni` credential provider to the client's `credentials` configuration option.

Step-by-Step Solution

Analyze the SDK client initialization syntax in the application code.

Identify that the constructor is initialized as `new S3Client({ profile: 'dev' })`.

In the AWS SDK for JavaScript v3, passing `profile` directly to the client constructor options is invalid and will be ignored by the constructor.

Evaluate the default credential provider chain resolution order.

The environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are detected and loaded first.

Since the `profile` parameter is ignored, the SDK falls back to the default chain, where environment variables take precedence over profiles in the shared credentials file.

Determine the correct method to load a custom profile using the SDK.

Import `fromIni` from `@aws-sdk/credential-providers` and supply it to the `credentials` parameter of the client constructor.

This explicitly configures the S3 client to resolve credentials from the designated profile in the shared credentials file, bypassing the environment variables.

Key Concept

AWS SDK credential resolution order and custom profile configuration

Estimated Time:2m 0s

Question 236Question →

A developer is configuring an Amazon API Gateway REST API with a Lambda proxy integration. The backend AWS Lambda function needs to return a custom HTTP status code of 201 (Created), a custom header, and a JSON payload to the client. How must the developer structure the response returned by the Lambda function?

Configure integration response mapping templates in API Gateway to extract the custom header and HTTP status code from the Lambda function's default output properties.

Use a custom Lambda authorizer to modify the response headers and HTTP status code before the API Gateway forwards the payload to the client.

Return a JSON object from the Lambda function containing statusCode, headers, and body fields, with the body field stringified.

Return the raw application JSON payload directly, because API Gateway automatically maps the payload and defaults to a 201 status code for successful Lambda executions.

Show answer & explanation

Answer: Return a JSON object from the Lambda function containing statusCode, headers, and body fields, with the body field stringified.

Answer

Return a JSON object from the Lambda function containing statusCode, headers, and body fields, with the body field stringified.

In a Lambda proxy integration, the backend Lambda function is fully responsible for determining the structure of the HTTP response. To return custom status codes, headers, and payloads, the developer must return a JSON object with the keys 'statusCode', 'headers', and 'body' (where the body payload must be serialized to a string). API Gateway parses this object to construct the final HTTP response sent back to the client.

Step-by-Step Solution

Determine the integration type configuration.

Identify that the REST API is configured with a Lambda proxy integration.

The integration type determines whether API Gateway or the backend Lambda function is responsible for formatting the HTTP response.

Identify the response requirements for Lambda proxy integration.

Recognize that API Gateway expects the Lambda function to return a specific JSON schema consisting of 'statusCode', 'headers', and 'body'.

Under proxy integration, API Gateway passes the raw output directly from the Lambda function to the client after parsing these top-level fields.

Format the payload and metadata in the Lambda code.

Build the response object where 'statusCode' is set to 201, the custom header is included inside 'headers', and the JSON payload is serialized into a string inside 'body'.

The body must be stringified because API Gateway expects the value of the 'body' property to be a string.

Key Concept

Lambda Proxy Integration Response Format

Estimated Time:1m 0s

Question 237Question →

A developer is deploying a new AWS Lambda function that reads data from an Amazon DynamoDB table. What is the AWS-recommended best practice for authorizing the Lambda function to perform this action?

Add the DynamoDB read permissions directly to the trust policy of the Lambda function's IAM execution role to allow the function to perform actions on the table.

Assign an IAM execution role to the Lambda function with a permission policy that grants DynamoDB read access, and initialize the AWS SDK client without specifying static credentials.

Embed the AWS access key ID and secret access key directly in the Lambda function's source code during the initialization of the AWS SDK client.

Configure the Lambda function's environment variables to store the AWS access key ID and secret access key, and load them into the AWS SDK client at runtime.

Show answer & explanation

Answer: Assign an IAM execution role to the Lambda function with a permission policy that grants DynamoDB read access, and initialize the AWS SDK client without specifying static credentials.

Answer

Assign an IAM execution role to the Lambda function with a permission policy that grants DynamoDB read access, and initialize the AWS SDK client without specifying static credentials.

The correct approach is to assign an IAM execution role to the AWS Lambda function. The permission policy attached to this role should grant the minimum required permissions (such as read access to the specific DynamoDB table). When the Lambda function runs, the AWS SDK automatically retrieves temporary security credentials provided by the execution role. This avoids the need to manage or store long-lived AWS credentials in the function code or configuration.

Step-by-Step Solution

Create an IAM role for the AWS Lambda function.

The Lambda service is allowed to assume the role via the role's trust policy.

This establishes the identity that the Lambda function will use when executing.

Attach a permission policy to the IAM role that allows the required DynamoDB read actions.

The role is granted permission to perform read operations on the target table.

This follows the principle of least privilege by explicitly allowing only the necessary database access.

Associate the IAM role with the Lambda function and initialize the AWS SDK client using its default configuration.

The AWS SDK automatically retrieves and uses the temporary credentials generated when Lambda assumes the role.

This eliminates the need to distribute, store, or manage long-lived AWS access keys.

Key Concept

IAM Execution Role and AWS SDK Default Credential Provider Chain

Question 238Question →

A developer is writing a Node.js application that uses the AWS SDK for JavaScript to read data from an Amazon DynamoDB table. The application must run on the developer's local workstation during development and on an AWS Lambda function in the production environment. Which two configurations should the developer use to manage credentials securely and ensure the application works in both environments without code modifications?

Select all that apply

Initialize the DynamoDB client by passing the AWS access key and secret key directly to the constructor in the application code.

Configure the credentials in the shared credentials file (~/.aws/credentials) on the local workstation, and assign an IAM execution role with DynamoDB access permissions to the Lambda function.

Instantiate the DynamoDB client using the default constructor without passing explicit credentials.

Package a local configuration file containing the developer's AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY directly inside the Lambda deployment package.

Store the developer's long-lived IAM access keys in AWS Secrets Manager, and configure the application to query Secrets Manager at startup to retrieve credentials.

Show answer & explanation

Answer: Configure the credentials in the shared credentials file (~/.aws/credentials) on the local workstation, and assign an IAM execution role with DynamoDB access permissions to the Lambda function.; Instantiate the DynamoDB client using the default constructor without passing explicit credentials.

Answer

Configure credentials in the shared credentials file (~/.aws/credentials) on the local workstation, assign an IAM execution role with DynamoDB access permissions to the Lambda function, and instantiate the DynamoDB client using the default constructor without passing explicit credentials.

The correct approach involves configuring the developer's credentials locally in the shared credentials file, assigning an IAM execution role to the Lambda function, and instantiating the SDK client using the default constructor. When initialized without credentials, the AWS SDK default credential provider chain looks for credentials dynamically. On the local workstation, the SDK resolves credentials from the shared credentials file. On Lambda, the SDK automatically retrieves temporary security credentials from the IAM execution role via environment variables.

Step-by-Step Solution

Determine the mechanism the AWS SDK uses to locate credentials automatically.

The AWS SDK implements the default credential provider chain, which searches for credentials in a specific sequence: environment variables, system properties, the shared credentials file, and container/execution roles.

Leveraging this chain allows writing environment-agnostic code.

Set up credential sources for local and production execution environments.

Locally, the developer saves keys to the shared credentials file (~/.aws/credentials). In AWS Lambda, the developer assigns an IAM execution role with the required DynamoDB permissions.

This separates local access credentials from production environment configuration, using temporary security tokens automatically managed by Lambda.

Code the initialization of the SDK client to use the credential provider chain.

Call the client constructor without arguments or parameters, letting the chain handle lookup.

This avoids hardcoding or packaging secrets and ensures seamless local and cloud execution without changing the code.

Key Concept

AWS SDK Default Credential Provider Chain

Question 239Question →

An e-commerce company is migrating their legacy billing system to a serverless architecture. They choose to expose their backend AWS Lambda function using an Amazon API Gateway REST API with a Lambda proxy integration. To ensure that the client application receives a valid JSON response from the API, what specific output requirements must the Lambda function adhere to? (Select TWO.)

Select all that apply

Return a JSON object containing the 'statusCode' key set to an HTTP status code integer.

Define a response mapping template within the Integration Response in the API Gateway console.

Return a JSON object containing the 'body' key set to a string representation of the JSON payload.

Configure a Lambda authorizer to process and format the return message from the Lambda function.

Return only the business data payload as a raw JSON object, allowing API Gateway to default to a 200 status.

Show answer & explanation

Answer: Return a JSON object containing the 'statusCode' key set to an HTTP status code integer.; Return a JSON object containing the 'body' key set to a string representation of the JSON payload.

Answer

The Lambda function must return a JSON object containing a 'statusCode' key with the HTTP status code and a 'body' key with the stringified JSON payload.

In Amazon API Gateway Lambda proxy integrations, the backend AWS Lambda function is responsible for formatting the entire HTTP response. The response returned by the function must be a JSON object containing the 'statusCode' key (specifying the HTTP response code) and the 'body' key (containing a serialized string representation of the JSON payload).

Step-by-Step Solution

Identify the integration type being used between Amazon API Gateway and the AWS Lambda function.

The integration is Lambda Proxy Integration.

This determines whether API Gateway parses the response automatically or relies on mapping templates.

Determine the required response structure for Lambda Proxy Integration.

The backend Lambda function must return a specific JSON response format containing 'statusCode' and 'body' fields.

API Gateway does not map the response itself in a proxy integration; it expects the backend code to explicitly define the status code and stringified body.

Key Concept

API Gateway Lambda Proxy Integration Response Format

Estimated Time:1m 0s

Question 240Question →

An application contains an AWS Lambda function that retrieves configuration files from Amazon S3 and writes audit logs to Amazon DynamoDB. The function's latency is higher than expected due to client initialization and S3 downloads occurring on every invocation. Which two actions will optimize the performance of this function by leveraging execution context reuse? (Select TWO.)

Select all that apply

Initialize the AWS SDK clients for S3 and DynamoDB outside of the Lambda handler function.

Download and store the configuration files in the local /tmp directory to reuse them across subsequent invocations.

Instantiate the S3 and DynamoDB SDK clients inside the handler function to guarantee fresh connections for each invocation.

Hardcode the AWS access key and secret access key in the SDK client configuration to reduce credential retrieval time.

Configure the Lambda function to run inside a private VPC subnet without a NAT Gateway or VPC endpoints to ensure isolated database routing.

Show answer & explanation

Answer: Initialize the AWS SDK clients for S3 and DynamoDB outside of the Lambda handler function.; Download and store the configuration files in the local /tmp directory to reuse them across subsequent invocations.

Answer

To optimize the Lambda function using execution context reuse, the developer should initialize the S3 and DynamoDB SDK clients outside of the handler function, and download and store the configuration files in the local /tmp directory.

Initializing AWS SDK clients outside the handler method enables the execution environment to reuse the connection pool across warm invocations. Additionally, caching files in the local /tmp directory allows subsequent invocations to read the configurations from local storage instead of performing network requests to Amazon S3.

Step-by-Step Solution

Identify performance bottlenecks related to execution context setup.

Recognize that SDK client instantiation and S3 downloads inside the handler execute on every invocation.

To optimize, initialization tasks should be moved to the global initialization phase (outside the handler).

Move SDK client initialization to the global scope.

SDK clients are initialized once during cold start and reused in subsequent warm invocations.

Reusing clients reduces latency by skipping initialization on warm starts.

Utilize the local execution environment storage.

Configuration files are cached in the /tmp directory and read locally if present.

Accessing /tmp is significantly faster than downloading the file from S3 on every invocation.

Key Concept

Execution context reuse and temporary storage cache optimization in AWS Lambda

Estimated Time:1m 0s

PreviousPage 12 / 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