All practice questions

1542 questions

Question 1161Question

A developer is implementing real-time processing of application logs generated by a payment service. The application writes JSON-formatted logs to an Amazon CloudWatch Logs log group. The developer sets up a CloudWatch Logs subscription filter to stream logs where the transaction status is "failed" and the error code is 504 to an AWS Lambda function for alerting.

During load testing, the developer observes that several alerts are missed, and the Lambda function's CloudWatch logs show multiple "Task timed out after 3.00 seconds" errors. The database connection initialization is currently located inside the Lambda handler function.

Which of the following represents the correct subscription filter pattern to extract these failed transactions, along with the appropriate troubleshooting step to resolve the Lambda timeout errors?

Show answer & explanation

Answer: Filter pattern: `{ .status = "failed" && .errorCode = 504 }`
Resolution: Increase the Lambda function's execution timeout and move the database connection initialization outside the handler function to leverage execution context reuse.

Answer

Filter pattern: `{ .status = "failed" && .errorCode = 504 }` and Resolution: Increase the Lambda function's execution timeout and move the database connection initialization outside the handler function to leverage execution context reuse.
The subscription filter pattern for JSON logs requires curly braces `{}` and prefixing JSON keys with `.` to properly parse and match values (e.g., `{ .status = "failed" && $.errorCode = 504 }`). To address the Lambda timeouts, moving the database connection initialization outside the handler function enables connection reuse across multiple invocations (execution context reuse). This avoids the heavy overhead of creating a new database connection on every function invocation, which is a major contributor to latency and timeouts.

Step-by-Step Solution

1
Analyze the log format and identify the correct CloudWatch Subscription Filter pattern syntax.
Since the logs are JSON-formatted, the filter pattern must use curly braces `{}` and reference fields using the `.` prefix (e.g., `{ .status = "failed" && $.errorCode = 504 }`).
Bracket-based syntax `[...]` is used for space-delimited text logs, whereas CloudWatch Logs requires JSON property paths for structured logs.
2
Examine the Lambda execution logs showing timeouts and identify the source of latency.
Initializing database connections inside the handler function leads to high connection establishment latency on every invocation.
During load spikes, establishing a new connection on every invocation leads to container resource exhaustion and execution timeouts.
3
Determine the correct mitigation to resolve the Lambda function's timeouts.
Move the database connection initialization code outside the handler to utilize execution context reuse, and increase the timeout.
Declaring the database client globally allows AWS Lambda to reuse the active connection pool across sequential warm invocations, dramatically reducing invocation latency.

Key Concept

CloudWatch Logs JSON Metric and Subscription Filter syntax combined with Lambda execution context reuse optimization.
Estimated Time:2m 0s
Question 1162Question

A developer needs to monitor a serverless application's log group in Amazon CloudWatch Logs for database connection errors. The application logs errors in the format: `[ERROR] DatabaseConnectionError: Connection timed out`. The developer wants to count these errors and send notifications when they occur. Which TWO actions should the developer take to achieve this?

Select all that apply

Show answer & explanation

Answer: Create an Amazon CloudWatch Logs metric filter on the log group using the filter pattern "DatabaseConnectionError".; Create an Amazon CloudWatch alarm based on the custom metric published by the metric filter to trigger notifications when the threshold is exceeded.

Answer

Create an Amazon CloudWatch Logs metric filter on the log group using the filter pattern "DatabaseConnectionError" and create an Amazon CloudWatch alarm based on the custom metric to trigger notifications when the threshold is exceeded.
The correct approach involves creating a CloudWatch Logs metric filter to search for the specific pattern 'DatabaseConnectionError' in incoming log events. This filter increments a custom CloudWatch metric. Then, a CloudWatch alarm must be configured on that custom metric to trigger an alarm state and notify the team (e.g., via SNS) when the occurrence threshold is crossed.

Step-by-Step Solution

1
Analyze the log structure to identify the term to monitor.
The target term "DatabaseConnectionError" is identified within the log pattern.
The filter pattern needs to match this specific string in the log stream.
2
Configure the metric filter with the pattern.
A metric filter is created on the log group that increments a custom metric name whenever "DatabaseConnectionError" appears.
Metric filters translate log data into numeric metrics.
3
Create a CloudWatch alarm.
An alarm is configured to monitor the custom metric and send notifications (e.g., via Amazon SNS) when the error rate exceeds the defined limit.
Alarms are required to detect threshold breaches and initiate notification actions.

Key Concept

Configuring CloudWatch Logs metric filters and alarms to detect and alert on specific patterns in application logs.
Question 1163Question

A developer is configuring a buildspec.yml file for an AWS CodeBuild project. The build environment requires access to a database connection password stored in AWS Secrets Manager and a non-sensitive configuration parameter stored in Systems Manager Parameter Store. The developer wants to retrieve these values securely and inject them as environment variables during the build phases without hardcoding them in the source code. Which approach should the developer take to retrieve these values?

Show answer & explanation

Answer: Define the non-sensitive configuration under the parameter-store mapping and the database password under the secrets-manager mapping inside the env section of the buildspec.yml file.

