Examkin

All practice questions

1542 questions

All types1,542Multiple choice782Multiple select746Ordering14
Question 1201Question →

An application team is deploying a containerized API to Amazon ECS using the AWS Fargate launch type. The application code needs to retrieve operational parameters from Amazon DynamoDB during runtime. Additionally, the ECS agent must retrieve database credentials from AWS Secrets Manager to configure the application's environment variables before the container starts. Which configuration will allow the application to start and run successfully with the least privilege?

Show answer & explanation

Answer: Configure the ECS Task Role with permissions for dynamodb:GetItem and the ECS Task Execution Role with permissions for secretsmanager:GetSecretValue, and configure the trust policy of both roles to trust the ecs-tasks.amazonaws.com service principal.

Answer

Configure the ECS Task Role with permissions for dynamodb:GetItem, the ECS Task Execution Role with permissions for secretsmanager:GetSecretValue, and configure both roles to trust the ecs-tasks.amazonaws.com service principal.
The correct configuration assigns DynamoDB permissions to the ECS Task Role and Secrets Manager permissions to the ECS Task Execution Role, while setting the trust policy of both roles to trust the ecs-tasks.amazonaws.com service principal. This separates responsibilities: the Task Execution Role allows the ECS agent to prepare the container environment (including resolving environment variables from Secrets Manager), while the Task Role gives the running containerized application the temporary AWS credentials it needs to perform DynamoDB API operations.

Step-by-Step Solution

1
Identify the role needed for application code runtime permissions.
The ECS Task Role is selected for DynamoDB operations.
The application code runs inside the container and requires access to DynamoDB during its execution lifecycle.
2
Identify the role needed for container agent startup and configuration permissions.
The ECS Task Execution Role is selected to fetch secrets from AWS Secrets Manager.
The ECS container agent runs outside the user container and must retrieve credentials to expose them as environment variables before the container starts.
3
Verify the correct IAM trust policy service principal.
Set the trust policy service principal to ecs-tasks.amazonaws.com for both roles.
ECS tasks require the task-specific service principal to assume the execution and task roles, rather than the core ECS service principal.

Key Concept

Amazon ECS IAM Roles Separation (Task Role vs Task Execution Role)
Question 1202Question →

A developer is refactoring a web application that runs on an Auto Scaling group of Amazon EC2 instances. The application currently stores user session state in the memory of individual instances, which causes users to lose their sessions when the Auto Scaling group scales in. The session data contains nested JSON objects representing user preferences and search history. The developer wants to store these sessions in a shared, highly available cache that supports automatic expiration of idle sessions after 30 minutes. Which solution meets these requirements with the best performance and lowest operational overhead?

Show answer & explanation

Answer: Configure an Amazon ElastiCache for Redis cluster to store the session state, and set a Time to Live (TTL) of 1800 seconds on the session keys.

Answer

Configure an Amazon ElastiCache for Redis cluster to store the session state, and set a Time to Live (TTL) of 1800 seconds on the session keys.
Storing session state in an Amazon ElastiCache for Redis cluster is an ideal solution. Redis is an in-memory data store that offers sub-millisecond latency, supports complex data structures (like nested JSON, lists, and sets), and provides native key expiration (TTL) which can be set to 1800 seconds (30 minutes) to automatically expire idle sessions.

Step-by-Step Solution

1
Analyze the application requirements.
The solution must support shared, highly available session storage, support complex/nested data structures (nested JSON objects), and automatically expire sessions after 30 minutes (1800 seconds) with the lowest latency and operational overhead.
This establishes the criteria for selecting the appropriate service and configuration.
2
Evaluate the storage and caching options against these criteria.
Systems Manager Parameter Store is not designed for session state. Storing sessions in DynamoDB with a manual Scan-based cleanup is inefficient. Scaling up DynamoDB capacity manually is costly and does not manage session expiration. ElastiCache for Redis supports in-memory speed, complex data structures, and native TTL expiration.
This eliminates the incorrect architectural patterns and identifies the correct service.
3
Determine the correct configuration for the chosen service.
An ElastiCache for Redis cluster with a key TTL of 1800 seconds (30 minutes) satisfies all requirements.
This defines the final implementation details for the session caching mechanism.

Key Concept

The core concept is offloading session state management from application servers (EC2 instances) to a shared, high-performance in-memory cache like Amazon ElastiCache for Redis, which natively supports complex data types and key expiration (TTL) to handle session lifetimes.
Question 1203Question →

A mobile gaming application writes daily player high scores to an Amazon DynamoDB table. Although the table's total provisioned write capacity is significantly higher than the aggregate write rate, the application frequently experiences ProvisionedThroughputExceededException errors because all writes use the current date (e.g., YYYY-MM-DD) as the partition key. Which action should the developer take to resolve this throttling issue?

Show answer & explanation

Answer: Change the partition key design to combine the date with a random numerical suffix to distribute write requests across multiple partitions.

Answer

