All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

An enterprise manages its application secrets in a dedicated security AWS account (Account A). A containerized microservice deployed on Amazon ECS Fargate in a production AWS account (Account B) needs access to a third-party payment provider's API key. This API key must be automatically rotated every 30 days using a custom rotation lifecycle, and the microservice must retrieve the plaintext key at runtime via the AWS SDK. Which configuration should the developer implement to meet these requirements securely?

Store the API key in AWS Secrets Manager in Account A. Attach a resource-based policy to the secret that grants retrieve permissions to the ECS Task Role in Account B. Configure AWS Secrets Manager to automatically rotate the secret every 30 days using a custom AWS Lambda function in Account A.

Store the API key as a SecureString parameter in Systems Manager Parameter Store in Account A. Attach a resource-based policy to the parameter that grants read permissions to the ECS Task Role in Account B, and configure Systems Manager to perform automatic rotation using a custom AWS Lambda function.

Store the API key in AWS Secrets Manager in Account A. Attach a resource-based policy to the secret that grants retrieve permissions to the ECS Task Execution Role in Account B. Configure AWS Secrets Manager to automatically rotate the secret every 30 days using a custom AWS Lambda function in Account A.

Store the API key in Systems Manager Parameter Store as a SecureString parameter in Account B. Hardcode the AWS Access Key ID and Secret Access Key of an IAM user from Account A in the Fargate container environment variables, and configure a cron job within the container to rotate the parameter.

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager in Account A. Attach a resource-based policy to the secret that grants retrieve permissions to the ECS Task Role in Account B. Configure AWS Secrets Manager to automatically rotate the secret every 30 days using a custom AWS Lambda function in Account A.

Answer

Store the API key in AWS Secrets Manager in Account A, allow access to the ECS Task Role in Account B using a resource-based policy, and configure automatic rotation using an AWS Lambda function in Account A.

The correct solution stores the API key in AWS Secrets Manager in Account A because it natively supports resource-based policies for direct cross-account access and provides automatic rotation using AWS Lambda. The permissions must be granted to the ECS Task Role in Account B since the application retrieves the secret at runtime using the AWS SDK.

Step-by-Step Solution

Determine the service to use for secret storage and rotation.

AWS Secrets Manager is selected because it natively supports automatic rotation via custom Lambda functions and allows resource-based policies for simple cross-account access.

Systems Manager Parameter Store does not support resource-based policies or built-in automatic rotation.

Select the correct IAM role for the Fargate task.

The ECS Task Role is selected.

The application code retrieves the secret at runtime using the AWS SDK, which relies on permissions associated with the Task Role. The Task Execution Role is only used by the container agent during container startup.

Configure the cross-account access policy.

A resource-based IAM policy is attached to the secret in Account A, granting 'secretsmanager:GetSecretValue' permissions to the ECS Task Role ARN in Account B.

This configuration allows the Task Role in Account B to directly fetch the secret from Account A without assuming another role.

Set up the rotation window and target.

A custom Lambda function in Account A is linked to the secret to handle the API key rotation lifecycle every 30 days.

AWS Secrets Manager handles the scheduling and triggers the Lambda function to coordinate the secret update with the third-party provider.

Key Concept

Distinguishing between AWS Secrets Manager and Systems Manager Parameter Store for secret rotation and cross-account access, while correctly applying ECS Task Roles for runtime application permissions.

Question 842Question →

A developer is deploying a containerized Node.js backend application to Amazon ECS on AWS Fargate. The application exposes REST APIs to a web portal where users authenticate using an Amazon Cognito User Pool. The client applications send the JSON Web Token (JWT) access token in the HTTP Authorization header of their requests. The developer needs to implement middleware in the Node.js application to validate these tokens locally, ensuring authenticity without making an external network call to Cognito for every incoming API request. Which approach should the developer take to meet these requirements?

Exchange the user pool access token for temporary AWS credentials using a Cognito Identity Pool on every request, and use the credentials to authenticate the session.

Download the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint and cache it. For each request, verify the token signature using the cached keys, and validate the token expiration and issuer claims.

Configure the Node.js middleware to invoke a Lambda Authorizer function via the AWS SDK, passing the token to validate it against the user pool client credentials.

Configure the IAM trust policy of the ECS Task Execution Role to trust the Cognito User Pool, allowing the container to automatically validate the token signature.

Show answer & explanation

Answer: Download the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint and cache it. For each request, verify the token signature using the cached keys, and validate the token expiration and issuer claims.

Answer

Verifying the token locally requires downloading the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint, caching it, and using the public keys to verify the token signature and validate the claims locally without making network calls on every request.

Step-by-Step Solution

Download and cache the JSON Web Key Set (JWKS) from the Cognito User Pool's public well-known endpoint.

The application obtains the public keys used by the User Pool to sign JWTs.

This allows the application to perform local cryptographic signature checks without calling Cognito on every request.

Extract the JWT from the HTTP Authorization header and match the key ID ('kid') header claim against the cached JWKS.

The corresponding public key is identified for signature validation.

This ensures the correct cryptographic key is used to verify the signature.

Verify the signature and validate claims including the expiration time ('exp') and issuer ('iss') against the Cognito User Pool URL.

The token is confirmed to be authentic, untampered, and currently active.

This completes the validation flow locally.

Key Concept

Local validation of Cognito JWT access tokens using the JSON Web Key Set (JWKS).

Estimated Time:1m 30s

Question 843Question →

A developer is setting up a build process in AWS CodeBuild that requires a database password and a software license key. The database password must be rotated automatically on a regular schedule, whereas the license key is a static configuration parameter that does not require rotation. The developer wants to retrieve these values securely during the build phase.

Which combination of steps will meet these requirements in the most secure and cost-effective manner? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager and reference it in the env/secrets-manager section of the buildspec file.

Store the license key in AWS Systems Manager Parameter Store and reference it in the env/parameter-store section of the buildspec file.

Store the database password in AWS Systems Manager Parameter Store and configure rotation using a custom Amazon EventBridge rule.