Answer

Define the non-sensitive configuration under the parameter-store mapping and the database password under the secrets-manager mapping inside the env section of the buildspec.yml file.
The correct option correctly uses CodeBuild's native capabilities to resolve environment variables. Defining the parameter in the parameter-store block and the secret in the secrets-manager block under the env section of buildspec.yml ensures that CodeBuild calls the appropriate AWS APIs at build initialization, retrieves the values securely, and makes them available to the build environment phases.

Step-by-Step Solution

1
Identify where the database connection password and non-sensitive configuration parameters are stored.
The password is in AWS Secrets Manager, and the parameter is in Systems Manager Parameter Store.
Understanding the source storage determines the corresponding configuration block to use in the buildspec.
2
Map the storage locations to the native environment variable structures supported by AWS CodeBuild.
AWS CodeBuild provides parameter-store and secrets-manager blocks under the env section of buildspec.yml to natively retrieve these values.
Using native blocks allows CodeBuild to automatically fetch the values at runtime using the build's IAM role, ensuring they are not hardcoded or exposed.
3
Specify the parameters under their correct respective blocks in the env section.
The configuration parameter goes under parameter-store and the database password goes under secrets-manager.
This guarantees that both services are accessed using the correct APIs and the fetched values are injected as environment variables.

Key Concept

AWS CodeBuild Environment Variable Resolution
Question 1164Question

A developer is troubleshooting a Node.js application running on a local development workstation. The application uses the AWS SDK for JavaScript v3 to write data to an Amazon DynamoDB table. The developer's local environment contains multiple AWS CLI profiles configured in ~/.aws/credentials.

The developer sets the environment variable AWS_PROFILE=dev-profile in the terminal and runs the application. However, the application fails to write to the development database and instead attempts to write to the production database, resulting in access denied errors. Further investigation reveals that the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are currently set in the active terminal session and correspond to production credentials.

Which two actions will resolve this issue by ensuring the application uses the dev-profile credentials? (Choose two.)

Select all that apply

Show answer & explanation

Answer: Run the command to unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the active terminal session.; Modify the application code to initialize the DynamoDB client using the fromIni credential provider from the @aws-sdk/credential-providers package, explicitly specifying the dev-profile profile.

Answer

To resolve this issue, the developer should unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the active terminal session, or modify the application code to initialize the client using the fromIni credential provider targeting the dev-profile profile.
The default credential provider chain resolves environment variables first. Therefore, unsetting the active production environment variables forces the SDK to evaluate the next step in the chain, resolving the profile specified in the AWS_PROFILE environment variable. Alternatively, explicitly configuring the client in the code using the fromIni provider overrides the default chain sequence entirely, forcing the SDK to retrieve credentials from the specified local profile.

Step-by-Step Solution

1
Analyze the client-side credential resolution order of the AWS SDK default credential provider chain.
Confirm that environment variables (like AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) have the highest precedence, overriding profile-based settings.
This explains why the SDK ignores the AWS_PROFILE environment variable as long as the production keys are active in the terminal.
2
Determine the environment-level remediation step.
Unsetting the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables allows the chain to evaluate the next provider, which retrieves profile settings.
Unsetting environment variables forces the SDK to fall back to the shared credential file using the profile specified in AWS_PROFILE.
3
Determine the application code-level remediation step.
Using the fromIni provider explicitly loads the credentials from the dev-profile in the shared credentials file.
This bypasses the default chain precedence rules entirely, ensuring the application executes under the correct credentials regardless of terminal state.

Key Concept

AWS SDK credential resolution precedence and configuration overrides
Question 1165Question

A gaming company is launching a multiplayer mobile game. The backend application requires a highly scalable data store to manage active player session states (such as scores and connection statuses) that are updated frequently and must expire after 24 hours of inactivity. The application also needs to cache static, read-heavy matchmaking lobby configurations to minimize database read latency.

Which combination of strategies should a developer implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store player session states in an Amazon DynamoDB table with Time to Live (TTL) enabled, and retrieve session records using Query operations based on unique player IDs.; Deploy an Amazon ElastiCache for Memcached cluster to cache the static matchmaking configurations and game rule metadata.

Answer

The correct strategies are to store player session states in an Amazon DynamoDB table with Time to Live (TTL) enabled, retrieving them using Query operations based on unique player IDs, and to deploy an Amazon ElastiCache for Memcached cluster to cache static matchmaking configurations.
The correct strategies involve using Amazon DynamoDB with Time to Live (TTL) enabled for player session states, retrieving them using Query operations based on unique player IDs, and deploying an Amazon ElastiCache for Memcached cluster to cache static matchmaking configurations. DynamoDB with TTL automatically deletes expired session data without consuming write capacity. Querying DynamoDB by player ID ensures low-latency single-item lookups. ElastiCache for Memcached is ideal for simple, read-heavy key-value configurations, which offloads read requests from the primary database.

Step-by-Step Solution