Change the partition key design to combine the date with a random numerical suffix to distribute write requests across multiple partitions.
The correct answer is to modify the partition key design to include a random numerical suffix. This technique, known as write sharding, distributes the writes for a single day across multiple partition keys (e.g., YYYY-MM-DD.1, YYYY-MM-DD.2), thereby distributing the physical partition load and preventing ProvisionedThroughputExceededException errors.

Step-by-Step Solution

1
Identify the cause of the throttling.
The application is encountering ProvisionedThroughputExceededException despite having high total provisioned capacity, indicating a hot partition key issue because all writes target the same partition key (the current date).
DynamoDB partitions data based on the partition key. If too many writes target the same key, that physical partition gets throttled regardless of the table's total provisioned throughput.
2
Select a solution that increases partition key entropy.
Add a random or calculated suffix (e.g., a number from 1 to N) to the date partition key.
This spreads the write requests across multiple distinct partition keys, distributing the workload across multiple physical partitions.

Key Concept

Resolving hot partition keys in Amazon DynamoDB by introducing write sharding (adding a random suffix) to distribute the load across multiple physical partitions.
Question 1204Question →

A developer is troubleshooting an AWS Lambda function written in Python that processes transaction records. The function intermittently fails with a memory limit exceeded error after running successfully for several hours under continuous traffic. The developer reviews the code and notes that a helper class initializes an in-memory cache list in the global scope, outside the handler function, to store transaction IDs. Which of the following is the most likely cause of this issue and the correct resolution?

Show answer & explanation

Answer: The Lambda execution environment is being reused across multiple invocations, causing the global transaction ID cache list to grow indefinitely. To resolve this, the developer should initialize the cache list inside the handler function so it is cleared for each request.

Answer

The Lambda execution environment is being reused across multiple invocations, causing the global transaction ID cache list to grow indefinitely. To resolve this, the developer should initialize the cache list inside the handler function so it is cleared for each request.
The correct option is correct because AWS Lambda reuses execution environments (warm starts) to improve latency. Objects declared in the global scope (outside the handler function) persist across these invocations. Since the transaction ID cache list is global and items are continuously added to it without being cleared, the memory footprint increases over time, eventually exceeding the configured memory limit. Initializing the list inside the handler ensures it is scoped to a single invocation and garbage collected afterward.

Step-by-Step Solution

1
Analyze the symptom where the memory limit is exceeded only after running successfully for several hours under continuous traffic.
This indicates a progressive memory leak that accumulates across multiple invocations rather than a failure on the first execution.
AWS Lambda optimizes performance by keeping execution environments warm and reusing them for subsequent requests.
2
Inspect the code structure to locate the global variable declaration.
The in-memory cache list is declared in the global scope (outside the handler function).
State stored in global variables persists across invocations in reused execution environments.
3
Determine the resolution to prevent the list from growing across warm starts.
Declare the cache list inside the handler function or explicitly clear it at the beginning of each handler execution.
This guarantees that the list starts empty for every request, preventing memory accumulation.

Key Concept

Lambda Execution Context Reuse and Global State
Estimated Time:1m 30s
Question 1205Question →

A developer is troubleshooting a CloudWatch Logs subscription filter that streams log events from a Lambda function's log group to an Amazon Kinesis Data Firehose delivery stream. The delivery stream successfully writes data to an Amazon S3 bucket, but the developer notices that no logs from the subscription filter are arriving in S3. The CloudWatch metric DeliveryErrors for the subscription filter shows a consistently high count. The developer verifies that the Firehose delivery stream is active and that the IAM role specified in the subscription filter has a permissions policy allowing firehose:PutRecord and firehose:PutRecordBatch on the delivery stream. Which of the following is the most likely cause of this issue?

Show answer & explanation

Answer: The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.

Answer

The trust policy of the IAM role specified in the subscription filter does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity.
To stream logs via a subscription filter, CloudWatch Logs must assume the IAM role specified in the subscription filter to write events to Kinesis Data Firehose. If the trust policy of that IAM role does not list the CloudWatch Logs service principal (logs.amazonaws.com) as a trusted entity, the sts:AssumeRole call fails, preventing logs from being delivered and causing DeliveryErrors.

Step-by-Step Solution

1
Identify the component failing in the log delivery pipeline.
The DeliveryErrors metric for the CloudWatch Logs subscription filter is high, indicating that CloudWatch Logs is unable to write the log events to Kinesis Data Firehose.
Understanding where the failure occurs helps narrow down whether the issue lies within Firehose configuration, IAM permissions, or subscription filter setup.
2
Analyze the IAM permission requirements for CloudWatch Logs subscription filters.
For CloudWatch Logs to push log data to Kinesis Data Firehose, it must assume the IAM role provided in the subscription filter.
This transition requires an sts:AssumeRole operation, which relies on the role's trust policy.
3
Evaluate the trust relationship of the IAM role.
The trust policy of the IAM role must permit the logs.amazonaws.com service principal to assume it.
If the trust policy incorrectly trusts firehose.amazonaws.com or lacks the logs service principal entirely, the assume-role request fails, resulting in delivery errors.