Store the database password as a plaintext environment variable in the env/variables section of the buildspec file.

Define the database password and license key in the trust policy of the AWS CodeBuild service IAM role.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and reference it in the env/secrets-manager section of the buildspec file.; Store the license key in AWS Systems Manager Parameter Store and reference it in the env/parameter-store section of the buildspec file.

Answer

Store the database password in AWS Secrets Manager and reference it in the env/secrets-manager section of the buildspec file, and store the license key in AWS Systems Manager Parameter Store and reference it in the env/parameter-store section of the buildspec file.

Storing the database password in AWS Secrets Manager enables native, automatic rotation of the credential, which can be securely fetched at build time by referencing it in the env/secrets-manager section of the buildspec file. For the static license key, AWS Systems Manager Parameter Store is a cost-effective and secure solution that does not require rotation, and can be retrieved using the env/parameter-store section of the buildspec file.

Step-by-Step Solution

Analyze rotation requirements for the sensitive data.

The database password requires automatic rotation, making AWS Secrets Manager the ideal service. The software license key is static and does not require rotation, making AWS Systems Manager Parameter Store a more cost-effective option.

Choosing the correct storage service based on rotation needs optimizes security and cost.

Identify how AWS CodeBuild references these external configurations in the buildspec file.

Secrets Manager secrets are referenced in the env/secrets-manager section, and Parameter Store parameters are referenced in the env/parameter-store section.

Using the native CodeBuild buildspec environment syntax ensures the secrets are fetched securely at runtime during the build.

Key Concept

AWS CodeBuild environment variable retrieval from Secrets Manager and Systems Manager Parameter Store

Estimated Time:50s

Question 844Question →

A developer is updating a critical production web application deployed on AWS Elastic Beanstalk. The deployment process must ensure zero downtime and support an immediate rollback to the previous version if the new version fails health checks. Which two Elastic Beanstalk deployment strategies or options meet these requirements?

Select all that apply

Blue/Green deployment using a CNAME swap

Immutable deployment

All-at-once deployment

Rolling deployment

Rolling with additional batch deployment

Show answer & explanation

Answer: Blue/Green deployment using a CNAME swap; Immutable deployment

Answer

The correct options are Blue/Green deployment using a CNAME swap and Immutable deployment.

Blue/Green deployment using a CNAME swap and Immutable deployment both satisfy the requirements. A Blue/Green deployment routes traffic to a completely separate environment, allowing an immediate rollback by swapping CNAME records back if the new version fails. An Immutable deployment deploys the new version to a temporary Auto Scaling group alongside the original one. If health checks fail, the temporary group is deleted immediately, leaving the original instances unaffected.

Step-by-Step Solution

Analyze the application requirements.

The application requires zero downtime and a method to roll back immediately if the update fails.

This filters out deployment strategies that cause downtime or have slow rollback mechanisms.

Evaluate the downtime characteristics of the deployment strategies.

All-at-once causes downtime, and Rolling reduces serving capacity. Immutable, Rolling with additional batch, and Blue/Green deployments do not cause downtime.

To maintain zero downtime and full capacity, we must look at strategies that avoid in-place service degradation.

Evaluate the rollback speed of the zero-downtime strategies.

Rolling with additional batch requires a slow, sequential redeployment to roll back. Immutable and Blue/Green deployments allow for an immediate rollback because they maintain the old version on separate, untouched instances.

Selecting strategies that support immediate rollback satisfies the final constraint.

Key Concept

AWS Elastic Beanstalk deployment strategies and their trade-offs regarding downtime, capacity, and rollback speed.

Question 845Question →

A developer is deploying a serverless microservice on AWS Lambda that requires access to an Amazon RDS database. The developer needs to store the database host URL (non-sensitive configuration) and the database password (sensitive credential). The database password must be automatically rotated every 30 days. Which combination of actions should the developer take to meet these requirements in the most secure and cost-effective manner? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager and enable automatic rotation.

Store the database host URL as a String parameter in AWS Systems Manager Parameter Store.

Store the database password in AWS Systems Manager Parameter Store as a SecureString parameter and configure scheduled automatic rotation.

Hardcode the database password directly within the Lambda function code to minimize configuration overhead.

Store both the database host URL and the database password in AWS Secrets Manager as a single JSON secret with automatic rotation enabled.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and enable automatic rotation.; Store the database host URL as a String parameter in AWS Systems Manager Parameter Store.

Answer

The developer should store the database password in AWS Secrets Manager with automatic rotation enabled, and store the database host URL in AWS Systems Manager Parameter Store.

The correct options are storing the database password in AWS Secrets Manager and storing the database host URL in AWS Systems Manager Parameter Store. Storing the password in AWS Secrets Manager ensures security and enables native automatic rotation (especially for RDS). Storing the host URL in Systems Manager Parameter Store is the most cost-effective solution for non-sensitive configuration details because standard parameters in Parameter Store are free, avoiding unnecessary Secrets Manager fees.

Step-by-Step Solution

Identify the sensitivity of the data and rotation requirements.

The host URL is non-sensitive, whereas the database password is a sensitive credential requiring automatic rotation.

This allows selecting the most secure and cost-effective service for each type of configuration data.

Determine the appropriate service for the sensitive database password.

AWS Secrets Manager is chosen because it supports automatic rotation natively, particularly for Amazon RDS.

Systems Manager Parameter Store does not natively support automatic rotation.

Determine the appropriate service for the non-sensitive host URL.

AWS Systems Manager Parameter Store (standard String parameter) is chosen because it is free of charge and ideal for plain text configuration parameters.

Storing non-sensitive data in AWS Secrets Manager would incur unnecessary costs.

Key Concept

Selecting the appropriate secrets management service based on sensitivity, rotation requirements, and cost-efficiency.

Estimated Time:1m 0s

Question 846Question →

A developer is configuring a continuous integration and continuous delivery (CI/CD) pipeline in AWS CodePipeline. The pipeline includes a test stage that invokes an AWS Lambda function to run integration tests against a database. The Lambda function requires database credentials to connect to the database and must notify CodePipeline of the success or failure of the tests. Which of the following actions should the developer perform to configure this setup securely and correctly? (Select TWO.)