1
Evaluate the requirement for storing active player session states that are updated frequently and must expire after 24 hours.
Amazon DynamoDB is a highly scalable key-value database, and enabling TTL allows automatic expiration of inactive sessions after 24 hours without incurring additional write capacity costs. Accessing sessions via Query or GetItem using unique player IDs provides low-latency retrieval.
This meets the session storage and expiration requirements efficiently.
2
Evaluate the requirement to cache static, read-heavy matchmaking lobby configurations.
Amazon ElastiCache for Memcached is an in-memory key-value store optimized for simple data types and read-heavy workloads, making it ideal for caching static configuration data.
This offloads read traffic from the primary database, reducing latency and cost.
3
Analyze the incorrect options against AWS best practices and the target scenario.
Using Scan operations instead of Query or GetItem results in poor performance and high RCU consumption. Parameter Store does not support automatic rotation. A single partition key for all sessions creates a hot partition and leads to throttling.
This confirms that the other options represent sub-optimal designs or incorrect service usage.

Key Concept

Application Caching and Session State Management
Question 1166Question

A developer attempts to deploy a new infrastructure stack using an AWS CloudFormation template. The initial stack creation fails during the creation of an Amazon DynamoDB table, and the stack status changes to ROLLBACK_COMPLETE. The developer corrects the table configuration in the template and wants to deploy the corrected template.

Which of the following actions can the developer take to deploy the updated template successfully? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Delete the current stack, and then create a new stack using the corrected template.; Deploy the corrected template as a new stack under a different stack name.

Answer

Deleting the failed stack and creating a new one, or deploying the template as a new stack with a different name.
To resolve a failed initial stack creation that has rolled back to the ROLLBACK_COMPLETE state, the developer must either delete the failed stack and create a new one using the corrected template, or deploy the template as a new stack with a different name. This is because a stack in the ROLLBACK_COMPLETE state from a failed initial creation cannot be updated directly.

Step-by-Step Solution

1
Identify the current state of the stack and how it was reached.
The stack is in the ROLLBACK_COMPLETE state due to a failure during its initial creation.
The rollback state determines what actions are allowed on the stack.
2
Determine if update operations are supported in the current state.
AWS CloudFormation does not allow update operations on stacks that have failed initial creation and rolled back to ROLLBACK_COMPLETE.
Understanding limitations of ROLLBACK_COMPLETE helps eliminate invalid update actions.
3
Select valid methods to deploy the corrected template.
The developer must either delete the failed stack and recreate it, or deploy the corrected template as a new stack with a different name.
These are the only allowed paths to deploy the resource definitions successfully.

Key Concept

Troubleshooting CloudFormation ROLLBACK_COMPLETE state on initial stack creation
Estimated Time:1m 0s
Question 1167Question

A developer is setting up a new AWS CodeBuild project to build and package a containerized application. The developer creates an IAM role named CodeBuildDeploymentRole and attaches the AWSCodeBuildDeveloperAccess managed policy. When the developer initiates a build run, the build fails immediately during the setup phase with the error message: "CodeBuild is not authorized to perform: sts:AssumeRole on the specified credentials role". Which action should the developer take to resolve this failure?

Show answer & explanation

Answer: Modify the trust relationship of the CodeBuildDeploymentRole to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

Modify the trust relationship of the CodeBuildDeploymentRole to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action.
The correct answer is to modify the trust relationship of the role to allow the codebuild.amazonaws.com service principal to perform the sts:AssumeRole action. For any AWS service to assume an IAM role, the role's trust policy must explicitly permit the service's principal to perform the sts:AssumeRole API call.

Step-by-Step Solution

1
Analyze the error message showing that AWS CodeBuild is unauthorized to perform sts:AssumeRole on the specified IAM role.
Identify that the issue is due to a misconfigured IAM Trust Policy on the target role, preventing CodeBuild from assuming it.
Before a build execution begins, the CodeBuild service must assume the project's service role to acquire temporary security credentials.
2
Update the trust policy document of the CodeBuildDeploymentRole via the IAM Console or CLI.
Add codebuild.amazonaws.com as a trusted entity allowed to call sts:AssumeRole.
This establishes the trust relationship required for the AWS CodeBuild service principal to assume this specific role.

Key Concept

IAM Service Roles and Trust Relationships
Estimated Time:2m 0s
Question 1168Question

A developer is configuring an AWS CodeDeploy deployment group for an in-place deployment to a fleet of 10 Amazon EC2 instances. The deployment must not provision any new EC2 instances due to budget limitations. Additionally, the application must maintain at least 50% of its healthy instance capacity at all times during the update to handle the incoming traffic load.

Which two CodeDeploy default deployment configurations can the developer select to meet these requirements? (Choose two.)

Select all that apply

Show answer & explanation

Answer: CodeDeployDefault.OneAtATime; CodeDeployDefault.HalfAtATime

Answer

CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime
The correct configurations are CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime. An in-place deployment to a fleet of 10 EC2 instances requires at least 5 instances (50%) to remain healthy at all times. CodeDeployDefault.OneAtATime updates one instance at a time, keeping 90% capacity active. CodeDeployDefault.HalfAtATime updates up to 5 instances at a time, keeping exactly 50% capacity active. Both satisfy the minimum capacity requirement.