Key Concept

IAM Role Trust Relationships for CloudWatch Logs Subscription Filters
Question 1206Question →

A developer is troubleshooting a Java application running on Amazon ECS Fargate that receives HTTP requests and uses the AWS SDK for Java to write metadata to an Amazon DynamoDB table. The developer runs the AWS X-Ray daemon as a sidecar container in the ECS task. The X-Ray daemon logs confirm that it is successfully receiving trace segments and uploading them to AWS X-Ray. However, in the X-Ray trace map, the downstream calls to DynamoDB do not appear. Which action should the developer take to ensure DynamoDB calls are included in the trace?

Show answer & explanation

Answer: Configure the AWS SDK client in the Java application using the X-Ray SDK's TracingInterceptor to instrument downstream service calls.

Answer

Configure the AWS SDK client in the Java application using the X-Ray SDK's TracingInterceptor to instrument downstream service calls.
To include downstream calls in an AWS X-Ray trace, the application's AWS SDK client must be instrumented. For Java applications, this is done by adding the X-Ray SDK's TracingInterceptor to the AWS SDK client configuration, which automatically creates subsegments for each downstream service call.

Step-by-Step Solution

1
Analyze the daemon logs to verify trace collection functionality.
The daemon logs show that the sidecar container is active, receiving traces locally, and successfully uploading segments to AWS X-Ray.
This rules out daemon configuration or network path issues from the ECS container to the X-Ray service.
2
Identify why downstream DynamoDB calls are missing from the trace map.
The AWS SDK client itself has not been instrumented with the AWS X-Ray SDK.
By default, the AWS SDK does not record subsegments for X-Ray. The client must be explicitly instrumented using the TracingInterceptor.
3
Configure the AWS SDK client with the TracingInterceptor.
Downstream calls automatically include tracing headers and generate subsegments.
Adding TracingInterceptor to the AWS SDK client builder allows X-Ray to track calls made to DynamoDB.

Key Concept

AWS SDK Client Instrumentation with AWS X-Ray SDK
Question 1207Question →

A developer needs to monitor an AWS Lambda function that occasionally times out during execution. The developer wants to count the occurrences of these timeouts and receive an alert when they happen. Which of the following steps should the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a CloudWatch Logs metric filter on the function's log group with the filter pattern "Task timed out" to increment a custom metric.; Create a CloudWatch Alarm based on the custom metric generated by the metric filter to send an alert when the threshold is exceeded.

Answer

Create a CloudWatch Logs metric filter with the pattern "Task timed out" on the function's log group and configure a CloudWatch Alarm based on the resulting metric.
To monitor and alarm on specific log statements, a developer must create a metric filter on the CloudWatch Logs log group associated with the log source (such as the Lambda log group /aws/lambda/<function-name>). When Lambda times out, it logs a standard message containing the phrase "Task timed out". Creating a metric filter with the pattern "Task timed out" will match this phrase and increment a custom metric. The developer can then associate a CloudWatch Alarm with this custom metric to send alerts when the failure count exceeds thresholds.

Step-by-Step Solution

1
Identify the log group associated with the Lambda function and the exact log phrase indicating a timeout.
The log group is /aws/lambda/<function-name> and the timeout log phrase is "Task timed out".
This identifies the target log source and the search criteria needed for tracking timeouts.
2
Configure a metric filter on the identified log group with the pattern "Task timed out".
A custom metric is generated and incremented whenever a log matches the pattern.
This extracts the text pattern from the raw log stream into a numeric time-series metric.
3
Create a CloudWatch Alarm that monitors the custom metric.
An alarm is created to trigger alerts (e.g., via SNS) when the count exceeds the defined threshold.
This establishes the alerting mechanism to notify the developer when timeouts occur.

Key Concept

Using CloudWatch Logs metric filters to extract metrics from plain text log streams and alarming on them.
Question 1208Question →

A developer attempts to deploy a new stack named `prod-app-backend` using AWS CloudFormation. The initial stack creation fails due to a syntax error in the resource properties, and the stack status transitions to `ROLLBACK_COMPLETE`. After correcting the syntax error in the template, the developer tries to perform a stack update using the corrected template and the same stack name, but the update fails. Which action must the developer take to deploy the stack successfully?

Show answer & explanation

Answer: Delete the stack and recreate it using the updated template.

Answer

Delete the stack and recreate it using the updated template.
When a CloudFormation stack fails its initial creation, it rolls back all resources and transitions to `ROLLBACK_COMPLETE`. A stack in this state cannot be updated because it was never successfully created. To deploy the stack with the same name, the developer must first delete the existing stack and then create a new one using the corrected template.

Step-by-Step Solution

