Examkin

All practice questions

1542 questions

All types1,542Multiple choice782Multiple select746Ordering14
Question 981Question →

A developer is designing a new web application and needs to implement user sign-up, sign-in, and directory management capabilities. Which Amazon Cognito component should the developer use to meet these requirements?

Show answer & explanation

Answer: Amazon Cognito User Pools

Answer

Amazon Cognito User Pools
The correct answer is Amazon Cognito User Pools because they function natively as a user directory, offering built-in workflows for user registration, user authentication, password recovery, and directory management.

Step-by-Step Solution

1
Analyze the core requirements of the application: user sign-up, sign-in, and user directory management.
The application needs an identity provider that can store user credentials, manage user profiles, and issue identity tokens.
This establishes that the task is authentication and identity management.
2
Compare Cognito features against these requirements.
Cognito User Pools provide a serverless user directory, host registration/authentication pages, and issue tokens (ID, access, refresh). Cognito Identity Pools, conversely, provide temporary credentials to access AWS resources.
This clarifies the distinction between user authentication (directories) and resource authorization (credentials).
3
Select the correct component.
Amazon Cognito User Pools satisfies all requirements with minimal configuration.
It matches the target use case perfectly, leaving other components for authorization or custom integration.

Key Concept

Amazon Cognito User Pools are user directories used for authentication (sign-up, sign-in, password reset), whereas Cognito Identity Pools are used for authorization (granting temporary AWS credentials).
Question 982Question →

A developer is configuring an application running on an Amazon EC2 instance that needs to read items from an Amazon DynamoDB table. The developer has created the following trust policy for an IAM role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which TWO steps must the developer complete to enable the application on the EC2 instance to securely access the DynamoDB table without hardcoding credentials?

Select all that apply

Show answer & explanation

Answer: Attach a permissions policy to the IAM role that grants the necessary DynamoDB permissions (such as dynamodb:GetItem).; Associate the IAM role with an IAM instance profile and attach the instance profile to the EC2 instance.

Answer

To securely grant access, the developer must attach a permissions policy with DynamoDB access to the IAM role, and then associate the IAM role with an IAM instance profile and attach it to the EC2 instance.
The correct steps are to attach a permissions policy containing the required DynamoDB permissions to the IAM role, and to associate the role with an IAM instance profile and attach it to the EC2 instance. This combination allows the application on the EC2 instance to assume the role and gain the necessary permissions to read DynamoDB data securely.

Step-by-Step Solution

1
Analyze the trust policy.
The trust policy currently allows the Amazon EC2 service principal to assume the IAM role.
This establishes the trust relationship allowing EC2 instances to use the role.
2
Define and attach the permissions policy.
Create an IAM policy that grants DynamoDB permissions and attach it to the IAM role.
An IAM role must have a permissions policy to define what actions are allowed on resources.
3
Associate the role with the EC2 instance.
Create an IAM instance profile, associate the role with it, and attach the instance profile to the EC2 instance.
EC2 instances cannot assume IAM roles directly; they must do so via an IAM instance profile.

Key Concept

Granting EC2 instances permissions to access AWS services using IAM roles and instance profiles.
Estimated Time:1m 30s
Question 983Question →

A developer has configured a microservice to perform actions in a different AWS account by assuming an IAM role. The microservice's execution role has an IAM policy that allows the sts:AssumeRole action on the target role's ARN. During execution, the microservice fails to assume the target role and receives an AccessDenied error. Which of the following is the most likely cause of this authorization failure?

Show answer & explanation

Answer: The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.

Answer

The trust policy of the target IAM role does not list the microservice's execution role ARN as a trusted principal.
For an identity to successfully assume an IAM role (especially in another account), two conditions must be met: the calling identity must have permission to call sts:AssumeRole on the target role, and the target role's trust policy must list the calling identity as a trusted principal. Since the caller already has the necessary permission policy, the failure is due to the trust policy of the target IAM role missing the caller's execution role ARN as a trusted principal.

Step-by-Step Solution