Step-by-Step Solution

1
Analyze the deployment target and capacity constraints.
The deployment is in-place on a fleet of 10 EC2 instances and requires at least 50% capacity (5 instances) to remain healthy at all times.
To identify which deployment configurations are compatible with EC2 and satisfy the minimum instance count requirements.
2
Evaluate compatible CodeDeploy deployment configurations for EC2.
CodeDeployDefault.OneAtATime, CodeDeployDefault.HalfAtATime, and CodeDeployDefault.AllAtOnce are default configurations for EC2. Configurations prefixed with ECS or Lambda are incompatible.
To filter out platform-incompatible configurations.
3
Calculate the active capacity during deployment for the remaining configurations.
OneAtATime keeps 90% (9 instances) active. HalfAtATime keeps 50% (5 instances) active. AllAtOnce keeps 0% (0 instances) active. Only OneAtATime and HalfAtATime meet the 50% threshold.
To select the configurations that satisfy the capacity constraint.

Key Concept

AWS CodeDeploy deployment configurations for EC2 in-place deployments.
Question 1169Question

A client receives a 500 Internal Server Error when attempting to call an Amazon API Gateway resource secured by a custom Lambda Authorizer. The Lambda Authorizer execution completes successfully with no errors in its Amazon CloudWatch logs. Which of the following is the most likely cause of this behavior?

Show answer & explanation

Answer: The custom Lambda Authorizer returned a response JSON payload that does not conform to the expected format containing principalId and policyDocument.

Answer

The custom Lambda Authorizer returned a response JSON payload that does not conform to the expected format containing principalId and policyDocument.
The correct response points out that a malformed JSON payload returned by the custom Lambda Authorizer (such as omitting principalId or policyDocument) causes API Gateway to fail validation, leading to a 500 Internal Server Error even if the Lambda code itself runs successfully without throwing errors.

Step-by-Step Solution

1
Analyze the HTTP status code and logs.
The client receives a 500 Internal Server Error, but the Lambda Authorizer execution completes successfully with no runtime errors in CloudWatch.
This indicates that the authorizer function executed successfully without throwing an exception, but API Gateway failed to process the output returned by the function.
2
Verify the required output format for Lambda Authorizers.
Lambda Authorizers must return a structured JSON response containing the principalId, policyDocument (with Statement, Action, Effect, Resource), and optionally context.
API Gateway requires this specific structure to validate permissions. If any of these fields are missing or incorrectly formatted, API Gateway cannot evaluate the policy and defaults to a 500 Internal Server Error.

Key Concept

API Gateway Lambda Authorizer response validation
Question 1170Question

A developer is deploying a containerized application to Amazon ECS on AWS Fargate. The application code reads configuration files from an Amazon S3 bucket. Additionally, the container definition is configured to retrieve a database password from AWS Systems Manager Parameter Store and inject it as an environment variable at startup. Which configuration of IAM roles and trust relationships is required for the application to run successfully?

Show answer & explanation

Answer: Attach the S3 access policy to the ECS Task Role, and attach the Parameter Store access policy to the ECS Task Execution Role. Configure both roles to trust the ECS tasks service (ecs-tasks.amazonaws.com).

Answer

Attach the S3 access policy to the ECS Task Role, and attach the Parameter Store access policy to the ECS Task Execution Role. Configure both roles to trust the ECS tasks service (ecs-tasks.amazonaws.com).
The correct option correctly separates the runtime application permissions (ECS Task Role for S3) from the ECS agent bootstrap permissions (ECS Task Execution Role for Parameter Store), and configures both roles to trust the ECS tasks service principal (ecs-tasks.amazonaws.com).

Step-by-Step Solution

1
Determine the role required for the application code to access S3.
The application code running inside the container needs runtime permissions, which are provided by the ECS Task Role.
The Task Role credentials are injected into the container's environment for the AWS SDK to use.
2
Determine the role required for the container agent to fetch secrets.
The ECS container agent needs permissions to pull the secret from Parameter Store at startup, which is provided by the ECS Task Execution Role.
The Task Execution Role grants the ECS infrastructure permissions to prepare the container environment.
3
Verify the IAM trust relationships.
Both roles must trust the ecs-tasks.amazonaws.com service principal.
This allows Amazon ECS to assume the specified IAM roles on behalf of the tasks.

Key Concept

ECS Task Role vs Task Execution Role
Question 1171Question

A developer is troubleshooting a client-side real estate web application hosted on `https://listings.example.com` that sends `POST` requests to an Amazon API Gateway REST API. The API is integrated with an AWS Lambda function using a Lambda Proxy integration. Users report that search submissions fail, and the browser console displays a CORS policy error indicating that the 'Access-Control-Allow-Origin' header is missing. Which two actions must the developer take to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the backend Lambda function to return the 'Access-Control-Allow-Origin' header in its JSON response headers.; Deploy the API Gateway REST API to a stage after enabling CORS on the resource in the console.