1
Identify the current state of the stack.
The stack is in the `ROLLBACK_COMPLETE` state after a failed initial creation attempt.
CloudFormation stacks that fail their initial creation roll back and enter this state. They contain no successfully deployed resources.
2
Determine if an update operation is supported.
Update operations are rejected by CloudFormation for stacks in the `ROLLBACK_COMPLETE` state that resulted from a failed creation.
Since the stack was never successfully created in the first place, there is no active baseline to update.
3
Perform the required cleanup and redeployment.
Delete the failed stack to release the stack name, then run the creation process with the corrected template.
Deleting the stack removes the metadata entry in CloudFormation, allowing a new stack with the same name to be created successfully.

Key Concept

CloudFormation Stack Lifecycle and Rollback States
Estimated Time:1m 30s
Question 1209Question →

A developer is implementing a serverless payment microservice using AWS Lambda. The microservice needs to securely access a third-party API key that must be rotated every 90 days. Which solution should the developer implement to manage and rotate this API key with the lowest operational overhead?

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager. Configure automatic rotation for the secret, and associate a custom AWS Lambda function to execute the rotation steps with the payment provider.

Answer

Store the API key in AWS Secrets Manager, configure automatic rotation, and associate a custom AWS Lambda function to handle the rotation lifecycle events with the third-party payment provider.
AWS Secrets Manager is designed to store, manage, and rotate secrets. For third-party APIs that do not have built-in rotation integration in AWS, Secrets Manager allows you to configure automatic rotation by invoking a custom AWS Lambda function. This custom function implements the rotation logic (e.g., creating a new key with the provider and updating the secret value) automatically on the set schedule, minimizing operational overhead.

Step-by-Step Solution

1
Identify the requirement for secure credential storage with automatic rotation for a third-party API key.
Determine that AWS Secrets Manager is the primary AWS service designed for secrets management and automated rotation of credentials.
AWS Systems Manager Parameter Store does not support native rotation, and embedding secrets in code or deployment packages violates security best practices.
2
Configure the rotation schedule in AWS Secrets Manager.
Enable automatic rotation for the secret and specify a rotation schedule of 90 days.
Secrets Manager requires an orchestration schedule to run the rotation process periodically.
3
Develop and associate a custom AWS Lambda function with the Secrets Manager secret.
The custom Lambda function handles the rotation steps: creating a new version of the secret, testing it against the third-party provider, and finalizing the rotation.
Standard automatic rotation templates exist for AWS databases, but custom APIs require a custom rotation Lambda function to communicate with the external service.

Key Concept

Secrets Management and Parameter Store
Question 1210Question →

A developer is configuring a custom Amazon CloudWatch metric filter to monitor performance metrics from an API gateway service. The service writes structured JSON logs to a CloudWatch log group. A representative log event has the following structure:

{
"service": "payment-api",
"transaction": {
"success": true,
"amount": 250.00
},
"latency": 150
}

The developer needs to create a metric filter that publishes to a custom metric named `HighValueLatency` in the `PaymentMetrics` namespace. The metric must record the `latency` value, but only for events where the transaction `success` is `true` and the transaction `amount` is strictly greater than 200200.

Which TWO configurations or values must the developer specify in the metric filter settings to achieve this?

Select all that apply

Show answer & explanation

Answer: Set the filter pattern to `{ (.transaction.success = true) && (.transaction.amount > 200) }`; Set the metric value to `$.latency`

Answer

Set the filter pattern to `{ (.transaction.success = true) && (.transaction.amount > 200) }` and set the metric value to `$.latency`
To extract a specific field value from a JSON log event based on multiple conditions, the developer must specify both a valid filter pattern and a valid metric value. The pattern must enclose each individual comparison within parentheses and join them with the `&&` operator, using a single `=` for equality, which matches `{ (.transaction.success = true) && (.transaction.amount > 200) }`. The metric value must refer to the desired JSON path using standard dot notation starting with `.‘,whichmatches‘.`, which matches `.latency`.

Step-by-Step Solution

1
Formulate the JSON path expressions for the target fields.
The target fields are transaction success, transaction amount, and latency. The corresponding JSON path expressions are `.transaction.success‘,‘.transaction.success`, `.transaction.amount`, and `$.latency`.
CloudWatch Logs metric filters use JSON path notation starting with `$.` to reference properties in a JSON log event.
2
Construct the multi-conditional filter pattern.
Combine the conditions using the syntax `{ (condition1) && (condition2) }`, which yields `{ (.transaction.success = true) && (.transaction.amount > 200) }`.
When evaluating multiple conditions in a JSON metric filter, each comparison must be enclosed in parentheses and joined by logical operators like `&&`.
3
Define the metric value extractor.
Specify `$.latency` as the metric value in the metric filter configuration.
To record the actual latency value rather than a count of events, the metric value must point to the specific JSON path containing the numeric measurement.

Key Concept

CloudWatch Metric Filter JSON parsing and pattern syntax
Estimated Time:2m 30s
Question 1211Question →