Select all that apply

Store the database credentials in AWS Secrets Manager and grant the Lambda function's IAM execution role permission to retrieve the secret.

Grant the Lambda function's IAM execution role permission to perform the codepipeline:PutJobSuccessResult and codepipeline:PutJobFailureResult API operations.

Store the database credentials in AWS Systems Manager Parameter Store as a standard parameter and configure Parameter Store to automatically rotate the credentials.

Configure the trust policy of the Lambda function's IAM execution role to allow the CodePipeline service principal to assume the role using the sts:AssumeRole action.

Hardcode the database credentials directly in the Lambda function's initialization code and configure the AWS SDK client to use those credentials.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and grant the Lambda function's IAM execution role permission to retrieve the secret.; Grant the Lambda function's IAM execution role permission to perform the codepipeline:PutJobSuccessResult and codepipeline:PutJobFailureResult API operations.

Answer

To configure this setup securely and correctly, the developer should store the database credentials in AWS Secrets Manager and grant the Lambda execution role permission to retrieve the secret. Additionally, the Lambda execution role must be granted permissions to call the codepipeline:PutJobSuccessResult and codepipeline:PutJobFailureResult API operations to report the job status back to CodePipeline.

Storing database credentials in AWS Secrets Manager allows secure storage and automatic rotation of secrets. The Lambda execution role must be granted permissions to retrieve this secret to connect to the database. Additionally, when CodePipeline invokes a Lambda function, the function runs asynchronously and must report the outcome back to CodePipeline. The Lambda function's execution role requires permission to call codepipeline:PutJobSuccessResult and codepipeline:PutJobFailureResult to update the pipeline stage status.

Step-by-Step Solution

Determine the secure method for storing and retrieving database credentials.

Identify AWS Secrets Manager as the appropriate service because it supports built-in rotation and secure runtime retrieval, unlike Systems Manager Parameter Store standard parameters.

This prevents credentials from being hardcoded in code or configuration files, adhering to security best practices.

Determine the required permissions for CodePipeline integration with Lambda.

Identify that the Lambda function must report its execution status back to CodePipeline to mark the stage as success or failure using the PutJobSuccessResult or PutJobFailureResult API operations.

Lambda tasks in CodePipeline run asynchronously. CodePipeline expects the function to send a success or failure token to complete the job; otherwise, the pipeline stage will remain in progress until it times out.

Key Concept

When AWS CodePipeline invokes an AWS Lambda function, the Lambda function must report back success or failure using the PutJobSuccessResult or PutJobFailureResult API calls. Additionally, database credentials should be stored securely in AWS Secrets Manager rather than in Parameter Store (which lacks native rotation for standard parameters) or hardcoded.

Question 847Question →

A developer is building an application that must encrypt raw sensor data files, each approximately $20\text{ MB}$ in size, locally on an application server before uploading them to a third-party storage system. The developer wants to use envelope encryption with a customer managed AWS KMS key. Which two steps must the developer perform to implement this encryption process?

Select all that apply

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

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

Call the KMS Encrypt API operation directly to encrypt each sensor data file.

Call the GenerateDataKeyWithoutPlaintext API operation, and decrypt the returned ciphertext using the public certificate of the KMS key.

Store the plaintext data key as a SecureString parameter in AWS Systems Manager Parameter Store to use for subsequent decryption operations.

Show answer & explanation

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

Answer

To implement envelope encryption for files larger than

4\text{ KB}

, the developer must call the GenerateDataKey API to obtain both a plaintext and an encrypted data key, encrypt the data locally using the plaintext data key, and then immediately destroy the plaintext key from memory.

The correct steps for envelope encryption involve calling the GenerateDataKey API operation to retrieve a plaintext data key and an encrypted version of that key. The application then uses the plaintext data key to perform local symmetric encryption of the payload, and finally deletes the plaintext key from memory. The encrypted data key is saved alongside the encrypted data so that it can be decrypted by KMS later.

Step-by-Step Solution

Invoke the KMS GenerateDataKey API.

The API returns a plaintext version of the data key and a ciphertext version encrypted under the customer managed KMS key.

Because the files are

20\text{ MB}

in size, they exceed the direct KMS encryption limit of

4\text{ KB}

, requiring local envelope encryption.

Encrypt the raw sensor data locally using a symmetric encryption algorithm and the plaintext data key.

The file is encrypted to a ciphertext payload.

Performing encryption locally offloads the cryptographic workload from KMS to the application server.

Discard the plaintext data key from application memory, and store the encrypted data key alongside the encrypted payload.

Only the encrypted data key and the encrypted payload remain.

Retaining the plaintext key in memory increases security risks. The encrypted data key is safe to store next to the encrypted file and will be used during decryption.

Key Concept

Envelope encryption is the practice of encrypting plaintext data with a data key, and then encrypting the data key under another key (the KMS root key). It is required for encrypting data payloads larger than

4\text{ KB}

using AWS KMS.

Question 848Question →

A developer is deploying a web application where the frontend authenticates users via a third-party Identity Provider (IdP) using OpenID Connect (OIDC). The frontend needs to make requests to a backend service exposed through an Amazon API Gateway HTTP API. The API must validate the incoming JSON Web Token (JWT) at the gateway layer before routing the request to backend AWS Lambda functions. The developer wants to implement this validation with the least amount of custom code and lowest latency. Which of the following configuration steps should the developer perform?

Configure a built-in JWT authorizer on the HTTP API, providing the Issuer URL from the third-party IdP and the target Audience, and associate it with the API routes.

Create an Amazon Cognito Identity Pool to exchange the third-party JWT for temporary AWS IAM credentials, and configure IAM authorization on the HTTP API routes.

Create an Amazon API Gateway Lambda authorizer that parses the JWT, calls the third-party IdP's validation endpoint, and generates an IAM policy to allow the request.

Configure a Lambda proxy integration that passes the raw authorization header to the backend Lambda function, and validate the JWT within the application code of each backend function.