Answer

The developer must configure the backend Lambda function to return the 'Access-Control-Allow-Origin' header in its JSON response, and deploy the API Gateway REST API to a stage after enabling CORS on the resource.
The correct options are configuring the backend Lambda function to return the 'Access-Control-Allow-Origin' header in its response, and deploying the API Gateway REST API to a stage. When using Lambda Proxy integration, the backend Lambda function is responsible for returning the appropriate CORS headers in its response because API Gateway passes the response from Lambda directly without modification. Additionally, enabling CORS in the API Gateway console configures the preflight OPTIONS method, but the API must be deployed to the target stage for those settings to become active.

Step-by-Step Solution

1
Add the required CORS headers to the Lambda function response.
The Lambda function returns a payload containing headers: { 'Access-Control-Allow-Origin': 'https://listings.example.com' }.
Since the API uses Lambda Proxy integration, API Gateway does not automatically inject CORS headers into responses from the integration; the backend function must return them.
2
Enable CORS on the REST API resource and deploy the API.
The mock integration for the preflight OPTIONS method is created and deployed to the active stage.
Before browsers send a non-simple request (like POST with JSON payload), they perform a preflight OPTIONS request. API Gateway must have CORS enabled (to handle OPTIONS) and the API must be deployed to the stage to serve these requests.

Key Concept

Handling CORS in Amazon API Gateway REST APIs using Lambda Proxy Integration requires both configuring the API Gateway OPTIONS method (via Enable CORS) and returning the CORS headers directly from the backend Lambda function response.
Question 1172Question

A developer uses AWS CloudFormation to manage an application's infrastructure. An administrator manually modified the inbound rules of a security group associated with an Amazon EC2 instance using the AWS Management Console to resolve a temporary connection issue. The developer runs a drift detection status check on the stack, and the security group is flagged as DRIFTED. Which action should the developer take to resolve the drift and ensure the resource configuration is correctly aligned with the CloudFormation template?

Show answer & explanation

Answer: Revert the manual changes in the security group directly via the Amazon EC2 console to match the template, or update the template to include the modified rules and run a stack update.

Answer

Revert the manual changes in the security group directly via the Amazon EC2 console to match the template, or update the template to include the modified rules and run a stack update.
To resolve drift on a resource managed by CloudFormation, you must either revert the manual out-of-band changes directly in the resource's service console (or via CLI) so it matches the template configuration, or update the CloudFormation template to match the drifted state and perform a stack update to sync the stack status.

Step-by-Step Solution

1
Identify the drifted properties of the resource using the drift detection details in the AWS CloudFormation console.
The differences between the expected template configuration and the actual live configuration of the security group are revealed.
This allows the developer to pinpoint exactly which rules were modified, added, or deleted out-of-band.
2
Decide whether to keep the manual changes or revert them.
A plan is made to either rollback the manual console edits or update the template to adopt them permanently.
Resolving drift requires aligning the expected template definition with the physical resource state.
3
Perform the alignment action by either manually updating the security group rules in the EC2 Console to match the template, or updating the CloudFormation template to match the new rules followed by a stack update.
The resource configuration matches the template, and subsequent drift detection checks will report the resource as IN_SYNC.
This establishes a clean baseline for future CloudFormation deployments and prevents deployment failures.

Key Concept

CloudFormation Drift Detection and Resolution
Question 1173Question

A developer is troubleshooting a failed AWS CodeDeploy deployment. The deployment was configured to update a containerized application running on an Amazon ECS service using a blue/green deployment strategy. The deployment failed during the validation phase with an error indicating that invalid lifecycle hooks were specified in the deployment specification file. Which of the following lifecycle hooks are unsupported for an Amazon ECS deployment and must be removed from the appspec.yaml file to resolve the issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: ApplicationStop; ApplicationStart

Answer

The unsupported lifecycle hooks for an Amazon ECS deployment are ApplicationStop and ApplicationStart.
For an Amazon ECS deployment, CodeDeploy supports a specific, limited set of lifecycle hooks: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic. The ApplicationStop and ApplicationStart hooks are only used in EC2/On-Premises deployments to manage on-instance application states and will fail validation if included in an ECS AppSpec template.

Step-by-Step Solution

1
Determine the target compute platform for the CodeDeploy deployment.
The target platform is Amazon ECS.
CodeDeploy lifecycle hooks differ significantly depending on whether the deployment is for EC2/On-Premises, AWS Lambda, or Amazon ECS.
2
Review the list of valid lifecycle hooks for Amazon ECS in CodeDeploy.
The valid hooks for ECS are BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic.
This establishes which hooks CodeDeploy expects when parsing the ECS AppSpec file.
3
Identify the unsupported hooks from the choices.
ApplicationStop and ApplicationStart are invalid for ECS, as they are part of the EC2/On-Premises deployment lifecycle.
Adding EC2-specific hooks to an ECS AppSpec file triggers validation errors during the deployment phase.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks differ based on the target compute platform (EC2 vs. ECS vs. Lambda). Using hooks designed for EC2 (such as ApplicationStop and ApplicationStart) in an ECS deployment leads to validation failures.
Question 1174Question