A developer is configuring a multi-account CI/CD pipeline using AWS CodePipeline. The pipeline executes an AWS CodeBuild project in Account A. As part of the build spec, the project runs a deployment script that is designed to deploy an AWS CloudFormation stack in Account B. During execution, the build fails at the deployment step with the error: `An error occurred (AccessDenied) when calling the AssumeRole operation`. Which two actions should the developer take to resolve this failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In Account A, attach a policy to the CodeBuild service role that grants the `sts:AssumeRole` permission on the target role's Amazon Resource Name (ARN) in Account B.; In Account B, update the trust policy of the target IAM role to allow the ARN of the CodeBuild service role from Account A to assume it.

Answer

In Account A, attach a policy to the CodeBuild service role that grants the `sts:AssumeRole` permission on the target role's ARN in Account B; and in Account B, update the trust policy of the target IAM role to allow the ARN of the CodeBuild service role from Account A to assume it.
The correct options state that a policy must be attached to the CodeBuild service role in Account A granting `sts:AssumeRole` on the target role's ARN, and the target role's trust policy in Account B must be updated to trust the CodeBuild service role from Account A. This pair of configurations satisfies the cross-account delegation requirements in AWS IAM.

Step-by-Step Solution

1
Configure permissions in the source account (Account A)
The CodeBuild service role is granted permission to perform `sts:AssumeRole` on the target role's ARN.
The initiating identity must have explicit permission to invoke the assume role action on the specific target resource.
2
Configure the trust relationship in the target account (Account B)
The target IAM role's trust policy is updated to list the CodeBuild service role's ARN as a trusted entity.
An IAM role cannot be assumed by a principal in another account unless that principal is explicitly trusted in the role's trust policy.

Key Concept

Cross-account IAM role assumption requires granting `sts:AssumeRole` permission in the source account and trusting the source principal in the target role's trust policy.
Estimated Time:2m 0s
Question 1212Question →

A client-side Angular application hosted on `https://claims.healthportal.com` sends a `PUT` request to an Amazon API Gateway REST API secured by a custom Lambda Authorizer. The API is integrated with a backend Lambda function using Lambda Proxy Integration. When users attempt to perform actions with expired session tokens, the application's browser console displays a CORS preflight blocked error, and the request fails without displaying the expected session expiration message to the user. Which actions should the developer take to resolve the CORS preflight blocked error and allow the frontend to receive the correct status codes? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the 'Unauthorized' (401) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.; Configure the 'Access Denied' (403) Gateway Response in the API Gateway console to return the Access-Control-Allow-Origin header set to the origin domain.

Answer

Configure the 'Unauthorized' (401) and 'Access Denied' (403) Gateway Responses in API Gateway to include the 'Access-Control-Allow-Origin' header.
When a client-side application receives a CORS preflight error during authentication failure, it is because the API Gateway authorizer rejects the request before it reaches the backend integration. As a result, API Gateway generates a default Gateway Response (either 401 Unauthorized or 403 Access Denied) which does not contain CORS headers by default. Configuring the 'Unauthorized' and 'Access Denied' Gateway Responses to return the 'Access-Control-Allow-Origin' header ensures the browser receives the CORS headers and allows the client application to read the HTTP status code.

Step-by-Step Solution

1
Identify the source of the error when session tokens expire.
The Lambda Authorizer either throws an error resulting in a 401 Unauthorized status, or returns a Deny policy resulting in a 403 Access Denied status.
Understanding where execution terminates helps determine why CORS headers are missing.
2
Determine how CORS headers are handled during gateway-level failures.
Because the execution is terminated at the authorizer level before reaching the backend integration, standard integration response headers are bypassed, and API Gateway returns a Gateway Response.
CORS headers must be attached to the Gateway Responses directly since the backend Lambda code is never executed.
3
Configure Gateway Responses in API Gateway.
Add the 'Access-Control-Allow-Origin' header to both the 'Unauthorized' (401) and 'Access Denied' (403) Gateway Responses.
This ensures the browser receives the required CORS headers for both failure modes, allowing the client-side code to read the HTTP status codes and display the session expiration message.

Key Concept

Configuring CORS on Gateway Responses for Custom Authorizer failures
Question 1213Question →

An engineer is setting up a build process in AWS CodeBuild for a repository where the build specification file is named buildspec.yml and is located inside a directory named config/ instead of the root directory. The build fails during the initial phase because the buildspec file cannot be found. How can the engineer configure CodeBuild to successfully locate and use this buildspec file?

Show answer & explanation

Answer: Update the buildspec path in the AWS CodeBuild project configuration to point to config/buildspec.yml.

Answer

Update the buildspec path in the AWS CodeBuild project configuration to point to config/buildspec.yml.
The correct action is to update the buildspec path in the AWS CodeBuild project settings to point to the actual subdirectory path. AWS CodeBuild allows developers to override the default root location by specifying a custom file path relative to the root of the repository.

Step-by-Step Solution