Show answer & explanation

Answer: Configure a built-in JWT authorizer on the HTTP API, providing the Issuer URL from the third-party IdP and the target Audience, and associate it with the API routes.

Answer

Configure a built-in JWT authorizer on the HTTP API, providing the Issuer URL from the third-party IdP and the target Audience, and associate it with the API routes.

The correct answer is to configure a built-in JWT authorizer on the HTTP API. Amazon API Gateway HTTP APIs provide native support for JWT validation against OIDC-compliant Identity Providers. This built-in mechanism validates token signatures, expiration dates, and scopes without executing custom Lambda code, offering the lowest latency and overhead.

Step-by-Step Solution

Select the API Gateway HTTP API and create a new Authorizer under the Security section.

A template for creating a new authorizer is displayed.

An authorizer is required at the gateway layer to intercept incoming requests and validate credentials before they reach the backend.

Choose JWT as the authorizer type, and configure the Identity Source (typically the Authorization header), Issuer URL (the third-party IdP's URL), and Audience (the client ID).

API Gateway automatically fetches the public keys (JWKS) from the OIDC issuer to validate incoming tokens.

This utilizes API Gateway's built-in OAuth 2.0 / OIDC capabilities to check token signatures and claims without custom code.

Attach the newly created JWT authorizer to the target HTTP API routes.

The HTTP API routes are now protected, and unauthorized requests are blocked directly at the gateway with a 401 Unauthorized status.

Associating the authorizer with specific routes ensures that only authenticated requests with valid tokens are forwarded to the backend integrations.

Key Concept

API Gateway HTTP APIs support built-in JWT authorizers that natively validate tokens from OpenID Connect (OIDC) compatible identity providers, eliminating the need for custom authorizer Lambda functions or IAM credential exchange.

Question 849Question →

A developer is deploying a containerized application to Amazon ECS using the AWS Fargate launch type. The ECS task needs to pull the container image from a private Amazon ECR repository and send container logs to Amazon CloudWatch. Once running, the application code inside the container must read data files from an Amazon S3 bucket.

Which two IAM configuration steps must the developer take in the ECS task definition to grant these permissions?

Select all that apply

Configure the Task Execution Role with permissions to pull the container image from Amazon ECR and send logs to Amazon CloudWatch.

Configure the Task Role with permissions to read objects from the Amazon S3 bucket.

Configure the Task Role with permissions to pull the container image from Amazon ECR.

Configure the Task Execution Role with permissions to read objects from the Amazon S3 bucket.

Hardcode IAM user credentials with Amazon S3 read permissions in the application's environment variables.

Show answer & explanation

Answer: Configure the Task Execution Role with permissions to pull the container image from Amazon ECR and send logs to Amazon CloudWatch.; Configure the Task Role with permissions to read objects from the Amazon S3 bucket.

Answer

Configure the Task Execution Role with permissions to pull the container image from Amazon ECR and send logs to Amazon CloudWatch, and configure the Task Role with permissions to read objects from the Amazon S3 bucket.

To deploy the application securely, the developer must use two separate IAM roles. The Task Execution Role is required by the Amazon ECS container agent to authenticate with Amazon ECR to pull the Docker image and to create log streams in Amazon CloudWatch before the container starts. The Task Role is assumed by the application code running inside the container to authorize calls to other AWS services, such as reading files from the Amazon S3 bucket.

Step-by-Step Solution

Identify the permissions needed by the ECS agent / container runtime vs the application code.

ECR image pulling and CloudWatch log streaming are performed by the ECS agent, while S3 reading is performed by the application code.

This separation determines which IAM roles need to be configured in the task definition.

Assign the ECS agent permissions to the Task Execution Role.

The Task Execution Role receives permissions for ECR and CloudWatch.

The Task Execution Role is used by the infrastructure to set up the task before application code runs.

Assign the application permissions to the Task Role.

The Task Role receives permissions for S3 bucket access.

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

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role

Question 850Question →

A developer is designing a deployment strategy for a containerized web application running on Amazon ECS (Fargate) behind an Application Load Balancer. The service currently runs with a desired task count of $8$ . The deployment must satisfy the following constraints:

* The application must maintain $100\%$ of its capacity (at least $8$ healthy tasks) during the deployment process.
* The AWS account has a strict service quota that prevents running more than $10$ concurrent tasks for this service.
* If the new container version fails to launch or fails container health checks, the deployment must automatically roll back to the previous version without manual intervention or DNS changes.

Which two configurations should the developer use to meet these requirements? (Select two.)

Select all that apply

Configure the ECS service rolling update parameters with a minimum healthy percent of

100\%

and a maximum percent of

125\%

Enable the ECS deployment circuit breaker with the rollback feature enabled on the service.

Configure the ECS service rolling update parameters with a minimum healthy percent of

50\%

and a maximum percent of

100\%

Configure AWS CodeDeploy to perform a blue/green deployment using an ECS Canary deployment configuration.

Configure an Amazon Route 53 weighted routing policy to route traffic between two separate ECS services.

Show answer & explanation

Answer: Configure the ECS service rolling update parameters with a minimum healthy percent of $100\%$ and a maximum percent of $125\%$ .; Enable the ECS deployment circuit breaker with the rollback feature enabled on the service.

Answer

Configure the ECS service rolling update parameters with a minimum healthy percent of

100\%

and a maximum percent of

125\%

, and enable the ECS deployment circuit breaker with the rollback feature enabled on the service.

To maintain

100\%

capacity during the deployment of a service with

8

desired tasks, at least

8

tasks must remain healthy, which translates to a minimum healthy percent of

100\%

. To not exceed

10

tasks total (which is

125\%

8

), the maximum percent must be set to

125\%

. In this configuration, ECS will launch

2

new tasks, wait for them to pass health checks, and then terminate

2

old tasks, repeating the process. Enabling the ECS deployment circuit breaker with rollback ensures that if these new tasks fail to launch or fail health checks, the deployment is automatically canceled and the service rolls back to the previous stable task definition without manual effort or DNS changes.

Step-by-Step Solution

Calculate the capacity and task count boundaries based on the constraints.

The minimum healthy task count must be at least

8

(

100\%

of desired). The maximum concurrent tasks cannot exceed

10

, which represents

125\%

of the desired

8

tasks (

10 / 8 = 1.25

This establishes the mathematical bounds for the ECS service's minimumHealthyPercent and maximumPercent configurations.

Determine the correct deployment mechanism that respects the task limit.

An ECS rolling update starts a batch of new tasks (up to

2

tasks, which is

25\%

of desired) before stopping the old ones. A CodeDeploy blue/green deployment requires launching an entire second task set (

8

tasks), which violates the

10

task limit.

This rules out blue/green deployment options in favor of an ECS rolling update.

Select the appropriate automated rollback mechanism that doesn't rely on DNS.

Enable the ECS deployment circuit breaker with rollback. This built-in ECS feature detects launch or health check failures and automatically rolls back the deployment to the last stable state.

This fulfills the requirement of automatic, rapid rollback without manual intervention or DNS routing updates.

Key Concept

ECS Rolling Update parameters (minimumHealthyPercent and maximumPercent) control task capacity during deployment, while ECS deployment circuit breaker provides automated rollbacks without DNS modifications.

Estimated Time:2m 30s

Question 851Question →

A developer is implementing a secure file upload utility in a Python application using the AWS SDK (Boto3). The utility must encrypt sensitive medical imaging files, each approximately $150\text{ MB}$ in size, client-side before uploading them to an Amazon S3 bucket. The application must use envelope encryption with a customer managed key (CMK) in AWS KMS to manage the encryption keys. Which programmatic workflow should the developer implement to encrypt each file while minimizing AWS KMS API calls and network overhead?

Call the generate_data_key API method passing the CMK identifier and specifying the AES_256 key spec. Use the returned plaintext data key to encrypt the file locally. Upload the encrypted file and the returned ciphertext data key to Amazon S3, then purge the plaintext data key from memory.

Call the generate_data_key_without_plaintext API method passing the CMK identifier. Call the decrypt API method passing the returned ciphertext data key to retrieve the plaintext data key. Use the plaintext data key to encrypt the file locally, then upload the encrypted file and the ciphertext data key to Amazon S3.

Call the encrypt API method passing the CMK identifier and the file contents in

4\text{ KB}

chunks. Concatenate the returned ciphertexts and upload the final consolidated file to Amazon S3.

Call the generate_data_key API method to retrieve a plaintext data key and a ciphertext data key. Call the encrypt API method passing the plaintext data key to encrypt it again with the CMK. Use the newly encrypted data key to encrypt the file, and upload the file to Amazon S3.

Show answer & explanation

Answer: Call the generate_data_key API method passing the CMK identifier and specifying the AES_256 key spec. Use the returned plaintext data key to encrypt the file locally. Upload the encrypted file and the returned ciphertext data key to Amazon S3, then purge the plaintext data key from memory.

Answer

The correct workflow is to call the generate_data_key API method, which returns both the plaintext data key (to immediately encrypt the file locally) and the ciphertext data key (to be uploaded to S3 along with the encrypted file). This ensures the envelope encryption is completed in a single KMS API call and local resources do not retain the plaintext key in memory after encryption.

Step-by-Step Solution

Generate the data key using the KMS customer managed key (CMK).

A plaintext data key and a ciphertext (encrypted) data key are returned by AWS KMS in a single API call.

Calling generate_data_key generates both key representations, avoiding the need for separate generation and encryption API calls.

Perform client-side encryption on the medical imaging file.

The file is encrypted locally using the plaintext data key and a symmetric encryption algorithm (like AES-256).

Local encryption keeps the large file payload (

150\text{ MB}

) out of KMS network transits, complying with KMS payload limits.

Store the encrypted file and the ciphertext data key in Amazon S3, and clean up memory.

The encrypted payload and ciphertext data key are uploaded to S3, and the plaintext data key is removed from application memory.

Storing the ciphertext data key alongside the encrypted file ensures it can be decrypted later, while purging the plaintext key secures it against memory-based attacks.

Key Concept

AWS KMS client-side envelope encryption workflow utilizing generate_data_key.

Question 852Question →

A developer is preparing to deploy a containerized financial API to Amazon ECS using the AWS Fargate launch type. The API application code utilizes the AWS SDK to decrypt sensitive transaction payloads at runtime using a customer managed key in AWS KMS. Additionally, the ECS agent must pull the API container image from a private Amazon ECR repository and send stdout/stderr logs to Amazon CloudWatch Logs. Which two IAM configuration steps must the developer perform to grant the necessary permissions? (Select TWO.)

Select all that apply

Attach a policy allowing the kms:Decrypt action to the IAM role configured as the Task Role in the task definition.

Attach a policy allowing the ecr:BatchGetImage and logs:PutLogEvents actions to the IAM role configured as the Task Execution Role in the task definition.

Attach a policy allowing the kms:Decrypt action to the IAM role configured as the Task Execution Role in the task definition.

Modify the trust policy of the Task Role to trust the Amazon EC2 service principal (ec2.amazonaws.com) to assume the role.

Attach a policy allowing the logs:PutLogEvents and logs:CreateLogStream actions to the IAM role configured as the Task Role in the task definition.

Show answer & explanation

Answer: Attach a policy allowing the kms:Decrypt action to the IAM role configured as the Task Role in the task definition.; Attach a policy allowing the ecr:BatchGetImage and logs:PutLogEvents actions to the IAM role configured as the Task Execution Role in the task definition.

Answer

The developer must attach a policy allowing the kms:Decrypt action to the Task Role, and attach a policy allowing the ecr:BatchGetImage and logs:PutLogEvents actions to the Task Execution Role.

The application code uses the AWS SDK to decrypt payloads at runtime, which requires the ECS Task Role to have permissions for the kms:Decrypt action. On the other hand, pulling the image from Amazon ECR and writing logs to CloudWatch are operations executed by the ECS agent on the host, meaning the ECS Task Execution Role must have permissions for ECR image pull actions and CloudWatch Logs stream creation/log ingestion.

Step-by-Step Solution

Determine the role needed for application-level AWS SDK calls.

The application code running inside the container performs decryption via the AWS SDK at runtime, which requires the ECS Task Role to have kms:Decrypt permissions.

The Task Role provides AWS credentials directly to the containerized application.

Determine the role needed for container agent-level tasks.

The ECS container agent needs to pull the container image from ECR and send stdout/stderr logs to CloudWatch Logs, which requires the ECS Task Execution Role to have ecr:BatchGetImage and logs:PutLogEvents permissions.

The Task Execution Role provides AWS credentials to the ECS agent running on the underlying host, enabling it to perform tasks on behalf of the container before it starts.

Key Concept

Delineation between ECS Task Role and ECS Task Execution Role

Question 853Question →

A developer needs to deploy a new version of a Java application to an AWS Elastic Beanstalk environment. The deployment must install a security patch on the host operating system using an environment configuration file named `security.config`. The application requires zero downtime during deployment, and the developer must ensure that if the deployment fails, the running production instances remain completely unaffected and do not require a manual recovery process. Which configuration and deployment setup meets these requirements?

Use the Rolling deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Use the Immutable deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Use the Immutable deployment policy, and place `security.config` in the `ebextensions/` directory at the root of the application source bundle.

Use the All at once deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Show answer & explanation

Answer: Use the Immutable deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Answer

Use the Immutable deployment policy, and place the configuration file in the `.ebextensions/` directory at the root of the application source bundle.

The correct answer proposes using the Immutable deployment policy and placing the configuration file in the `.ebextensions/` directory. The Immutable deployment policy performs an update by launching a second Auto Scaling group with instances running the new version. If these new instances fail health checks, Elastic Beanstalk terminates them, leaving the original environment and instances completely untouched. This satisfies the requirement that production instances remain unaffected in case of failure. Placing the configuration file in the `.ebextensions/` directory at the root of the source bundle ensures that Elastic Beanstalk successfully parses and applies the custom configuration.

Step-by-Step Solution

Analyze the deployment downtime and rollback requirements from the scenario.

The application requires zero downtime and must guarantee that a failed deployment leaves running production instances completely unaffected.

These constraints eliminate the All at once policy (which causes downtime) and the Rolling policy (which modifies existing instances, risking inconsistent states if a failure occurs).

Select the deployment policy that isolates changes and guarantees safe rollback.

The Immutable deployment policy is selected because it deploys the new version to a temporary Auto Scaling group, ensuring the existing instances are untouched until the new version is healthy.

Immutable updates provide zero downtime and the cleanest rollback path by terminating the temporary instances upon failure.

Determine the correct directory structure for Elastic Beanstalk configuration files.

The configuration file must be placed in a directory named `.ebextensions/` at the root of the source bundle.

Elastic Beanstalk requires the leading dot in `.ebextensions/` to recognize and apply the configuration files during provisioning; a folder named `ebextensions/` without the dot is ignored.

Key Concept

AWS Elastic Beanstalk Immutable deployments and `.ebextensions` configuration directory naming.

Question 854Question →

A cloud engineering team is migrating a legacy payment service to a serverless architecture on AWS. To ensure safe deployments, they intend to implement a canary rollout where $10\%$ of traffic is shifted to the new version for $10$ minutes before the remaining traffic is cut over. They write the following AWS SAM template:

yaml
Transform: AWS::Serverless-2016-10-31

Resources:
ProcessPaymentFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./payment
DeploymentPreference:
Type: Canary10Percent10Minutes

After deploying the template, the team observes that the application traffic shifts to the new function version immediately, completely bypassing the $10$ -minute canary phase.

What is the root cause of this behavior?

The AutoPublishAlias property is omitted from the function properties, preventing AWS SAM from generating the Lambda alias and CodeDeploy resources required for traffic shifting.

The IAM role assigned to the function lacks a trust relationship allowing the AWS CodeDeploy service principal to assume it.

The execution timeout of the function is set to a value shorter than the

10

-minute canary window, causing the deployment to fail back to All-at-Once routing.

The Canary10Percent10Minutes deployment configuration is exclusive to Amazon ECS task sets and cannot be applied to serverless functions.

Show answer & explanation

Answer: The AutoPublishAlias property is omitted from the function properties, preventing AWS SAM from generating the Lambda alias and CodeDeploy resources required for traffic shifting.

Answer

The AutoPublishAlias property is omitted from the function properties, which prevents AWS SAM from generating the Lambda alias and AWS CodeDeploy resources required for gradual traffic shifting.

The correct answer is correct because AWS SAM requires the AutoPublishAlias property to be defined in order to set up gradual deployments. AutoPublishAlias instructs SAM to publish new versions of the function and create a Lambda alias pointing to them. CodeDeploy shifts traffic between these versions on the alias. If AutoPublishAlias is omitted, SAM will update the function directly, resulting in an immediate traffic shift.

Step-by-Step Solution

Analyze how AWS SAM implements gradual deployment preferences using AWS CodeDeploy under the hood.

Identified that AWS CodeDeploy requires a specific target Lambda alias to shift traffic between two underlying Lambda function versions.

Traffic routing cannot occur directly on the function's static ARN or the $LATEST version.

Examine the provided template properties for the AWS::Serverless::Function resource.

Observed that the template defines DeploymentPreference but lacks the AutoPublishAlias property under Properties.

Checking if all required properties are declared to allow SAM to synthesize the CodeDeploy resources.

Determine the outcome of omitting AutoPublishAlias during the CloudFormation transformation phase.

Without AutoPublishAlias, AWS SAM does not generate the Lambda alias resource or the CodeDeploy deployment group, leading to direct updates on $LATEST and causing traffic to shift immediately.

Explaining the root cause of the immediate traffic cutover.

Key Concept

AWS SAM Gradual Lambda Deployments with CodeDeploy and AutoPublishAlias

Estimated Time:2m 0s

Question 855Question →

A developer is configuring an AWS Lambda function that needs to retrieve objects from an Amazon S3 bucket. Which of the following configurations represents the most secure method to grant the Lambda function the necessary permissions to access the S3 bucket?

Create an IAM role with a permissions policy allowing s3:GetObject, and configure the trust policy of the role to allow the s3.amazonaws.com service principal to assume it.

Create an IAM execution role with a permissions policy that allows s3:GetObject on the specific bucket, configure the trust policy of the role to allow the lambda.amazonaws.com service principal to assume it, and associate this role with the Lambda function.

Initialize the AWS SDK client inside the Lambda function code using hardcoded AWS access keys of an IAM user that has read access to the S3 bucket.

Assign an ECS Task Execution Role containing the necessary S3 permissions to the Lambda function configuration.

Show answer & explanation

Answer: Create an IAM execution role with a permissions policy that allows s3:GetObject on the specific bucket, configure the trust policy of the role to allow the lambda.amazonaws.com service principal to assume it, and associate this role with the Lambda function.

Answer

The correct answer correctly specifies creating an IAM execution role, defining its permissions policy to allow s3:GetObject, configuring its trust policy to allow lambda.amazonaws.com to assume it, and associating the role with the Lambda function. This follows the principle of least privilege and uses secure, temporary credentials.

Step-by-Step Solution

Determine the resource access model.

AWS Lambda functions assume execution roles to get temporary credentials for other AWS services.

This avoids hardcoding long-lived access keys in code or environment variables.

Define the IAM execution role components.

The role must have a trust policy for the Lambda service principal (lambda.amazonaws.com) and a permissions policy for s3:GetObject on the bucket.

The trust policy allows Lambda to assume the role, while the permissions policy allows the assumed role to access S3.

Associate the role.

Attach the configured IAM execution role to the Lambda function configuration.

This grants the Lambda function instance the identity and temporary credentials of the role during execution.

Key Concept

IAM Execution Roles for AWS Lambda

Question 856Question →

An e-commerce application requires users to authenticate before they can download digital invoice PDFs directly from a private Amazon S3 bucket. The developer has set up user registration and authentication using Amazon Cognito. Which Cognito component must be configured to exchange the authenticated user session for temporary, limited-privilege AWS credentials?

Cognito Identity Pools

Cognito User Pools

API Gateway Lambda Authorizer

Cognito User Pool Authorizer

Show answer & explanation

Answer: Cognito Identity Pools

Answer

Cognito Identity Pools

Cognito Identity Pools (Federated Identities) enable applications to obtain temporary, limited-privilege AWS credentials. These credentials allow client applications to make direct calls to AWS services such as Amazon S3, using IAM roles associated with the authenticated or unauthenticated identity pool users.

Step-by-Step Solution

Identify the primary requirement: the client application needs temporary, limited-privilege AWS credentials to interact directly with an AWS service (Amazon S3).

Temporary AWS credentials (access key, secret key, and session token) are required.

Direct calls to S3 APIs from a client application require AWS credentials rather than standard OAuth/OIDC identity or access tokens.

Evaluate the difference between Cognito User Pools and Cognito Identity Pools.

User Pools manage the user directory and authentication, while Identity Pools provide AWS credentials (authorization) based on successful authentication.

To bridge the gap between user identity (authentication) and AWS permissions (authorization), Cognito Identity Pools must be configured.

Key Concept

Amazon Cognito Identity Pools are used to federate identities and obtain temporary AWS credentials for accessing AWS resources directly.

Estimated Time:45s

Question 857Question →

A developer is preparing to update an AWS CloudFormation stack that manages a production backend application. The update involves introducing a new external service API key that must be stored securely with support for automatic rotation. Additionally, the developer must ensure that any manual, out-of-band changes previously made to the stack's resources are identified and resolved before the update is performed to prevent deployment failures.

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

Select all that apply

Store the API key in AWS Secrets Manager, and reference it in the CloudFormation template using a dynamic reference.

Run drift detection on the CloudFormation stack, identify any drifted resources, and update the template or import resources to resolve the differences before updating the stack.

Store the API key in Systems Manager Parameter Store as a Standard parameter, and reference it in the CloudFormation template using a Systems Manager dynamic reference.

Modify the drifted resources manually in the AWS Management Console to match the updated template configurations, then apply the stack update.

Initiate the stack update directly, and if a failure occurs, manually delete the resource that caused the rollback while the stack is in the ROLLBACK_IN_PROGRESS state.

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager, and reference it in the CloudFormation template using a dynamic reference.; Run drift detection on the CloudFormation stack, identify any drifted resources, and update the template or import resources to resolve the differences before updating the stack.

Answer

Storing the API key in AWS Secrets Manager and referencing it via a dynamic reference, and running drift detection to identify and resolve drifted resources before updating the stack.

Storing the API key in AWS Secrets Manager satisfies the requirements for secure storage and automatic rotation, and referencing it via a dynamic reference ensures security. Running drift detection identifies any out-of-band changes that would cause the stack update to fail, allowing the developer to synchronize the template and actual resource configurations before deploying the update.

Step-by-Step Solution

Select the appropriate storage service for the API key.

AWS Secrets Manager is chosen because it supports automatic rotation and secure credential storage.

Systems Manager Parameter Store does not offer native automatic rotation for secrets, whereas Secrets Manager does.

Integrate the secret securely in the CloudFormation template.

Reference the secret using the Secrets Manager dynamic reference format in the template.

This prevents hardcoding sensitive credentials in the template and allows retrieval at deployment time.

Identify out-of-band resource modifications.

Execute drift detection on the CloudFormation stack.

Drift detection reveals which resources have been modified outside of CloudFormation control.

Resolve resource drift before deploying the update.

Update the template to match the drifted state or import/re-import resources as necessary.

This ensures the stack state is synchronized with the template, preventing deployment conflicts and rollback failures.

Key Concept

CloudFormation update mechanics, drift detection, and secure parameter retrieval.

Question 858Question →

A developer is building a serverless web application. The application requires users to register and sign in. Additionally, authenticated users must be allowed to upload files directly to a private Amazon S3 bucket. Which TWO Amazon Cognito components are required to meet these requirements?

Select all that apply

An Amazon Cognito User Pool to manage user registration, authentication, and the user directory

An Amazon Cognito Identity Pool to authorize users and provide temporary AWS credentials for accessing the Amazon S3 bucket

A custom Amazon API Gateway Lambda Authorizer to generate temporary IAM credentials for direct Amazon S3 bucket access

An Amazon Cognito User Pool configured to directly issue temporary AWS credentials to the client web application

An Amazon API Gateway Cognito Authorizer configured to authorize direct uploads to the Amazon S3 bucket

Show answer & explanation

Answer: An Amazon Cognito User Pool to manage user registration, authentication, and the user directory; An Amazon Cognito Identity Pool to authorize users and provide temporary AWS credentials for accessing the Amazon S3 bucket

Answer

The developer must use an Amazon Cognito User Pool to manage user registration, authentication, and the user directory, alongside an Amazon Cognito Identity Pool to authorize users and provide temporary AWS credentials for accessing the Amazon S3 bucket.

To implement user authentication (sign-up, sign-in, directory), a Cognito User Pool is required. To authorize the users to access AWS resources directly, such as uploading files to Amazon S3, an Amazon Cognito Identity Pool is required to exchange the User Pool tokens for temporary AWS IAM credentials.

Step-by-Step Solution

Implement a user directory and sign-up/sign-in flows using Amazon Cognito User Pools.

Users are authenticated and receive JSON Web Tokens (JWTs) representing their identity.

To verify user identities and manage their authentication status.

Configure an Amazon Cognito Identity Pool and link it to the Cognito User Pool.

The client application can exchange the User Pool JWTs for temporary AWS credentials.

To authorize authenticated users to access AWS services directly.

Assign an IAM Role to the authenticated user group in the Identity Pool with permissions to write to the Amazon S3 bucket.

The temporary AWS credentials grant the necessary permissions to write files directly to Amazon S3.

To enforce fine-grained access control on the target AWS resource.

Key Concept

Distinction between Amazon Cognito User Pools (authentication and identity directory) and Identity Pools (authorization and temporary AWS credentials).

Question 859Question →

A developer is building a mobile game that needs to save user progress data directly to an Amazon DynamoDB table. Users must first authenticate, and the application must then obtain temporary, limited-privilege AWS credentials to authorize write operations to the DynamoDB table. Which Amazon Cognito feature should the developer use to obtain these temporary AWS credentials?

Cognito Identity Pools

Cognito User Pools

Cognito User Pools combined with an API Gateway Lambda Authorizer

Cognito User Pools using hardcoded IAM Access Keys

Show answer & explanation

Answer: Cognito Identity Pools

Answer

Cognito Identity Pools

Cognito Identity Pools (Federated Identities) are specifically designed to authorize users by exchanging authentication tokens (from Cognito User Pools or social providers) for temporary, limited-privilege AWS credentials. This allows mobile applications to call AWS services directly, such as writing to DynamoDB, using the permissions defined in the assumed IAM role.

Step-by-Step Solution

Identify the authentication and authorization requirements.

The application requires authentication to verify identity, and then authorization using temporary AWS credentials to write directly to DynamoDB.

Determining whether the client needs direct AWS resource access versus REST API access helps select the correct Cognito feature.

Differentiate between User Pools and Identity Pools.

Cognito User Pools provide user directories and authentication (JWTs). Cognito Identity Pools provide authorization by exchanging authentication tokens for temporary AWS credentials.

Selecting the feature that specifically generates temporary credentials ensures secure, direct SDK access to AWS services.

Key Concept

Amazon Cognito Identity Pools vs User Pools for AWS resource access

Estimated Time:45s

Question 860Question →

A developer is implementing application-side encryption for sensitive user profile data. When calling the AWS KMS `Encrypt` API, the developer includes an encryption context: `{"AppName": "UserProfileService"}`. The encrypted ciphertext is stored in a database. When the developer later attempts to decrypt this ciphertext using the AWS SDK, how must the encryption context be handled?

The decryption API automatically extracts the plaintext version of the encryption context from the ciphertext payload, so it does not need to be provided in the API call.

The encryption context is only used as a custom metadata tag in AWS CloudTrail for auditing, making its inclusion optional during the decryption process.

The identical encryption context must be passed in the decryption API call; otherwise, AWS KMS will reject the request with an InvalidCiphertextException.

The encryption context serves as a lookup key to retrieve the plaintext data key from Systems Manager Parameter Store to perform local decryption.

Show answer & explanation

Answer: The identical encryption context must be passed in the decryption API call; otherwise, AWS KMS will reject the request with an InvalidCiphertextException.

Answer

The identical encryption context must be passed in the decryption API call; otherwise, AWS KMS will reject the request with an InvalidCiphertextException.

When an encryption context is provided in an AWS KMS encryption request, it is cryptographically bound to the ciphertext as Additional Authenticated Data (AAD). To decrypt the ciphertext, the exact same encryption context (case-sensitive key-value pairs) must be supplied in the decryption request. If the context does not match, AWS KMS cannot decrypt the payload and returns an InvalidCiphertextException error.

Step-by-Step Solution

Analyze how AWS KMS handles encryption context during the `Encrypt` API call.

The encryption context is cryptographically bound to the ciphertext as Additional Authenticated Data (AAD) to ensure integrity.

This establishes that the encryption context is not merely metadata but a vital part of the cryptographic envelope.

Determine the requirements for the subsequent `Decrypt` API call.

The Decrypt request must include the exact same encryption context (key-value pairs) used during encryption.

If there is any mismatch in the keys or values, AWS KMS will fail to authenticate the payload and reject the request with an InvalidCiphertextException.

Key Concept

AWS KMS Encryption Context behaves as Additional Authenticated Data (AAD), requiring an exact, case-sensitive match during Decrypt operations to verify ciphertext integrity.

Estimated Time:1m 30s

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