A software engineer is building a deployment package for an Amazon ECS service running on AWS Fargate. The application container must write logging metadata to a shared Amazon S3 bucket during execution. Additionally, the container needs to retrieve a database password stored in AWS Systems Manager Parameter Store during initialization without hardcoding it. Which of the following identity and access configuration actions must the engineer perform? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy granting S3 write access to the ECS Task Role, and reference this role as the taskRoleArn in the task definition.; Attach an IAM policy granting Systems Manager Parameter Store access to the ECS Task Execution Role, and reference the parameter in the secrets section of the container definition.

Answer

Attach an IAM policy granting S3 write access to the ECS Task Role, and attach an IAM policy granting Systems Manager Parameter Store access to the ECS Task Execution Role.
The ECS Task Role is assumed by the containerized application itself at runtime to interact with AWS services like Amazon S3. The ECS Task Execution Role is used by the ECS container agent to make AWS API calls on your behalf, such as pulling images from Amazon ECR or retrieving secrets/parameters from Systems Manager Parameter Store or Secrets Manager during the container provisioning phase.

Step-by-Step Solution

1
Define the permissions required by the application code at runtime.
An IAM policy with s3:PutObject is identified.
This permission is needed for application logic execution.
2
Associate the runtime S3 permissions with the ECS Task Role.
The ECS Task Role is configured with the S3 policy and referenced in the task definition.
The containerized application inherits these permissions at runtime.
3
Define the permissions required by the ECS agent at launch time.
An IAM policy with ssm:GetParameters is identified.
This permission is needed for the ECS agent to fetch parameters and inject them as environment variables before starting the container.
4
Associate the startup parameter retrieval permissions with the ECS Task Execution Role.
The ECS Task Execution Role is configured with the SSM policy and referenced in the task definition.
The ECS agent successfully pulls the parameters during initialization.

Key Concept

Differentiating between the ECS Task Role and the ECS Task Execution Role for application runtime permissions versus container agent startup permissions.
Question 1175Question

A developer is troubleshooting an application that streams JSON logs to an Amazon CloudWatch Logs log group. A representative log event in the log group is structured as follows:

{
"timestamp": "2026-07-14T12:00:00Z",
"level": "ERROR",
"error": {
"code": "DB_CONNECTION_FAILED",
"message": "Failed to connect to the database instance."
}
}

The developer created a CloudWatch metric filter with the pattern `{ $.error = "DB_CONNECTION_FAILED" }` to monitor database connection failures. However, the associated metric is not being populated, even though matching error logs are visible in the log group. What is the reason for this behavior?

Show answer & explanation

Answer: The filter pattern references the parent error object rather than the nested code property. It should be updated to { $.error.code = "DB_CONNECTION_FAILED" }.

Answer

The filter pattern references the parent error object rather than the nested code property. It should be updated to { $.error.code = "DB_CONNECTION_FAILED" }.
The correct answer explains that CloudWatch Logs requires a fully qualified JSON path to target a leaf node. The developer's pattern references the parent object 'error' (which evaluates to a nested map/dictionary) instead of the string property 'code'. By correcting the path to $.error.code, CloudWatch is able to successfully perform the equality comparison with the string 'DB_CONNECTION_FAILED'.

Step-by-Step Solution

1
Analyze the structured JSON log format to identify the path to the target error code.
The target string "DB_CONNECTION_FAILED" is located at the path $.error.code.
Correctly identifying the JSON hierarchy is required because CloudWatch Logs metric filters require complete JSON paths to match values.
2
Evaluate the developer's filter pattern { $.error = "DB_CONNECTION_FAILED" } against the JSON log hierarchy.
The selector $.error evaluates to the object { "code": "DB_CONNECTION_FAILED", "message": "Failed to connect to the database instance." }, which is not equal to the string "DB_CONNECTION_FAILED".
Understanding why the match fails requires evaluating the selector path's return type against the target value.
3
Select the option that fixes the path referencing issue using valid CloudWatch Logs metric filter syntax.
Updating the filter pattern to { $.error.code = "DB_CONNECTION_FAILED" } correctly compares the leaf node's string value.
This establishes a direct match on the string field, resolving the zero match issue.

Key Concept

CloudWatch Logs JSON Metric Filter Path Syntax
Question 1176Question

A CORS preflight block error is displayed in the browser console when a client-side application hosted on https://webapp.example.com sends a request to an Amazon API Gateway REST API. The API is configured with a custom Lambda Authorizer. Investigation reveals that the error occurs only when the authorizer rejects requests containing expired JSON Web Tokens (JWTs), which prevents the browser from reading the actual 401 Unauthorized status code. How should the developer resolve this issue?

Show answer & explanation

Answer: Configure Gateway Responses in API Gateway for the Unauthorized and Access Denied response types to return the required Access-Control-Allow-Origin header.

Answer