Identify the default behavior of AWS CodeBuild regarding the buildspec file.
CodeBuild expects the buildspec.yml file to be located at the root of the source directory by default.
To understand why the build is failing when the file is in the config/ directory.
Determine how to override the default buildspec path in CodeBuild.
The project configuration allows defining a custom path relative to the root directory, such as config/buildspec.yml.
To tell CodeBuild where to look for the configuration file during the build initialization phase.
Update the CodeBuild project settings using the AWS Console, AWS CLI, or AWS CloudFormation.
The build specification is resolved successfully and the build starts.
To apply the configuration changes and fix the failing build.

Key Concept

Custom Buildspec File Paths
Question 1214Question →

A logistics tracking application uses Amazon DynamoDB to store delivery status updates. During peak hours, the application frequently experiences read throttling ("ProvisionedThroughputExceededException") when querying the status of specific high-priority shipments, which are read repeatedly by multiple warehouse terminals using eventually consistent reads. The development team needs to implement a caching solution to reduce the load on the DynamoDB table and minimize tail latency while requiring minimal modifications to the existing application code. Which solution should the development team implement to meet these requirements?

Show answer & explanation

Answer: Deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application code to use the DAX SDK client instead of the standard DynamoDB client.

Answer

Deploy an Amazon DynamoDB Accelerator (DAX) cluster and update the application code to use the DAX SDK client instead of the standard DynamoDB client.
Deploying an Amazon DynamoDB Accelerator (DAX) cluster and updating the application code to use the DAX SDK client is the optimal solution. DAX provides a fully managed, API-compatible, in-memory cache for DynamoDB. Because the reads are eventually consistent, DAX caches and serves them directly from the item cache, eliminating hot partition read throttling on the underlying DynamoDB table with minimal changes to application logic.

Step-by-Step Solution

1
Analyze the root cause of the DynamoDB throttling ("ProvisionedThroughputExceededException").
The throttling is caused by repeated reads of specific high-priority shipments (hot partition keys) using eventually consistent reads.
Identifying whether the bottleneck is due to overall capacity constraints or hot partitions determines the correct mitigation strategy.
2
Evaluate the consistency requirement and caching solutions.
Since the read requests are eventually consistent, they are eligible for item caching using either Amazon ElastiCache or Amazon DynamoDB Accelerator (DAX).
Strongly consistent reads bypass the DAX item cache, but eventually consistent reads are served directly from the cache, reducing read load on DynamoDB.
3
Select the caching solution that minimizes code changes and avoids anti-patterns.
Deploying DAX requires only replacing the standard DynamoDB client with the DAX client (API-compatible), whereas ElastiCache requires writing complex custom logic for cache-aside patterns and can lead to inefficient Scan patterns if designed poorly.
DAX is specifically built for DynamoDB caching, offering transparent API integration and automatic cache management without rewriting query logic.

Key Concept

Using DynamoDB Accelerator (DAX) to resolve read throttling on hot keys with minimal code changes.
Question 1215Question →

A developer is testing a local Java application that uses the AWS SDK for Java v2 to retrieve messages from an Amazon SQS queue. The application is configured to use a profile named dev-profile. When running the application locally, it fails with the following error:

software.amazon.awssdk.core.exception.SdkClientException: Unable to load credentials from any of the providers in the chain

The developer verifies that the local AWS credentials and configuration files exist. Which TWO conditions could explain this credential loading failure? (Select TWO).

Select all that apply

Show answer & explanation

Answer: The credentials file (~/.aws/credentials) defines the profile as [profile dev-profile] instead of [dev-profile].; The environment variable AWS_PROFILE is not set on the local machine, and the ~/.aws/credentials file does not contain a [default] profile.

Answer

The credentials file (~/.aws/credentials) must define the profile without the 'profile' prefix, and the environment variable AWS_PROFILE must be set to the profile name if a default profile is not defined.
The correct options identify valid reasons for the SDK's inability to load credentials. First, in the shared credentials file (~/.aws/credentials), profiles must be declared as [profile_name] (e.g., [dev-profile]) without the 'profile' prefix, which is only used in the configuration file (~/.aws/config). If the prefix is included in the credentials file, the SDK will fail to resolve the profile. Second, if the AWS_PROFILE environment variable is not defined, the default credential provider chain looks for the [default] profile. If no default profile is configured, the chain fails and throws an SdkClientException.

Step-by-Step Solution

1
Examine the local system's environment variables to check if AWS_PROFILE is set.
If AWS_PROFILE is unset, the SDK default provider chain defaults to searching for credentials under the '[default]' profile header.
To understand which profile the Java SDK is attempting to load.
2
Inspect the content and structure of the ~/.aws/credentials file.
Identify if the target profile is defined correctly as '[dev-profile]' or incorrectly as '[profile dev-profile]'.
The credentials file does not support the 'profile' keyword prefix in brackets, which is a common syntax error that prevents the SDK from reading the credentials.

Key Concept

AWS SDK credential lookup precedence and configuration syntax rules for local development.
Question 1216Question →