1
Analyze the IAM role assumption request flow.
The caller (microservice's execution role) calls the AWS Security Token Service (STS) AssumeRole API on the target role.
This establishes that permissions are required on both the caller side (identity-based permission policy) and the callee side (resource-based trust policy).
2
Verify identity-based permissions.
The microservice's execution role already has a policy allowing sts:AssumeRole on the target role.
This rules out a permission failure on the caller's side.
3
Verify resource-based trust policy permissions.
Identify that the target role must have a trust policy granting assume-role permission to the caller principal.
Without the trust policy explicitly listing the caller's ARN, STS rejects the role assumption, causing an AccessDenied error.

Key Concept

IAM AssumeRole Trust Policies
Question 984Question →

An AWS Lambda function is configured to run inside private subnets of a custom VPC. The function needs to call a public external payment gateway API and also write results to an Amazon DynamoDB table. During testing, the function successfully connects to DynamoDB via a VPC gateway endpoint, but the connection attempts to the external payment gateway API consistently fail with connection timeout errors. The Lambda function's execution role has the AWSLambdaVPCAccessExecutionRole policy attached, and its security group allows all outbound traffic. Which two actions must the developer take to resolve the external API connectivity issue?

Select all that apply

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet of the VPC.; Add a route in the private subnets' route table that directs destination 0.0.0.0/0 to the NAT Gateway.

Answer

Deploy a NAT Gateway in a public subnet of the VPC, and add a route in the private subnets' route table directing internet-bound traffic (0.0.0.0/0) to the NAT Gateway.
For an AWS Lambda function inside a VPC to access the public internet, it must be associated with private subnets. The private subnets must have a route in their route table (0.0.0.0/0) pointing to a NAT Gateway that is hosted in a public subnet. The public subnet must have a route to an Internet Gateway.

Step-by-Step Solution

1
Analyze the connectivity issue.
The function can access DynamoDB (via VPC Gateway Endpoint) but times out accessing a public external API, meaning there is no route to the public internet.
Identify if the issue is a networking path limitation or resource configuration.
2
Select the correct NAT gateway deployment.
A NAT Gateway must be provisioned in a public subnet which has internet connectivity.
Lambda functions in private subnets require a NAT Gateway to route traffic to public endpoints.
3
Configure the route table for the private subnets.
A default route (0.0.0.0/0) is added pointing to the NAT Gateway.
Ensure outbound traffic from the private subnet is directed correctly to the NAT Gateway.

Key Concept

VPC Networking for AWS Lambda
Estimated Time:1m 0s
Question 985Question →

A developer is updating a serverless application hosted on AWS Lambda and wants to roll out a new function version using AWS CodeDeploy. The deployment must route 10%10\% of incoming traffic to the new version initially. After a 1010-minute observation period, if no errors are detected by Amazon CloudWatch alarms, all remaining traffic (90%90\%) must be routed to the new version. Which AWS CodeDeploy deployment configuration meets these requirements?

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent10Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent10Minutes
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes shifts 10%10\% of the traffic to the new Lambda version initially, waits for a 1010-minute interval to monitor for errors via CloudWatch alarms, and then routes the remaining 90%90\% of the traffic to the new version.

Step-by-Step Solution

1
Analyze the traffic shifting requirement
The requirement specifies routing 10%10\% of traffic to the new version initially, waiting 1010 minutes, and then shifting all remaining 90%90\% of traffic to the new version.
This traffic shifting pattern describes a canary deployment strategy (an initial small slice of traffic followed by a single promotion of all remaining traffic after a specific delay) rather than a linear or all-at-once deployment.
2
Identify the corresponding AWS CodeDeploy predefined configuration
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes matches the 10%10\% initial traffic split and 1010-minute wait duration.
AWS CodeDeploy provides predefined deployment configurations for Lambda. The Canary configurations specify the percentage to shift and the wait time before shifting the remaining traffic. The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes implements a single 1010-minute step before routing all remaining traffic.

Key Concept

AWS CodeDeploy deployment configurations for AWS Lambda allow developers to gradually shift traffic between versions using Canary or Linear strategies.
Question 986Question →

A developer is deploying a containerized application to an Amazon ECS cluster using the Amazon EC2 launch type. The application, which runs in a container with the `bridge` network mode, is designed to write records to an Amazon DynamoDB table. The developer specifies an IAM role named `DynamoDBWorkerRole` in the `taskRoleArn` parameter of the task definition. This IAM role has a policy that allows `dynamodb:PutItem` on the target table. However, at runtime, the application fails to write to DynamoDB and logs the following error:

`AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/ECSInstanceRole/i-0abcdef123456789 is not authorized to perform: dynamodb:PutItem on resource`

(Note: `123456789012123456789012` is the AWS account ID, and `ECSInstanceRole` is the IAM role associated with the EC2 container instances.)

Which of the following actions will resolve this issue?

Show answer & explanation

Answer: Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.

Answer

Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.
The application failed to write to DynamoDB because the AWS SDK inside the container could not retrieve task credentials, causing it to fall back to the EC2 instance profile role (`ECSInstanceRole`). This fallback happens because the ECS agent is unable to assume the `DynamoDBWorkerRole` due to a misconfigured trust policy. To resolve this, the role's trust relationship must trust `ecs-tasks.amazonaws.com` instead of `ec2.amazonaws.com`.

Step-by-Step Solution

1
Analyze the error message to identify which IAM identity is performing the unauthorized request.
The error shows that `ECSInstanceRole` (the role associated with the EC2 container instance profile) is attempting the `dynamodb:PutItem` action, not the specified `DynamoDBWorkerRole`.
This indicates that the AWS SDK inside the container has fallen back to using the host instance's credentials because it could not retrieve container task credentials.
2
Determine why the task-specific credentials for `DynamoDBWorkerRole` were not provided to the container.
The ECS agent retrieves credentials by assuming the role specified in `taskRoleArn`. If the trust policy of that role does not trust the `ecs-tasks.amazonaws.com` service principal, the ECS agent will fail to assume the role.
ECS tasks require the `ecs-tasks.amazonaws.com` service principal to assume the IAM role defined in the task definition.
3
Evaluate the correct remediation to enable the ECS agent to assume the task role.
Modify the trust policy of `DynamoDBWorkerRole` to allow the `ecs-tasks.amazonaws.com` service principal to perform the `sts:AssumeRole` action.
This allows the ECS agent to assume the role, generate temporary credentials, and inject them into the container's environment.
4
Confirm the destination of the policy for application-level actions like DynamoDB operations.
The application permissions must remain attached to the Task Role (`taskRoleArn`), not the Task Execution Role (`taskExecutionRoleArn`).
The Task Execution Role is only used by the ECS container agent for infrastructure tasks such as pulling images and exporting logs.

Key Concept

ECS Task Role trust relationships and credential provider chain fallback behavior
Estimated Time:3m 0s
Question 987Question →

An engineering team is developing a document management application. The application's frontend is a single-page application (SPA). The backend APIs are deployed on Amazon API Gateway (REST API) with AWS Lambda integrations. The application uses an Amazon Cognito User Pool for user authentication, which includes federated identity providers. The backend Lambda functions must receive the authenticated user's custom department attribute ('custom:department') to authorize document access at the application layer. The developers want to implement a highly performant and secure authorization mechanism that minimizes API calls and operational overhead.

Which solution should the developer implement to meet these requirements?

Show answer & explanation

Answer: Configure an Amazon API Gateway Cognito User Pool Authorizer. Configure the frontend to send the Cognito ID token in the Authorization header of API requests. Access the department attribute in the backend Lambda function via the event parameter at event.requestContext.authorizer.claims['custom:department'].

Answer

Configure an Amazon API Gateway Cognito User Pool Authorizer, configure the frontend to send the Cognito ID token in the Authorization header of API requests, and access the department attribute in the backend Lambda function via the event parameter at event.requestContext.authorizer.claims['custom:department'].
The correct solution uses the built-in API Gateway Cognito User Pool Authorizer along with the Cognito ID token. The ID token natively carries user profile attributes, including the custom department attribute. Once validated by the authorizer, API Gateway automatically injects these claims into the Lambda integration context under the path 'event.requestContext.authorizer.claims'. This fulfills the security and functional requirements without requiring any custom validation code, downstream API queries, or Cognito Identity Pool credential exchanges, thereby minimizing execution latency and operational overhead.

Step-by-Step Solution

1
Select the appropriate Amazon Cognito token type.
Cognito ID tokens contain user identity claims, including custom attributes such as 'custom:department', whereas standard Access tokens do not contain these user-specific directory attributes by default.
Choosing the ID token ensures that the required custom user attributes are sent to the gateway without requiring back-channel API requests to retrieve them.
2
Configure the API Gateway Authorizer.
Create a built-in Cognito User Pool Authorizer on API Gateway and associate it with the REST API resource methods. Set the Authorization header as the token source.
Using the built-in Cognito Authorizer offloads token signature verification and expiration checks to API Gateway, avoiding the operational overhead of managing custom authorizer functions.
3
Extract claims inside the backend Lambda function.
In the backend Lambda handler, read the custom attribute from 'event.requestContext.authorizer.claims["custom:department"]'.
When using a Cognito User Pool Authorizer with API Gateway Lambda proxy integration, the gateway automatically populates the claims from the validated ID token into the request context, allowing the backend to retrieve the attribute with zero database or API lookups.

Key Concept

Amazon API Gateway Cognito User Pool Authorizers natively validate ID tokens and inject user claims, including custom attributes, into the backend Lambda context, avoiding the latency and cost of custom authorizers or downstream user lookup APIs.
Estimated Time:2m 0s
Question 988Question →

A developer is configuring an AWS Lambda function that needs to retrieve files from an Amazon S3 bucket. Which two IAM configurations are required to allow the Lambda function to assume its execution role and read the objects from the bucket? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: A trust policy on the IAM role that grants the "sts:AssumeRole" action to the "lambda.amazonaws.com" service principal.; An IAM permissions policy attached to the IAM role that grants the "s3:GetObject" action on the target S3 bucket resource.

Answer

The correct configurations are: a trust policy on the IAM role that grants the "sts:AssumeRole" action to the Lambda service principal, and an IAM permissions policy attached to the IAM role that grants the "s3:GetObject" action on the target S3 bucket.
The correct options state that a trust policy must grant the "sts:AssumeRole" action to the Lambda service principal, and that a permissions policy must grant the "s3:GetObject" action on the target S3 bucket. Together, these allow the Lambda service to assume the execution role and grant that role the specific permissions needed to retrieve S3 objects.

Step-by-Step Solution

1
Identify the AWS service principal executing the function code.
The service principal is "lambda.amazonaws.com".
This principal must be permitted to assume the execution role via the trust policy.
2
Determine the necessary data access actions and resource boundaries.
The action is "s3:GetObject" and the resource is the specific Amazon S3 bucket ARN.
A permissions policy must be created to grant the role read access to the S3 bucket.
3
Attach both policies to the Lambda execution role.
The trust policy establishes trust with AWS Lambda, and the permissions policy grants S3 read access to the role.
Both policies must be present for the Lambda function to safely execute and access the S3 objects under the security envelope of the role.

Key Concept

IAM execution roles require a trust policy to define the assuming principal (who) and permissions policies to define the allowed actions and resources (what).
Estimated Time:1m 0s
Question 989Question →

A serverless order processing application utilizes an AWS Lambda function to send confirmation emails via a third-party API. The function is also configured to access an Amazon Aurora PostgreSQL database in a private subnet. The developer has configured the Lambda function to run inside the private subnets of the VPC to enable database access.

During testing, the developer observes two issues:
1. The Lambda function fails to connect to the third-party email API.
2. The database connection pool is frequently exhausted, and Lambda execution logs show connection timeouts during concurrent invocations.

Which two actions should the developer take to resolve these issues?

Select all that apply

Show answer & explanation

Answer: Initialize the database connection client outside the Lambda handler function to enable connection reuse across invocations.; Provision a NAT Gateway in a public subnet, and configure the route table of the Lambda private subnets to route outbound internet traffic through the NAT Gateway.

Answer

To resolve the issues, the developer must initialize the database connection client outside the Lambda handler function to enable connection reuse, and provision a NAT Gateway in a public subnet to route outbound internet traffic from the private subnets.
The correct solution involves reusing database connections by instantiating the client outside the handler, and establishing internet connectivity for the private subnet using a NAT Gateway.

Step-by-Step Solution

1
Analyze the connectivity failure to the third-party email API.
Recognize that because the Lambda function is placed in a private subnet within a VPC to access Aurora, it lacks access to the public internet by default.
VPC-associated Lambda functions require a NAT Gateway or NAT Instance in a public subnet, with appropriate route tables, to establish outbound connections to external endpoints.
2
Diagnose the database connection pool exhaustion.
Identify that the database client initialization code is situated inside the handler function.
Placing the connection logic inside the handler function forces Lambda to create a new database connection on every single invocation, rapidly depleting the database's available connections. Placing it outside the handler allows subsequent invocations in the same execution environment to reuse the connection.
3
Apply the VPC routing and code updates.
Create the NAT Gateway in a public subnet, add a route in the private subnet route table pointing `0.0.0.0/0` traffic to the NAT Gateway, and refactor the Lambda code to instantiate the database client during the initialization phase.
This combined approach resolves both the internet egress restriction and the connection leak under load.

Key Concept

Troubleshooting VPC egress routing for Lambda functions and optimizing resource utilization through execution context reuse.
Question 990Question →

An organization is containerizing a legacy session manager and deploying it as a task on Amazon ECS with the AWS Fargate launch type. The application code requires permissions to write session state directly to an Amazon DynamoDB table. Additionally, the task's container image is hosted within a private Amazon Elastic Container Registry (ECR) repository. The developer needs to establish the correct IAM permissions for both the ECS container agent and the application itself to run successfully.

Which of the following configuration steps must the developer perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the ECS Task Role with an IAM policy that allows the `dynamodb:PutItem` action.; Configure the ECS Task Execution Role with an IAM policy that allows the `ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage` actions.

Answer

To configure the task successfully, the ECS Task Role must be configured with permission to write to DynamoDB (`dynamodb:PutItem`), and the ECS Task Execution Role must be configured with permissions to pull the image from ECR (`ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage`).
The correct configurations are: 1. Setting the ECS Task Role with an IAM policy that allows the application code to write to DynamoDB (`dynamodb:PutItem`). The Task Role is designed specifically to provide permissions to the application running inside the container. 2. Setting the ECS Task Execution Role with an IAM policy that allows the ECS container agent to pull images from ECR (`ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage`). The Task Execution Role is used by the ECS container agent to perform lifecycle tasks on behalf of the container before the application begins running.

Step-by-Step Solution

1
Determine which role is used by the ECS container agent to perform infrastructure actions.
The ECS Task Execution Role is identified as the role used by the ECS agent to pull container images from ECR and write logs to CloudWatch.
The ECS container agent runs outside the user container and requires separate credentials to interact with AWS services before the container starts.
2
Determine which role is used by the application code running inside the container.
The ECS Task Role is identified as the role that provides temporary AWS credentials to the application code container.
The application code uses the AWS SDK to write data to DynamoDB, so the permission must be attached to the Task Role.
3
Verify the trust policy of both roles to ensure they can be assumed by ECS.
The trust policy for both roles must allow the Amazon ECS Task service (`ecs-tasks.amazonaws.com`) to assume the role.
If the trust policy is misconfigured (e.g., set to EC2 instead of ECS Tasks), ECS will not be able to assume the roles, and the task will fail to launch.

Key Concept

Delineation between the ECS Task Role (granting permissions to the application code inside the container) and the ECS Task Execution Role (granting permissions to the ECS agent/daemon to pull images and push logs).
Question 991Question →

A developer is designing a web application that will be hosted on Amazon ECS. The application requires a shared session state store to support horizontal scaling of container instances. The session data consists of semi-structured JSON documents that are updated frequently with each user request. The session documents must automatically expire and be deleted after 24 hours of inactivity to keep storage costs low. Which solution meets these requirements with the lowest operational overhead?

Show answer & explanation

Answer: Store the session data in an Amazon DynamoDB table, and enable DynamoDB Time to Live (TTL) on an attribute containing the expiration timestamp.

Answer

Store the session data in an Amazon DynamoDB table, and enable DynamoDB Time to Live (TTL) on an attribute containing the expiration timestamp.
Storing session data in Amazon DynamoDB and enabling Time to Live (TTL) provides a fully managed, highly scalable solution. DynamoDB automatically deletes expired items based on a timestamp attribute without consuming provisioned throughput or requiring custom application logic.

Step-by-Step Solution

1
Evaluate the session state storage requirements: high-frequency writes, semi-structured documents, automatic expiration, and low operational overhead.
Amazon DynamoDB is identified as a suitable NoSQL database because it natively supports JSON documents and auto-scaling, and offers a built-in Time to Live (TTL) feature.
DynamoDB TTL automatically deletes expired items based on an epoch timestamp attribute without consuming any read or write capacity units.
2
Assess alternative deletion mechanisms like a scheduled AWS Lambda function running a DynamoDB Scan.
The Scan-and-delete approach is rejected because Scan operations scan the entire database table, leading to high resource utilization and cost.
Using Scan violates the requirement for low operational overhead and cost efficiency.
3
Evaluate using Systems Manager Parameter Store and a static partition key design in DynamoDB.
Parameter Store is rejected due to API throttling limits, and the static key design is rejected because it creates a hot partition.
These solutions fail to scale horizontally and lead to performance degradation under load.

Key Concept

Session State Management using Amazon DynamoDB and Time to Live (TTL)
Question 992Question →

An application downloads a 150 KB150\text{ KB} encrypted payload and its corresponding encrypted data key from an Amazon S3 bucket. The payload was encrypted client-side using envelope encryption with an AWS KMS customer managed key. Which of the following workflows should the developer implement in the application code to decrypt the payload?

Show answer & explanation

Answer: Send the encrypted data key to the AWS KMS Decrypt API operation to retrieve the plaintext data key, decrypt the payload locally using the plaintext key, and then delete the plaintext key from memory.

Answer

Send the encrypted data key to the AWS KMS Decrypt API operation to retrieve the plaintext data key, decrypt the payload locally using the plaintext key, and then delete the plaintext key from memory.
The correct workflow involves calling the KMS Decrypt API operation with the encrypted data key. Because direct KMS cryptographic operations are capped at 4096 bytes4096\text{ bytes} (4 KB4\text{ KB}), a 150 KB150\text{ KB} payload cannot be decrypted directly by KMS. Instead, the application must delegate the decryption of the small data key to KMS. Once the plaintext data key is returned, the actual data payload is decrypted locally using cryptographic libraries in the application code, and the plaintext data key is discarded from memory.

Step-by-Step Solution

1
Call the AWS KMS Decrypt API passing the encrypted data key.
AWS KMS decrypts the data key and returns the plaintext data key along with the KMS key ARN.
The ciphertext payload is too large (150 KB150\text{ KB}) to be decrypted directly by KMS, which has a limit of 4 KB4\text{ KB} for direct operations.
2
Use the plaintext data key to decrypt the payload locally in memory.
The plaintext version of the 150 KB150\text{ KB} payload is recovered.
Client-side decryption must occur locally using the symmetric key (the plaintext data key) generated during the initial encryption process.
3
Erase the plaintext data key from memory as soon as decryption is complete.
The plaintext data key is destroyed.
This is a security best practice to prevent the plaintext key from remaining in application memory longer than necessary.

Key Concept

KMS Envelope Decryption Workflow
Estimated Time:1m 30s
Question 993Question →

A backend service uses an AWS Lambda function to process 15 MB15\text{ MB} data files uploaded to Amazon S3. During execution, the function stops processing before completing, and the Amazon CloudWatch logs report that the function reached its configured execution limit of 15 seconds15\text{ seconds}. Which action should the developer take to resolve this issue?

Show answer & explanation

Answer: Increase the timeout configuration parameter of the Lambda function.

Answer

Increase the timeout configuration parameter of the Lambda function.
The correct action is to increase the timeout configuration of the Lambda function. When a Lambda function hits its configured execution limit, AWS Lambda terminates the container. If the workload simply requires more time to run (e.g., parsing a larger file), the configuration must be updated to a higher timeout value.

Step-by-Step Solution

1
Analyze the error message from the CloudWatch logs.
The log indicates the function timed out after 15 seconds15\text{ seconds}, which is its currently configured maximum execution limit.
Understanding the failure symptom shows that the execution is aborted by AWS Lambda because the processing time exceeded the timeout configuration.
2
Evaluate the workload requirements.
Processing a 15 MB15\text{ MB} file requires more CPU time and network transfer time than the default 15 seconds15\text{ seconds} configuration allows.
Determining if the code is stuck in an infinite loop or simply needs more time to run is necessary to choose the correct remediation step.
3
Adjust the Lambda function configuration.
Increase the timeout setting (up to the maximum limit of 15 minutes15\text{ minutes}) to accommodate the processing time of larger files.
Modifying the configuration settings allows the function to execute longer without being terminated mid-process.

Key Concept

AWS Lambda execution timeout configuration
Question 994Question →

A developer is configuring an in-place deployment in AWS CodeDeploy for an application running on an Auto Scaling group with 1010 Amazon EC2 instances. To prevent performance degradation during peak hours, the application must maintain at least 60%60\% of its capacity (66 instances) to serve traffic at all times during the deployment. The developer also wants to complete the deployment in the shortest time possible. Which deployment configuration should the developer use to meet these requirements?

Show answer & explanation

Answer: Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%.

Answer

Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%.
The correct option is the custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%. This ensures that at least 66 instances (which is 60%60\% of 1010 instances) remain healthy and serving traffic throughout the deployment. Consequently, CodeDeploy can update up to 44 instances concurrently, minimizing the total deployment duration while satisfying the capacity constraint.

Step-by-Step Solution

1
Calculate the number of healthy instances required during the deployment.
The application requires at least 60%60\% of 1010 instances to be healthy, which equals 10×0.60=610 \times 0.60 = 6 healthy instances.
This establishes the minimum capacity baseline that must be maintained.
2
Determine the maximum number of instances that can be updated concurrently.
Maximum updating instances = Total instances - Minimum healthy instances = 10−6=410 - 6 = 4 instances.
To complete the deployment in the shortest time, we must update the maximum allowable number of instances concurrently.
3
Evaluate the predefined CodeDeploy configurations against the constraints.
HalfAtATime updates 55 instances (leaving 55 healthy, violating the limit). OneAtATime updates 11 instance (taking too long). AllAtOnce updates all 1010 (violating the limit).
Predefined configurations do not optimize for updating exactly 44 instances at a time while keeping 66 healthy.
4
Define the custom configuration parameters.
A custom configuration with minimum healthy hosts set to a fleet percentage of 60%60\% (or a host count of 66) is required.
Setting the minimum healthy hosts to a fleet percentage of 60%60\% ensures exactly 66 instances remain healthy, permitting 44 instances to update concurrently, thus meeting both capacity and speed constraints.

Key Concept

AWS CodeDeploy deployment configurations and minimum healthy hosts parameters.
Question 995Question →

A developer is preparing an AppSpec file for an Amazon ECS deployment using AWS CodeDeploy. The developer needs to define lifecycle hooks to validate the deployment before routing production traffic to the new task set. What target type must the developer specify in the AppSpec file to execute the validation tests?

Show answer & explanation

Answer: An AWS Lambda function

Answer

An AWS Lambda function
For Amazon ECS deployments, CodeDeploy lifecycle hooks (such as BeforeAllowTraffic and AfterAllowTraffic) must target an AWS Lambda function. The Lambda function runs the validation code and calls the CodeDeploy API to report success or failure.

Step-by-Step Solution

1
Identify the target compute platform for the CodeDeploy deployment.
The target platform is Amazon ECS.
CodeDeploy handles lifecycle hooks differently depending on whether the target platform is EC2/on-premises versus ECS/Lambda.
2
Determine how validation tests are executed on the Amazon ECS platform.
ECS deployments use AWS Lambda functions to execute validation code for lifecycle hooks.
Because containers in ECS tasks cannot run arbitrary local host scripts during CodeDeploy lifecycle transitions, a Lambda function must be used to perform checks like BeforeAllowTraffic.

Key Concept

AWS CodeDeploy lifecycle hooks for Amazon ECS require AWS Lambda functions to execute validation tests.
Estimated Time:1m 0s
Question 996Question →

A developer has configured an AWS Lambda function in AWS Account A to send messages to an Amazon Simple Queue Service (Amazon SQS) queue located in AWS Account B. During execution, the Lambda function fails with an AccessDenied error when attempting to write to the queue. Which two actions are required to resolve this authorization failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a policy to the Lambda function's IAM execution role in Account A that allows the sqs:SendMessage action on the queue in Account B.; Update the SQS queue policy in Account B to grant the Lambda function's IAM execution role in Account A permission to perform the sqs:SendMessage action.

Answer

Add a policy to the Lambda function's IAM execution role in Account A that allows the sqs:SendMessage action on the queue in Account B, and update the SQS queue policy in Account B to grant the Lambda function's IAM execution role in Account A permission to perform the sqs:SendMessage action.
The correct answers describe the two necessary steps for cross-account resource access: granting identity-based permissions to the caller's IAM execution role in the source account and granting resource-based permissions in the queue's policy in the target account to allow access from that execution role principal.

Step-by-Step Solution

1
Add the appropriate SQS permission to the Lambda execution role.
The execution role in Account A now has identity-based permission to call sqs:SendMessage on the SQS queue in Account B.
For cross-account access, the requesting identity must explicitly be allowed to perform the action in its own policy.
2
Add permissions to the SQS queue resource policy.
The SQS queue policy in Account B allows the execution role ARN from Account A to perform sqs:SendMessage.
Cross-account access requires explicit permission on the resource-based policy of the target resource to allow access from an external account.

Key Concept

Cross-account resource access requires authorization in both the caller's IAM identity-based policy and the target's resource-based policy.
Estimated Time:1m 0s
Question 997Question →

A developer is building a serverless web application that allows users to sign in and upload files directly to an Amazon S3 bucket. The application must support user registration and sign-in, and provide temporary AWS credentials to authenticated users for S3 uploads. Which two Amazon Cognito features should the developer configure to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Amazon Cognito User Pools to manage user registration, authentication, and directory services; Amazon Cognito Identity Pools to authorize users and obtain temporary AWS credentials for S3 access

Answer

Amazon Cognito User Pools to manage user registration, authentication, and directory services, and Amazon Cognito Identity Pools to authorize users and obtain temporary AWS credentials for S3 access.
To support user sign-up and authentication, a Cognito User Pool is required. To authorize the users and grant temporary AWS credentials for direct S3 upload access, a Cognito Identity Pool is required.

Step-by-Step Solution

1
Determine the service needed for user authentication and directory management.
Amazon Cognito User Pools provides the directory and authentication features required for user registration and sign-in.
User Pools handle authentication and act as the identity provider.
2
Determine the service needed to access AWS resources directly from the client.
Amazon Cognito Identity Pools (federated identities) allows exchanging authentication tokens for temporary AWS IAM credentials.
Identity Pools manage authorization and provide credentials for AWS resources like Amazon S3.

Key Concept

Cognito User Pools authenticate users and manage directories, while Cognito Identity Pools authorize users to access AWS resources by issuing temporary credentials.
Question 998Question →

An application uses an AWS Lambda function associated with private subnets of a VPC to perform write operations on an Amazon RDS PostgreSQL database. The function also needs to write tracking data to an Amazon DynamoDB table, but the write operations to DynamoDB are failing with connection timeout errors. Which two actions should a developer take to resolve this connectivity issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a Gateway VPC Endpoint for Amazon DynamoDB and associate it with the route table used by the Lambda function's subnets.; Deploy a NAT Gateway in a public subnet of the VPC, and add a route pointing to it in the private subnet's route table.

Answer

To resolve the connection timeout issue, the developer must either create a Gateway VPC Endpoint for Amazon DynamoDB and associate it with the private subnet's route table, or deploy a NAT Gateway in a public subnet and route the private subnet's internet-bound traffic through it.
The Lambda function is failing to reach the public DynamoDB endpoint because it is running inside private subnets of a VPC without access to public endpoints. The two correct options resolve this: one by establishing a Gateway VPC Endpoint that routes DynamoDB traffic internally, and the other by establishing a NAT Gateway in a public subnet to allow outbound internet access for resources in private subnets.

Step-by-Step Solution

1
Analyze the error symptom.
The Lambda function is experiencing connection timeout errors, indicating a network routing block rather than an IAM permission (AccessDenied) block.
Correctly identifying the nature of the error prevents unnecessary IAM configuration changes and focuses troubleshooting on VPC routing.
2
Evaluate the current network configuration.
The Lambda function resides in private VPC subnets to access RDS. Private subnets do not have direct access to the public internet where DynamoDB resides.
Understanding the isolation of private subnets explains why traffic cannot reach DynamoDB without a gateway helper.
3
Select valid network routing solutions.
A Gateway VPC Endpoint or a NAT Gateway allows private subnet traffic to reach DynamoDB.
A Gateway VPC Endpoint routes traffic to DynamoDB internally within the AWS network, while a NAT Gateway routes traffic to public endpoints via a public subnet.

Key Concept

VPC Networking for AWS Lambda Functions
Estimated Time:1m 30s
Question 999Question →

A developer is containerizing a Python microservice that uses the AWS SDK (Boto3) to retrieve objects from an Amazon S3 bucket. During local development on a macOS host, the developer runs the application in a Docker container using Docker Desktop. The container fails to authenticate with AWS and throws a `NoCredentialsError`. The host machine's AWS CLI is configured with a default profile and a named profile `local-dev` that contains active credentials.

Which TWO actions should the developer perform to resolve this authentication failure and allow the containerized application to use the `local-dev` credentials? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Mount the host machine's ~/.aws directory to the home directory of the user running inside the container (e.g., /root/.aws) and set the AWS_PROFILE environment variable to local-dev in the container runtime environment.; Pass the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables from the host's active shell session directly into the container using container runtime environment flags.

Answer

Mount the host machine's credentials directory while setting the profile environment variable, or pass the active shell credential environment variables to the container at runtime.
The correct options provide valid, secure mechanisms to supply credentials to a local container without exposing secrets. Mounting the host's credential directory (~/.aws) into the container's user directory combined with the profile variable allows the SDK to resolve credentials from the configuration file. Alternatively, injecting active environment variables into the container environment allows the SDK's credential provider chain to resolve credentials from environment variables directly.

Step-by-Step Solution

1
Analyze the environment boundary.
The containerized application is isolated from the host's files and environment variables, resulting in the Boto3 SDK being unable to find any credentials in its default search path.
By default, Docker containers do not share the host's home directory or environment variables where AWS credentials are configured.
2
Evaluate configuration mounting options.
Mounting the host's ~/.aws folder to the container's user home directory makes the configuration and credentials files visible to Boto3.
Setting the AWS_PROFILE environment variable inside the container to 'local-dev' instructs Boto3 to read from the mounted named profile rather than falling back to the default profile.
3
Evaluate environment variables injection options.
Passing AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN environment variables into the container environment allows Boto3 to load credentials directly.
Environment variables are evaluated first in the AWS SDK default credentials provider chain, overriding other local file configuration paths.

Key Concept

AWS SDK Default Credentials Provider Chain in Container Environments
Question 1000Question →

A developer is implementing authorization for an Amazon API Gateway REST API. The API serves as the backend for a web application where users register and log in directly using Amazon Cognito. The developer needs to validate the JSON Web Tokens (JWT) sent in the HTTP authorization header for each request. The solution should minimize both custom development effort and operational overhead. Which of the following approaches should the developer choose to secure the API?

Show answer & explanation

Answer: Deploy a native Amazon Cognito authorizer on the API Gateway REST API resources to validate the incoming tokens.

Answer

Deploy a native Amazon Cognito authorizer on the API Gateway REST API resources to validate the incoming tokens.
Deploying a native Amazon Cognito authorizer is the correct approach. API Gateway provides built-in integration with Cognito User Pools. By configuring a Cognito authorizer, API Gateway automatically validates the signature and expiration of the JWT before forwarding the request to the integration backend. This requires zero custom code, minimizes developer effort, and lowers latency and costs.

Step-by-Step Solution

1
Identify the authentication source
The identity source is Amazon Cognito User Pools, which issues standard JSON Web Tokens (JWT) upon successful authentication.
This determines which authorization methods are compatible with the token type.
2
Evaluate the architectural constraints
The solution must minimize custom development effort and operational overhead.
This rules out options that require writing custom authorizer code or backend validation logic.
3
Select the native API Gateway capability
API Gateway has a built-in Cognito User Pools authorizer that handles JWT validation natively.
A native authorizer requires no custom code, lowering operational overhead and automatically rejecting unauthorized requests before they reach backend integrations.

Key Concept

Amazon API Gateway Cognito User Pools Authorizer
Estimated Time:1m 30s
PreviousPage 50 / 78Next
All practice questions — AWS Certified Developer - Associate | Examkin