Configure Gateway Responses in API Gateway for the Unauthorized and Access Denied response types to return the required Access-Control-Allow-Origin header.
Configuring Gateway Responses in API Gateway for the Unauthorized and Access Denied response types ensures that when a request fails authentication at the custom authorizer level, the response returned by API Gateway contains the necessary Access-Control-Allow-Origin headers. This allows the browser to process the 401 or 403 HTTP status code instead of blocking the response due to CORS policy violations.

Step-by-Step Solution

1
Analyze where the failure occurs in the API Gateway execution flow.
Since the token is expired, the custom Lambda Authorizer denies the request before API Gateway invokes the backend integration.
Understanding the request flow is essential to determine whether the error originates from the backend integration or API Gateway itself.
2
Determine the source of the generated HTTP error response.
API Gateway returns a gateway-generated response (such as 401 Unauthorized or 403 Forbidden).
When an authorizer rejects a request, API Gateway short-circuits the flow and handles the response directly.
3
Identify why the browser reports a CORS error on the authentication failure.
By default, Gateway Responses generated by API Gateway do not contain CORS headers (Access-Control-Allow-Origin).
A browser will reject any cross-origin response that lacks valid Access-Control-Allow-Origin headers, even if the backend integration is configured for CORS.
4
Configure the Gateway Responses in the API Gateway console or CloudFormation template.
The Access-Control-Allow-Origin header is added to the Unauthorized and Access Denied Gateway Responses, allowing the browser to read the actual HTTP response code.
This exposes the real status code (401/403) to the frontend client, allowing correct authentication error handling.

Key Concept

API Gateway Gateway Responses are used to customize responses and inject CORS headers for requests that fail before reaching the backend integration.
Question 1177Question

A software development team configures an AWS CodeBuild project to run within a private subnet of a VPC to perform integration testing against an Amazon RDS DB instance. The integration tests connect to the database successfully, but the build project fails during the install phase when running commands to retrieve packages from a public software registry. Which of the following actions will resolve this build failure?

Show answer & explanation

Answer: Configure a NAT gateway in a public subnet of the VPC, and update the private subnet's route table to route outbound internet traffic through the NAT gateway.

Answer

Configure a NAT gateway in a public subnet of the VPC, and update the private subnet's route table to route outbound internet traffic through the NAT gateway.
The correct answer is to configure a NAT gateway in a public subnet of the VPC and update the private subnet's route table. When AWS CodeBuild projects are configured to run inside a VPC, they do not have direct internet access. If the build needs to access both private resources (such as Amazon RDS) and public registries to pull dependencies, you must place the CodeBuild project in private subnets, configure a NAT gateway in a public subnet, and route outbound internet traffic (0.0.0.0/0) through that NAT gateway.

Step-by-Step Solution

1
Analyze the network path requirements.
The CodeBuild project successfully connects to Amazon RDS (inside the private VPC) but fails to reach the public internet (external package registry).
This indicates that internal VPC routing works, but there is no outbound path to the public internet.
2
Identify the standard VPC component needed for outbound-only internet access.
A NAT gateway is required to translate private IP addresses to a public IP address for internet communication.
Resources in a private VPC subnet require a NAT gateway located in a public subnet with a route to an Internet Gateway to access external endpoints.
3
Configure routing for the private subnet.
Update the private subnet route table to target the NAT gateway for destination '0.0.0.0/0'.
This ensures all internet-bound traffic from the CodeBuild container in the private subnet is forwarded through the NAT gateway.

Key Concept

AWS CodeBuild VPC connectivity and internet access requirements
Estimated Time:1m 30s
Question 1178Question

A developer is configuring a CloudWatch Metric Filter to count the occurrences of HTTP 5xx errors from a web application's JSON-formatted log group. The JSON log events have the structure: `{"statusCode": 500, "message": "Internal Server Error"}`. The metric filter must count all events where `statusCode` is greater than or equal to 500. Which of the following configurations are required to correctly achieve this? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define the metric filter pattern as `{ $.statusCode >= 500 }` to match the JSON key-value pair.; Set the metric value in the filter configuration to 1 to increment the metric count by 1 for each matching log event.

Answer

Define the metric filter pattern as `{ $.statusCode >= 500 }` and set the metric value in the filter configuration to 1.
The correct options are the ones stating to define the metric filter pattern as `{ .statusCode >= 500 }` and to set the metric value in the filter configuration to 1. CloudWatch Logs supports filtering JSON log messages using curly braces `{}` and the `.property` notation to inspect properties of the JSON object. Specifying a metric value of 1 instructs CloudWatch to increment the metric by 1 for each matching log event.

Step-by-Step Solution

1
Select the correct pattern syntax for JSON logs.
The JSON pattern syntax requires curly braces `{}` and the JSON path operator `.` to target the `statusCode` field (e.g., `{ .statusCode >= 500 }`).
CloudWatch Logs parses JSON events dynamically, but requires the correct query structure to extract fields.
2
Configure the metric increment value.
A metric value of 1 is specified to increment the custom metric count per occurrence.
This registers each matched error event as a single count for monitoring purposes.