An e-commerce application named "FlashRetail" writes customer transaction records to an Amazon DynamoDB table. The table partition key is configured as the transaction date (format: YYYY−MM−DDYYYY-MM-DD). During a high-volume flash sale event, the application experiences write throttling and encounters ProvisionedThroughputExceededExceptionProvisionedThroughputExceededException errors, even though the total consumed capacity is well below the table's overall provisioned write limit.

Which of the following actions should the developer take to resolve this throttling issue?

Show answer & explanation

Answer: Redesign the partition key schema by appending a random suffix to the transaction date to distribute writes across multiple partition keys.

Answer

Redesign the partition key schema by appending a random suffix to the transaction date to distribute writes across multiple partition keys.
The correct action is to redesign the partition key schema by appending a random suffix. The transaction date (YYYY−MM−DDYYYY-MM-DD) has low cardinality during a high-traffic event, causing all writes to target the same partition key. Appending a random suffix (sharding) distributes the write operations across multiple distinct partition key values (e.g., 2026−07−14.12026-07-14.1, 2026−07−14.22026-07-14.2), resolving the hot partition bottleneck.

Step-by-Step Solution

1
Analyze the table's partition key design and write patterns during the event.
The partition key is the transaction date, which causes all write operations on a given day to target the exact same partition key value.
When all writes target a single partition key value, a hot partition is created, leading to local throttling even if the table-wide provisioned capacity is not fully consumed.
2
Evaluate remediation options to distribute the write load.
Adding a random suffix (e.g., a number from 1 to N) to the transaction date splits the single hot partition key into multiple distinct partition key values.
Distributing the writes across multiple partition key values ensures that traffic is spread across different physical partitions, resolving the single-partition throughput bottleneck.

Key Concept

Avoiding hot partitions in DynamoDB by distributing writes using partition key sharding (adding random suffixes).
Estimated Time:45s
Question 1217Question →

A developer is deploying a three-tier web application using an AWS CloudFormation template. The template defines an Amazon RDS DB instance that requires database credentials. The company's security policy requires that database passwords must be stored securely, rotated every 30 days, and retrieved dynamically during stack operations. Additionally, the developer must ensure that any failed stack updates automatically revert to the last stable state without leaving orphaned resources or requiring manual intervention. Which two actions should the developer take to meet these security and deployment requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and reference it in the CloudFormation template using a dynamic reference format.; Rely on CloudFormation's automatic rollback on update failure, which reverts modified resources to their previous configuration and returns the stack to the UPDATE_ROLLBACK_COMPLETE state.

Answer

Store the database password in AWS Secrets Manager and reference it in the CloudFormation template using a dynamic reference format, and rely on CloudFormation's automatic rollback on update failure, which reverts modified resources to their previous configuration and returns the stack to the UPDATE_ROLLBACK_COMPLETE state.
Storing database credentials in AWS Secrets Manager and referencing them using dynamic references satisfies the credential security and 30-day rotation policy while keeping passwords out of plaintext template properties. Relying on default CloudFormation update rollbacks ensures that stack updates that fail revert all affected resources back to their original stable configurations automatically.

Step-by-Step Solution

1
Select AWS Secrets Manager as the secure vault for credentials.
The database password is created and stored in AWS Secrets Manager, allowing automatic 30-day rotation configurations.
Parameter Store does not support automatic rotation natively, making Secrets Manager the compliant choice for rotated secrets.
2
Integrate the secret reference into the CloudFormation template using dynamic references.
CloudFormation retrieves the password dynamically at runtime during stack operations without exposing the password in template files.
Dynamic references are resolved only during resource provisioning and keep plaintext passwords out of templates and outputs.
3
Determine the automatic rollback strategy on deployment failure.
The rollback mechanism reverts stack resources back to their pre-update state, returning the stack to UPDATE_ROLLBACK_COMPLETE on failure.
This behavior prevents orphan resources and returns the infrastructure configuration to the last known stable state.

Key Concept

AWS CloudFormation deployment lifecycle controls stack update rollbacks and integrates with AWS Secrets Manager via dynamic references to handle rotated secrets securely.
Estimated Time:2m 0s
Question 1218Question →

A developer is implementing a smart home mobile application. The mobile client needs to authenticate users and obtain temporary, limited-privilege AWS credentials to publish telemetry data directly to Amazon IoT Core MQTT topics.

Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Authenticate users using an Amazon Cognito User Pool. Configure an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials associated with an IAM role that permits publishing to AWS IoT Core.

Answer

Authenticate users using an Amazon Cognito User Pool. Configure an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials associated with an IAM role that permits publishing to AWS IoT Core.
Using an Amazon Cognito User Pool for user authentication combined with an Amazon Cognito Identity Pool to exchange tokens for temporary AWS credentials is the standard, built-in AWS pattern. The Identity Pool handles the generation of temporary credentials via an IAM role with minimum operational overhead.

Step-by-Step Solution

1
Use Amazon Cognito User Pools for user sign-up and sign-in management.
Users are authenticated, and the mobile client receives JSON Web Tokens (JWTs).
Cognito User Pools serve as the identity provider to verify user identities.
2
Configure an Amazon Cognito Identity Pool and associate it with the Cognito User Pool as an authentication provider.
The client application can present the User Pool tokens to the Identity Pool in exchange for temporary AWS credentials.
Cognito Identity Pools provide authorization to AWS resources by vending temporary AWS credentials.
3
Assign an IAM role with permissions to publish to AWS IoT Core MQTT topics to the authenticated user role in the Identity Pool.
The mobile client uses the obtained temporary credentials to interact securely and directly with AWS IoT Core.
This implements the principle of least privilege using short-lived credentials, minimizing security risks and administrative overhead.

Key Concept

Amazon Cognito User Pools handle authentication (user directory and tokens), whereas Cognito Identity Pools handle authorization by exchanging those tokens for temporary AWS credentials.
Estimated Time:1m 30s
Question 1219Question →

A developer has deployed a Python Flask web application on Amazon EC2 instances. The application receives user requests, sends notifications to Amazon SNS, and queries an Amazon RDS PostgreSQL database. The AWS X-Ray daemon is running on the instances and has the necessary permissions. However, the X-Ray service map only shows the EC2 instances as nodes and does not display downstream nodes for Amazon SNS or the RDS database. Which two actions should the developer take to instrument the application and trace these downstream components? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Call the patch_all() function from the aws_xray_sdk.core module at the start of the application to instrument boto3.; Use the database patching capabilities in the AWS X-Ray SDK to instrument the psycopg2 database connector.

Answer

To instrument downstream calls, the developer must call the patch_all() function from the X-Ray SDK to instrument boto3 and patch the database connector (psycopg2) to trace RDS queries.
The correct choices involve using the AWS X-Ray SDK to patch the boto3 library and instrument the database connector (psycopg2). This allows the SDK to intercept and record tracing data for downstream services like Amazon SNS and Amazon RDS.

Step-by-Step Solution

1
Import and call patch_all() in the main Flask application entry point.
The boto3 library is patched, enabling X-Ray to record calls to Amazon SNS.
To capture metadata and segments for AWS service calls.
2
Patch the database connector (psycopg2) using the X-Ray SDK's dbapi instrumentation.
SQL queries executed against the RDS database are captured as subsegments.
To trace SQL database operations.

Key Concept

AWS X-Ray SDK patching and instrumentation for downstream service and database calls.
Question 1220Question →

A developer is troubleshooting a cross-account deployment failure. A CI/CD pipeline using AWS CodePipeline in Account A (111111111111111111111111) needs to deploy resources into Account B (222222222222222222222222) by assuming a role named `CrossAccountDeployRole` in Account B.

The pipeline fails at the deploy stage with the error:
`CodePipeline is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::222222222222:role/CrossAccountDeployRole`

In Account B, the developer has configured the following trust policy for `CrossAccountDeployRole`:

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

Which two actions should the developer take to resolve this authorization failure?

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the CodePipeline service role in Account A that allows the `sts:AssumeRole` action on `arn:aws:iam::222222222222:role/CrossAccountDeployRole`.; Update the trust policy of `CrossAccountDeployRole` in Account B to replace the `codepipeline.amazonaws.com` service principal with the ARN of the CodePipeline service role in Account A.

Answer

Attach an IAM policy to the CodePipeline service role in Account A that allows the `sts:AssumeRole` action, and update the trust policy of `CrossAccountDeployRole` in Account B to trust the CodePipeline service role in Account A.
For cross-account role assumption, two permissions must be aligned: the initiator (CodePipeline service role in Account A) must have an identity policy allowing the `sts:AssumeRole` action on the target role, and the receiver (the target role in Account B) must have a trust policy listing the initiator's role ARN as a trusted principal. Using the service principal `codepipeline.amazonaws.com` is incorrect because cross-account actions are performed by the role executing the pipeline, not the service itself.

Step-by-Step Solution

1
Identify the principal attempting the assume-role action.
The AWS CodePipeline execution in Account A operates under the security context of the CodePipeline service role, not the generic service principal.
Understanding the security principal is essential for establishing cross-account access.
2
Configure the trust relationship on the target role in Account B.
Modify the trust policy of `CrossAccountDeployRole` in Account B to trust the specific IAM role ARN from Account A rather than the service principal.
A trust policy must trust the calling identity's ARN to allow cross-account access.
3
Configure permissions on the initiating role in Account A.
Attach an identity policy to the CodePipeline service role in Account A permitting `sts:AssumeRole` on the target role ARN in Account B.
IAM requires both the target trust policy and the caller's permission policy to allow cross-account operations.

Key Concept

Cross-account IAM role assumption requires both an identity-based permission policy in the source account allowing sts:AssumeRole, and a trust policy in the target account permitting the source principal to assume it.
PreviousPage 61 / 78Next
All practice questions — AWS Certified Developer - Associate | Examkin