Key Concept

CloudWatch Logs Metric Filters syntax and configuration for JSON-formatted log events.
Estimated Time:1m 0s
Question 1179Question

An order processing workflow runs on AWS Lambda and needs to interact with an Amazon RDS PostgreSQL database located inside a private subnet of a VPC. Additionally, the function must publish event messages to an external third-party shipping API. The Lambda function is configured with access to the same private subnets as the database. While database operations succeed, the outbound HTTP requests to the shipping API fail with connection timeout errors.

Which TWO network configuration steps will resolve the outbound connectivity issue to the shipping API?

Select all that apply

Show answer & explanation

Answer: Configure a NAT Gateway within a public subnet of the VPC.; Update the route table of the private subnets to route traffic destined for 0.0.0.0/0 to the NAT Gateway.

Answer

The correct actions are to configure a NAT Gateway within a public subnet of the VPC, and to update the route table of the private subnets to route traffic destined for 0.0.0.0/0 to that NAT Gateway.
When an AWS Lambda function is configured to run inside a VPC, it utilizes Hyperplane ENIs to connect to the designated subnets. If it is attached to private subnets to communicate with internal resources like databases, it does not have access to the public internet by default. To resolve this, a NAT Gateway must be provisioned in a public subnet (which has a route to an Internet Gateway), and the route table associated with the Lambda function's private subnets must direct all outbound traffic (0.0.0.0/0) to the NAT Gateway.

Step-by-Step Solution

1
Analyze the network path for the Lambda function.
The Lambda function is running in private subnets to reach the database, meaning it lacks direct internet routing.
By default, Lambda functions associated with private subnets have no route to public endpoints unless configured with a gateway or translation instance.
2
Select the correct translation mechanism.
Deploying a NAT Gateway in a public subnet provides the necessary Network Address Translation for private resources.
A NAT Gateway maps private IP addresses to a public IP to facilitate outbound connections while shielding internal resources from unsolicited inbound traffic.
3
Configure the routing paths for outbound traffic.
Modify the route table associated with the private subnets where the Lambda function runs to forward 0.0.0.0/0 traffic to the NAT Gateway.
Resources in private subnets require an explicit route table entry pointing to the NAT Gateway to exit the VPC.

Key Concept

Lambda VPC Networking and Internet Access
Question 1180Question

A developer is migrating a backend REST API from a Lambda Custom Integration to a Lambda Proxy Integration in Amazon API Gateway. The client application is an iOS mobile app that sends a POST request to create user profiles. Previously, when the Lambda function encountered a validation error (such as a missing email address), it would throw an exception, and the developer mapped this exception to a 400 Bad Request HTTP status code using API Gateway Integration Responses. After switching the API method to use the Lambda Proxy Integration, the client application receives a 502 Bad Gateway error instead of the 400 Bad Request validation error, even though the Lambda function execution succeeds with the expected validation error logged. Which of the following modifications should the developer make to the Lambda function's code to resolve this issue and return the expected 400 Bad Request status code?

Show answer & explanation

Answer: Modify the Lambda function to catch the validation error and return a JSON object containing a statusCode key set to 400 and a body key containing a serialized JSON string of the error details.

Answer

Modify the Lambda function to catch the validation error and return a JSON object containing a statusCode key set to 400 and a body key containing a serialized JSON string of the error details.
In a Lambda Proxy Integration, Amazon API Gateway expects the backend Lambda function to return a response in a specific JSON format containing statusCode (as an integer) and body (as a stringified JSON). If the Lambda function throws an unhandled exception or returns a structure that does not conform to this contract, API Gateway cannot parse the output and returns a 502 Bad Gateway error to the client. To properly return a client-side error like 400 Bad Request in a proxy integration, the function must catch the exception and return the correct JSON format directly.

Step-by-Step Solution

1
Analyze the API Gateway integration type and the error returned.
The integration is Lambda Proxy Integration, and the client receives a 502 Bad Gateway error instead of the expected 400 Bad Request.
502 Bad Gateway errors in Lambda Proxy Integrations typically occur when the Lambda function's output does not conform to the expected format required by API Gateway.
2
Review the differences in error handling between Lambda Custom and Lambda Proxy integrations.
In Custom Integrations, API Gateway maps errors using Integration Responses. In Proxy Integrations, API Gateway relies entirely on the Lambda function returning a structured JSON response containing the status code and body.
To resolve the 502 error and return a 400 status code, the responsibility of mapping the error shifts from API Gateway configuration to the Lambda function code.
3
Formulate the correct Lambda function response payload.
The Lambda function must catch the validation exception and return an object with a statusCode of 400 and a serialized string body detailing the validation failure.
This satisfies the Lambda Proxy Integration response contract, allowing API Gateway to parse the payload and pass the 400 status code to the client.

Key Concept

API Gateway Lambda Proxy Integration Response Formatting Requirements
PreviousPage 59 / 78Next
All practice questions — AWS Certified Developer - Associate | Examkin