Examkin

All practice questions

1542 questions

All types1,542Multiple choice782Multiple select746Ordering14
Question 1301Question →

A developer is implementing a secure report retrieval feature for a corporate intranet portal. The portal's users authenticate using an Amazon Cognito User Pool. Once authenticated, the portal's client-side application needs to download private reports directly from an Amazon S3 bucket. To optimize performance and cost, the architecture must not route the file downloads through an intermediate API Gateway or Lambda function. The solution must grant users direct, short-lived access to the reports using the least privilege principle.

Which TWO configuration steps should the developer perform to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool and add the Cognito User Pool as an identity provider.; Attach an IAM policy granting s3:GetObject permissions to the IAM role associated with authenticated users in the Identity Pool.

Answer

Configure an Amazon Cognito Identity Pool and add the Cognito User Pool as an identity provider, and attach an IAM policy granting s3:GetObject permissions to the IAM role associated with authenticated users in the Identity Pool.
To authorize authenticated Cognito User Pool users to directly access private S3 resources, the developer must configure an Amazon Cognito Identity Pool that lists the User Pool as its identity provider. The developer must then attach an IAM policy granting s3:GetObject permissions to the authenticated IAM role of the Identity Pool. This allows the client-side application to obtain short-lived AWS credentials containing the necessary permissions to retrieve files directly from S3 without passing through intermediate compute layers.

Step-by-Step Solution

1
Configure the identity directory
Ensure users authenticate via the Amazon Cognito User Pool, which validates credentials and issues JSON Web Tokens (JWTs).
Provides the initial authentication mechanism and user directory.
2
Set up federated authorization
Create an Amazon Cognito Identity Pool and register the Cognito User Pool ID/App Client ID as the identity provider.
Establishes a mechanism to exchange identity tokens (JWTs) for temporary AWS credentials.
3
Configure IAM permissions
Attach an IAM policy with s3:GetObject permission for the target S3 bucket to the Identity Pool's authenticated IAM role.
Ensures that the client application receives credentials authorized to retrieve reports directly from S3.

Key Concept

Amazon Cognito Authentication and Authorization using User Pools and Identity Pools
Estimated Time:2m 0s
Question 1302Question →

A frontend web application hosted on `https://app.company.internal` receives a `403 Forbidden` error with the message 'User is not authorized to access this resource' when sending requests to various endpoints of a private Amazon API Gateway REST API. The API uses a custom Lambda Authorizer with caching enabled. The developer notes that the client's first API call to `GET /orders` succeeds, but a subsequent call to `POST /payments` by the same user within a five-minute window fails with the `403 Forbidden` error. The CloudWatch logs show the authorizer executes successfully only for the first request. Which of the following is the most likely cause of this error?

Show answer & explanation

Answer: The Lambda Authorizer generated an IAM policy document that hardcoded the specific resource ARN of the first request (`GET /orders`) instead of using wildcards, which was then cached and applied to the subsequent request.

Answer

The Lambda Authorizer generated an IAM policy document that hardcoded the specific resource ARN of the first request instead of using wildcards, which was then cached and applied to the subsequent request.
The correct answer is that the Lambda Authorizer generated a policy document that hardcoded the specific resource ARN of the first request instead of using wildcards, which was then cached and applied to the subsequent request. When authorization caching is enabled, API Gateway caches the policy document returned by the authorizer for the duration of the TTL. If the policy lists a specific resource ARN instead of a wildcard, subsequent requests to different resources or methods using the same cache key will be evaluated against that cached policy and denied with a 403 Forbidden error.

Step-by-Step Solution

1
Analyze the log behavior: the authorizer only runs on the first request and caching is enabled.
Confirm that subsequent requests are authorized using the cached policy statement rather than fresh authorizer execution.
This isolates the failure to how the cached policy document is evaluated by API Gateway for subsequent endpoints.
2
Examine the mismatch between the successful request (`GET /orders`) and the failed request (`POST /payments`).
Determine that the cached policy document must lack permissions for the `POST /payments` resource ARN.
If the authorizer code dynamically generates a policy containing the exact request ARN of the initial request and caching is enabled, subsequent calls to other endpoints with the same token will fail.
3
Identify the proper resolution for this authorization caching behavior.
The authorizer must return a policy resource ARN using wildcards (e.g., `arn:aws:execute-api:region:account-id:api-id/stage/*`) to cover all potential client calls during the cache TTL.
This allows the cached authorization state to apply correctly across different endpoints of the API.

Key Concept

API Gateway Lambda Authorizer Caching and Policy Evaluation
Question 1303Question →

A developer is monitoring a web application that writes log events to an Amazon CloudWatch Logs log group in the following JSON format:

{
"requestPath": "/payment/process",
"responseCode": 502,
"responseTimeMs": 1500
}

The developer needs to configure a CloudWatch metric filter to count the occurrences of failed payment requests where the `responseCode` is 502502 and the `responseTimeMs` is greater than 10001000 milliseconds.

Which of the following configurations are valid for this metric filter or represent correct troubleshooting actions to ensure the filter works as intended? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Define the metric filter pattern as `{ .responseCode = 502 && .responseTimeMs > 1000 }` to match the JSON properties.; Ensure that all application logs are written as valid JSON objects, as the JSON filter pattern will ignore malformed JSON or plain text.

Answer

The correct configurations are defining the metric filter pattern as `{ .responseCode = 502 && .responseTimeMs > 1000 }` and ensuring that all application logs are written as valid JSON objects.
The correct choices are using the single equals operator (`=`) inside curly braces to query JSON properties, and ensuring the log events are valid JSON. CloudWatch JSON metric filter syntax requires a single equals sign for comparison and will completely ignore log events that do not conform to valid JSON formatting.

Step-by-Step Solution

1
Analyze the format of the incoming logs to determine the appropriate filter syntax.
The logs are structured in JSON format, which means curly brace syntax `{ ... }` must be used instead of space-delimited bracket syntax `[ ... ]`.
CloudWatch Logs treats JSON and space-delimited logs differently, and using the wrong syntax results in zero matches.
2
Review the comparison operator syntax for JSON metric filters.
Confirm that a single equals sign (`=`) is the valid comparison operator for matching property values in JSON filter patterns.
Programming-style double equals (`==`) is invalid in CloudWatch filter patterns and will prevent correct evaluation.
3
Verify log ingestion format constraints.
Ensure all log entries are valid, well-formed JSON objects.
If a log entry contains malformed JSON, CloudWatch Logs will fail to parse the fields, and the filter pattern will not match the event.

Key Concept

JSON Metric Filter Syntax and Validation in CloudWatch Logs
Estimated Time:2m 0s
Question 1304Question →

A developer is building a backend application on AWS Lambda that integrates with a third-party payment gateway. The integration requires an API key that is rotated automatically every 30 days. The developer needs to store the API key securely, automate its rotation, and retrieve it in the Lambda function with minimal latency. Which storage and management approach should the developer use to meet these requirements with the least operational effort?

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager. Configure automated rotation in AWS Secrets Manager by writing a custom AWS Lambda rotation function, and retrieve the key in the backend Lambda function using the AWS SDK with local caching.

Answer

Store the API key in AWS Secrets Manager, configure automated rotation using a custom Lambda function, and retrieve the key in the backend Lambda function using the AWS SDK with local caching.
Storing the API key in AWS Secrets Manager and configuring a custom Lambda rotation function allows AWS to natively manage the rotation schedule and execution. The application Lambda function retrieves the key at runtime using the AWS SDK, and caching it locally ensures subsequent invocations do not call Secrets Manager unnecessarily, minimizing latency and API costs.

Step-by-Step Solution

1
Create a secret in AWS Secrets Manager to store the third-party payment gateway API key.
The API key is securely encrypted and stored.
AWS Secrets Manager is optimized for securing credentials and sensitive values.
2
Configure AWS Secrets Manager rotation settings by linking a custom AWS Lambda rotation function and setting the schedule to 30 days.
Secrets Manager automatically invokes the Lambda function on schedule to update the secret value.
This automates the rotation lifecycle with native orchestrations instead of custom cron schedulers.
3
Update the application Lambda function to retrieve the API key using the AWS SDK and cache the value in memory.
The key is fetched at startup or initialization and reused across invocations, lowering latency and reducing cost.
Local caching minimizes the number of API calls to AWS Secrets Manager.

Key Concept

Automating secret rotation using AWS Secrets Manager vs manual orchestration or insecure alternatives.
Question 1305Question →

A developer is designing a web application that uses Amazon Cognito User Pools for user authentication and Amazon API Gateway REST APIs for the backend. The API endpoints must be secured so that only users with an 'Active' subscription can access them. The subscription status is stored in an external Amazon DynamoDB table and updated in real-time, which prevents it from being stored as a static attribute in the Cognito ID or access tokens. Which solution should the developer implement to secure the API Gateway endpoints?

Show answer & explanation

Answer: Implement an API Gateway Lambda Authorizer that validates the incoming Cognito token, queries the DynamoDB table to verify the user's subscription status, and returns an IAM policy to allow or deny the request.

Answer

Implement an API Gateway Lambda Authorizer that validates the incoming Cognito token, queries the DynamoDB table to verify the user's subscription status, and returns an IAM policy to allow or deny the request.
An API Gateway Lambda Authorizer allows custom authorization logic. In this scenario, it can parse and validate the Cognito token to authenticate the user, query DynamoDB to check the real-time subscription status, and dynamically generate an IAM policy that allows or denies access to the API resources.

Step-by-Step Solution

1
Analyze the authentication and authorization requirements.
Authentication is handled by Cognito User Pools (JWT tokens are provided to the client). Authorization requires a real-time check against an external DynamoDB table.
Determines whether the built-in Cognito Authorizer is sufficient or if a custom authorization mechanism is required.
2
Evaluate the capabilities of the native Cognito User Pool Authorizer.
The native authorizer can only validate token signatures, expiration, and audience. It cannot perform external lookups or query DynamoDB.
Eliminates solutions relying solely on the built-in Cognito User Pool Authorizer for dynamic database checks.
3
Select and configure an API Gateway Lambda Authorizer.
The Lambda Authorizer receives the token, decodes and validates it, queries DynamoDB for the real-time subscription status, and returns an IAM policy.
Provides the custom validation logic needed to satisfy the real-time subscription requirement before the request reaches the backend.

Key Concept

Using API Gateway Lambda Authorizers for custom, dynamic authorization checks that cannot be performed by built-in Cognito Authorizers.
Estimated Time:1m 30s
Question 1306Question →

A developer is testing a Java application locally that uses the AWS SDK for Java v2 to retrieve objects from an Amazon S3 bucket. The application initializes the S3 client using S3Client.create(). When running the application locally, it fails with a software.amazon.awssdk.core.exception.SdkClientException stating that it is unable to load credentials from any of the providers in the default chain. The developer has configured the credentials in the local ~/.aws/credentials file under a profile named developer-local.

Which two actions should the developer take to resolve this credentials loading issue? (Select two.)

Select all that apply

Show answer & explanation

Answer: Set the environment variable AWS_PROFILE to developer-local in the local command shell before running the application.; Define the JVM system property -Daws.profile=developer-local when launching the Java application.

Answer

Setting the AWS_PROFILE environment variable to developer-local or defining the JVM system property -Daws.profile=developer-local directs the AWS SDK for Java v2 to use the credentials associated with that profile from the credentials file.
The correct options are setting the environment variable AWS_PROFILE to developer-local or using the JVM system property -Daws.profile=developer-local. The DefaultCredentialsProvider in the AWS SDK for Java v2 automatically checks the system property and the environment variable to determine which profile to use when loading credentials from the shared credentials file.

Step-by-Step Solution

1
Analyze the client exception showing that the default credentials provider chain is unable to find any credentials.
Understand that the application uses the default S3Client.create() method, which checks standard environment variables, system properties, and profiles.
Since credentials are set under a custom profile ('developer-local') instead of the default profile, the SDK needs to be directed to look up the correct profile.
2
Evaluate mechanisms to specify the profile name to the SDK without modifying the code.
Identify that setting the environment variable AWS_PROFILE or using the system property -Daws.profile are standard methods supported by the AWS SDK for Java v2.
Both methods configure the environment so the default credentials provider reads the 'developer-local' credentials block from the credentials file.

Key Concept

AWS SDK Credential Provider Chain Resolution for Local Development Profiles
Question 1307Question →

A `502 Bad Gateway` error occurs when a locally running Electron desktop application sends an HTTP `POST` request to an Amazon API Gateway REST API. The developer also notices a CORS failure message in the application logs: 'Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin'. The API Gateway endpoint uses a Lambda proxy integration. The backend Lambda function's logs in Amazon CloudWatch show that the function completes successfully and returns the following structure:

{
"status": 200,
"body": {
"message": "Data processed successfully",
"itemId": "12345"
}
}

Which changes must the developer make to resolve both the `502 Bad Gateway` error and the CORS block? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the Lambda function's output to use the key 'statusCode' instead of 'status', and convert the JSON object in 'body' into a stringified JSON format.; Add a 'headers' object containing the 'Access-Control-Allow-Origin' key set to 'http://localhost:8080' inside the Lambda function's returned JSON payload.

Answer

To resolve the issues, the developer must modify the Lambda function to return a correctly formatted JSON response with a 'statusCode' key and a stringified JSON 'body' to resolve the 502 Bad Gateway error. The developer must also add the 'Access-Control-Allow-Origin' header to the 'headers' map in the Lambda function's response to resolve the CORS block.
To fix the 502 Bad Gateway error under a Lambda proxy integration, the Lambda function's output must contain the 'statusCode' key (rather than 'status') and the 'body' must be stringified. To resolve the CORS failure, the response payload from the Lambda function must explicitly contain the CORS headers, such as 'Access-Control-Allow-Origin', in the 'headers' object.

Step-by-Step Solution

1
Correct the response key.
Change the key 'status' to 'statusCode' in the Lambda function's return payload.
API Gateway's parser requires the exact key name 'statusCode' to interpret the HTTP response status code in a Lambda proxy integration.
2
Stringify the body content.
Apply JSON.stringify() to the 'body' object.
Under Lambda proxy integration, API Gateway expects the 'body' property to be a raw text string, not a nested JSON object.
3
Add the CORS header to the Lambda response.
Insert 'headers': { 'Access-Control-Allow-Origin': 'http://localhost:8080' } into the Lambda return object.
Since Lambda proxy bypasses API Gateway's integration responses, the backend function must return all HTTP headers required by the client browser.

Key Concept

Lambda Proxy Integration Response Format and CORS Configuration
Question 1308Question →

A company runs a logistics tracking service on AWS Fargate. The application needs to retrieve a sensitive API key for a third-party shipping service dynamically at runtime. The API key is managed by a separate security team in a dedicated AWS account, where it must be rotated every 90 days. The Fargate tasks in the application account must access this key securely. To implement this configuration, which two steps should be performed? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a secret in AWS Secrets Manager within the security account, and apply a resource-based policy to allow retrieval from the application account's Fargate task roles.; Configure an AWS Lambda function in the security account to handle the API key rotation, and associate it with the Secrets Manager secret on a 90-day schedule.

Answer

To securely share and rotate the key across accounts, the developer must use AWS Secrets Manager in the security account with a resource-based policy permitting access to the application's Fargate task roles, and configure a custom AWS Lambda function to perform the 90-day rotation.
To support both cross-account access and automated rotation, AWS Secrets Manager is the correct service choice. A resource-based policy attached directly to the secret allows the application's Fargate task roles in a separate account to read the secret directly. Additionally, Secrets Manager integrates with AWS Lambda to orchestrate the rotation logic on a schedule.

Step-by-Step Solution

1
Select the proper service for cross-account access and rotation.
AWS Secrets Manager is chosen instead of Systems Manager Parameter Store.
Secrets Manager natively supports resource-based policies for cross-account access and has built-in rotation functionality, whereas Parameter Store parameters do not support resource-based policies.
2
Configure permissions for the Fargate tasks.
Attach a resource-based policy to the Secrets Manager secret allowing the Fargate task roles to retrieve it.
Dynamic runtime API calls by application code require permissions attached to the task role itself, not the task execution role.
3
Implement the automatic rotation.
Create a Lambda function to perform rotation and set the rotation schedule on the secret to 90 days.
AWS Secrets Manager uses a Lambda function to execute rotation workflows automatically.

Key Concept

Cross-account access and automatic rotation of sensitive credentials using AWS Secrets Manager, and distinguishing between Fargate task roles and task execution roles.
Question 1309Question →

An IoT startup is developing a dashboard web application that allows users to authenticate using external social providers (Google and Apple) via Amazon Cognito. Once authenticated, the web application must interact with two backend systems:
1. Make authenticated requests to an Amazon API Gateway HTTP API that manages dashboard configurations.
2. Directly publish sensor telemetry data to an Amazon Kinesis Data Stream.

Which TWO configurations must the developer implement to secure access to these resources? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool federated with Google and Apple, and set up an Amazon API Gateway JWT authorizer that validates the identity tokens issued by the User Pool.; Configure an Amazon Cognito Identity Pool that integrates with the User Pool as an identity provider, and associate an IAM role with the authenticated identities that grants kinesis:PutRecord permissions.

Answer

To secure the HTTP API, configure a User Pool federated with Google and Apple and use an API Gateway JWT authorizer. To authorize direct Kinesis writes, configure an Identity Pool that exchanges User Pool tokens for temporary AWS credentials with the required IAM policy.
Setting up a Cognito User Pool with Google and Apple federation allows the application to authenticate users and receive JSON Web Tokens (JWTs). These JWTs can be natively validated by an API Gateway HTTP API JWT authorizer. An Identity Pool takes the token from the authenticated User Pool session and exchanges it for temporary AWS credentials via an IAM role, which allows the application to directly call the Kinesis API.

Step-by-Step Solution

1
Determine how to authenticate users via Google and Apple and secure API Gateway HTTP API routes.
Identify that an Amazon Cognito User Pool acts as the user directory and identity provider (IdP), and that API Gateway HTTP APIs can use a native JWT authorizer to validate the issued token.
User Pools handle authentication and federation with social providers, while API Gateway JWT authorizers offer low-latency, built-in validation of these user pool tokens.
2
Determine how the client application can write to the Amazon Kinesis Data Stream directly.
Identify that the client needs temporary AWS credentials authorized via an IAM role to call the Kinesis API.
Cognito Identity Pools exchange Cognito User Pool tokens for temporary AWS security credentials, enabling direct, secure client access to AWS resources like Kinesis.
3
Associate the IAM role with the correct Cognito construct.
Configure the Cognito Identity Pool with the authenticated IAM role containing the kinesis:PutRecord policy.
This maps authenticated users to the specific AWS IAM policy required to publish telemetry data to Kinesis.

Key Concept

Distinguishing and integrating Amazon Cognito User Pools for user authentication and Identity Pools for AWS resource authorization.
Estimated Time:2m 0s
Question 1310Question →

A developer is troubleshooting an application locally on their workstation. They are running a Node.js application that uses the AWS SDK for JavaScript (v3) to upload objects to an Amazon S3 bucket.

The developer has configured a profile named `staging` in their local `~/.aws/credentials` file:

ini
[staging]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

They also set the following environment variables in their terminal session:

bash
export AWS_PROFILE=staging
export AWS_ACCESS_KEY_ID=AKIAIADSTESTINGEXAMPLE
export AWS_SECRET_ACCESS_KEY=mockKeyStagingExampleKey

When running the application, the developer receives access denied errors because the SDK attempts to authenticate using the `AKIAIADSTESTINGEXAMPLE` credentials (which are invalid) rather than the credentials specified in the `staging` profile.

Which action should the developer take to ensure the SDK uses the `staging` profile credentials?

Show answer & explanation

Answer: Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.

Answer

Unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables.
The correct action is to unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. The AWS SDK default credential provider chain evaluates environment variables for credentials first. If AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are set, they are used immediately, ignoring any configured profiles or file-based credentials. By unsetting these variables, the provider chain falls back to using the profile specified in the AWS_PROFILE environment variable, which resolves to the staging credentials.

Step-by-Step Solution

1
Analyze the AWS SDK default credential provider chain resolution order.
Identify that the chain checks environment variables (AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY) first, before shared credentials/config files or the AWS_PROFILE variable.
This explains why the invalid credentials in the environment variables are being used instead of the configuration under the 'staging' profile.
2
Determine the necessary change to make the SDK fall back to the credentials file.
Unsetting the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables removes them from the top of the provider chain.
Once the explicit credentials variables are cleared, the default chain falls back to looking at the AWS_PROFILE environment variable and the credentials file.

Key Concept

AWS SDK credential provider chain precedence
Question 1311Question →

A developer is configuring a blue/green deployment for a containerized application on Amazon ECS using AWS CodeDeploy. The deployment configuration utilizes an Application Load Balancer with two target groups and a test listener. The developer wants to run automated integration tests against the replacement task set via the test listener to validate the new version of the application before shifting any production traffic.

Which AppSpec lifecycle hook should the developer use to run these integration tests?

Show answer & explanation

Answer: AfterAllowTestTraffic

Answer

AfterAllowTestTraffic
The correct answer is the hook named AfterAllowTestTraffic. During an ECS blue/green deployment, AWS CodeDeploy executes hooks in a specific order: BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic. The test listener begins routing traffic to the replacement task set just before AfterAllowTestTraffic runs. This is the only point where the application is reachable via the test listener for validation tests before the production listener is updated to point to the replacement task set.

Step-by-Step Solution

1
Analyze the deployment architecture and requirements.
The target is Amazon ECS using AWS CodeDeploy for blue/green deployment. The requirement is to run automated integration tests against the replacement (new) task set using the test listener before shifting production traffic.
Understanding the target platform and specific validation workflow constraints is essential for selecting the correct lifecycle hook.
2
Map the sequence of AWS CodeDeploy ECS lifecycle hooks.
The ECS lifecycle hooks run in the following order: BeforeInstall -> AfterInstall -> AfterAllowTestTraffic -> BeforeAllowTraffic -> AfterAllowTraffic. The test listener starts routing traffic to the replacement tasks just before the AfterAllowTestTraffic hook runs.
Identifying the execution order of ECS hooks allows us to determine when the replacement tasks are reachable via the test listener.
3
Select the hook that matches the requirement of using the test listener for validation.
The AfterAllowTestTraffic hook is executed after the test listener begins routing traffic to the replacement task set. This allows running tests against the test listener endpoint.
Running tests at any other stage would fail because the replacement task set would not yet be reachable via the test listener.

Key Concept

AWS CodeDeploy ECS Blue/Green Lifecycle Hooks
Question 1312Question →

A developer is troubleshooting an application deployed on Amazon ECS that writes logs to an Amazon CloudWatch Logs log group. The developer created a CloudWatch subscription filter to route log events containing the phrase `CRITICAL_ERROR` to an AWS Lambda function for real-time alerting. Although the developer verified that `CRITICAL_ERROR` is present in the log streams, the Lambda function is never invoked. Which two configurations or troubleshooting steps should the developer verify to resolve this issue?

Select all that apply

Show answer & explanation

Answer: Verify that the resource-based policy of the target Lambda function allows the CloudWatch Logs service principal (`logs.amazonaws.com`) to perform the `lambda:InvokeFunction` action.; Confirm that the subscription filter pattern matches the exact casing of `CRITICAL_ERROR`, as CloudWatch Logs filter patterns are case-sensitive.

Answer

Verify that the resource-based policy of the target Lambda function allows the CloudWatch Logs service principal to perform the invoke action, and confirm that the subscription filter pattern matches the exact casing of the error keyword, as CloudWatch Logs filter patterns are case-sensitive.
The correct options state that the Lambda resource-based policy must allow the CloudWatch Logs service principal to invoke the function, and that the filter pattern casing must be verified due to case sensitivity. CloudWatch Logs invokes Lambda asynchronously using a push model. For this invocation to succeed, the Lambda function must have a resource-based policy that explicitly allows 'logs.amazonaws.com' to call 'lambda:InvokeFunction'. Furthermore, CloudWatch subscription filters perform case-sensitive matching on term literals, meaning any casing mismatch will prevent matches and invocations.

Step-by-Step Solution

1
Analyze the log delivery model of CloudWatch subscription filters.
CloudWatch Logs uses a push-model to invoke target Lambda functions, which requires resource-based permissions on the target Lambda function.
Since CloudWatch Logs is initiating the invocation, it must have the lambda:InvokeFunction permission granted to logs.amazonaws.com in the Lambda resource-based policy.
2
Examine the filter pattern matching characteristics.
CloudWatch Logs filter patterns are case-sensitive when evaluating text patterns.
If the subscription filter pattern is defined with incorrect casing, it will not match the log messages containing 'CRITICAL_ERROR'.

Key Concept

CloudWatch Logs subscription filters push events to target destinations like AWS Lambda using resource-based policies for authorization, and evaluate log streams using case-sensitive pattern matching.
Question 1313Question →

A developer is using AWS Serverless Application Model (SAM) to deploy a database-backed API. The database password is saved as a SecureString in AWS Systems Manager Parameter Store. The developer attempts to reference this password in the SAM template's `Parameters` section as follows:

yaml
Parameters:
DbPassword:
Type: AWS::SSM::Parameter::Value<String>
Default: /prod/db/password

During the `sam deploy` process, AWS CloudFormation returns a validation error indicating that `AWS::SSM::Parameter::Value<String>` cannot reference SSM SecureString parameters.

How should the developer resolve this deployment failure while keeping the database password secure?

Show answer & explanation

Answer: Remove the parameter from the template's `Parameters` section and reference it directly in the function's environment variables using the `{{resolve:ssm-secure:/prod/db/password}}` dynamic reference.

Answer

Remove the parameter from the template's `Parameters` section and reference it directly in the function's environment variables using the `{{resolve:ssm-secure:/prod/db/password}}` dynamic reference.
AWS CloudFormation parameters cannot resolve SSM SecureString parameters when using the `AWS::SSM::Parameter::Value<String>` type. To secure and dynamically retrieve sensitive configuration data from Parameter Store, developers must use dynamic references. By removing the parameter from the template's `Parameters` section and referencing `{{resolve:ssm-secure:/prod/db/password}}` directly within the resource properties (e.g., inside the environment variables of the function), the secure value is retrieved securely at deployment time without validation errors.

Step-by-Step Solution

1
Identify the cause of the CloudFormation deployment validation error.
CloudFormation parameters of type `AWS::SSM::Parameter::Value<String>` do not support SSM SecureString parameters to prevent accidental exposure of secrets.
This is a native limitation of AWS CloudFormation's Parameter Store integration.
2
Replace the static parameter declaration with a dynamic reference in the template.
Remove the parameter definition from the `Parameters` section and instead reference the SecureString using the dynamic reference format: `{{resolve:ssm-secure:/prod/db/password}}`.
Dynamic references tell CloudFormation to resolve the value from SSM at deployment/runtime without exposing the value in the template definition.
3
Ensure the Lambda execution role has permissions to read the parameter.
The Lambda function's IAM role permissions (not the trust policy) must allow `ssm:GetParameters` or `ssm:GetParameter` for the resource path.
This enables the Lambda execution context to successfully resolve the value.

Key Concept

AWS SAM Integration with Systems Manager Parameter Store Secure Strings
Question 1314Question →

A developer is building a corporate portal where employees must sign in using their existing SAML 2.0 Identity Provider (IdP) credentials. The portal's backend API, hosted on Amazon API Gateway, requires custom user claims such as department and employee ID to perform fine-grained authorization. Which configuration will meet these requirements with the least development effort?

Show answer & explanation

Answer: Configure the SAML 2.0 IdP as a federated identity provider in a Cognito User Pool, map the SAML assertions to the corresponding user pool attributes, and configure API Gateway to use a Cognito User Pool authorizer.

Answer

Configure the SAML 2.0 IdP as a federated identity provider in a Cognito User Pool, map the SAML assertions to the corresponding user pool attributes, and configure API Gateway to use a Cognito User Pool authorizer.
Configuring the SAML 2.0 IdP within a Cognito User Pool and mapping its assertions to user pool attributes allows the identity directory to generate JWT ID/access tokens containing the custom claims. Using the native Cognito User Pool authorizer in API Gateway validates these tokens automatically, presenting the claims to the backend integration with minimal configuration and no custom code.

Step-by-Step Solution

1
Set up a Cognito User Pool and add the SAML 2.0 IdP as a federated provider using the IdP's metadata document.
Cognito User Pool is established as the directory that federates authentication to the external corporate SAML IdP.
This establishes the identity provider trust relationship and configures the user authentication source.
2
Configure SAML attribute mapping in Cognito User Pool settings to map incoming SAML assertions (e.g., department, employee ID) to standard or custom user pool attributes.
The federated user's identity tokens generated by Cognito (ID token and Access token) will automatically contain these mapped claims.
This ensures the backend API can access the required custom claims in the authorization payload.
3
Configure an API Gateway Cognito User Pool Authorizer on the API methods, referencing the user pool.
API Gateway automatically validates the incoming ID token sent in the Authorization header and passes the claims to the backend integration context.
This performs token validation and supplies the custom claims to the API with zero custom code or Lambda execution overhead.

Key Concept

Amazon Cognito User Pools support SAML 2.0 federation and direct attribute mapping, allowing standard API Gateway Cognito Authorizers to automatically validate tokens and pass mapped claims to backend integrations without custom Lambda code.
Question 1315Question →

A developer is deploying a microservice to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. The microservice needs to read messages from an Amazon SQS queue and write records to an Amazon DynamoDB table. During startup, the ECS container agent must pull the container image from Amazon Elastic Container Registry (Amazon ECR) and send container logs to Amazon CloudWatch Logs. Which configuration of IAM roles should the developer specify in the task definition to satisfy these requirements with the least privilege?

Show answer & explanation

Answer: Assign an IAM role with permissions for SQS and DynamoDB as the Task Role, and assign an IAM role with permissions for ECR and CloudWatch Logs as the Task Execution Role.

Answer

Assign an IAM role with permissions for SQS and DynamoDB as the Task Role, and assign an IAM role with permissions for ECR and CloudWatch Logs as the Task Execution Role.
The correct configuration assigns the application permissions (SQS and DynamoDB) to the Task Role, and infrastructure/agent permissions (ECR image pull and CloudWatch logging) to the Task Execution Role. The ECS agent needs the Task Execution Role to pull the container image and set up logs before starting the container, while the application code inside the container uses the Task Role to interact with AWS services.

Step-by-Step Solution

1
Identify the credentials required by the application code running inside the container.
The application code requires SQS and DynamoDB access.
The containerized application needs these permissions to execute its business logic after startup.
2
Identify the permissions required by the Amazon ECS container agent to provision and start the task.
The ECS agent requires ECR image pull and CloudWatch logging permissions.
These permissions are needed by the container agent before the container is running.
3
Map these requirements to the appropriate ECS task definition parameters.
The Task Role is assigned to the application, and the Task Execution Role is assigned to the ECS agent.
This separation follows the AWS security model and least-privilege principles.

Key Concept

ECS Task Role vs. ECS Task Execution Role distinction in IAM configurations
Estimated Time:1m 30s
Question 1316Question →

A developer is deploying a web application to Amazon EC2 instances. The application requires access to a sensitive API key for a third-party marketing platform. The company's security policy mandates that the API key must be encrypted at rest and rotated every 90 days. The developer wants to implement a solution that supports automatic rotation with minimal custom code. Which service and configuration should the developer choose to store and manage the API key?

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager. Configure an AWS Lambda function to perform the rotation logic, and associate it with the secret to rotate every 90 days.

Answer

Store the API key in AWS Secrets Manager. Configure an AWS Lambda function to perform the rotation logic, and associate it with the secret to rotate every 90 days.
Storing the API key in AWS Secrets Manager and using a custom AWS Lambda function for rotation is the correct approach. Secrets Manager natively supports automatic rotation of secrets using Lambda functions. Since this is a third-party API key, a custom Lambda function is required to perform the rotation steps, meeting the 90-day rotation requirement with minimal custom code.

Step-by-Step Solution

1
Evaluate the security and rotation requirements for the sensitive API key.
Identify that the API key must be encrypted at rest and automatically rotated every 90 days.
Establishing these requirements guides the selection of the correct AWS service that supports automatic secret rotation.
2
Compare AWS Secrets Manager and Systems Manager Parameter Store capabilities.
AWS Secrets Manager is selected because it provides built-in rotation functionality via integration with AWS Lambda, whereas Parameter Store does not support native automatic rotation.
Secrets Manager is designed specifically for managing secrets that require automatic rotation, while Parameter Store is suited for configuration management.
3
Configure the rotation mechanism for the non-AWS resource (third-party API).
A custom AWS Lambda function is configured to handle the specific rotation logic for the third-party marketing platform, and the rotation schedule is set to 90 days on the Secrets Manager secret.
For non-RDS and third-party services, Secrets Manager uses a Lambda function to perform the steps required to rotate the credentials.

Key Concept

AWS Secrets Manager vs. AWS Systems Manager Parameter Store for secrets rotation
Estimated Time:1m 30s
Question 1317Question →

A CORS preflight blocked error is displayed in the browser console when a client-side SvelteKit application hosted on https://manager.fleet-ops.net sends a POST request to an Amazon API Gateway REST API. The request includes a custom HTTP header named X-Client-Session-ID. The developer had previously enabled CORS on the API Gateway resource, which created an OPTIONS method returning the standard headers Access-Control-Allow-Origin and Access-Control-Allow-Methods. Which action must the developer take to resolve this CORS validation error?

Show answer & explanation

Answer: Update the API Gateway OPTIONS method integration response to include X-Client-Session-ID in the Access-Control-Allow-Headers header value, and redeploy the API.

Answer

Update the OPTIONS method integration response in API Gateway to include the custom header in the Access-Control-Allow-Headers list, then deploy the API.
When a client application includes a custom HTTP header such as X-Client-Session-ID, the browser automatically sends a preflight OPTIONS request before the actual POST request. The OPTIONS method is typically configured in API Gateway using a Mock integration. To allow the request to proceed, the OPTIONS method's integration response must include the custom header name in its Access-Control-Allow-Headers value. The API must then be redeployed to apply the configuration change.

Step-by-Step Solution

1
Identify the stage of the failure.
The failure occurs during the preflight (OPTIONS) request, before the actual POST request is sent.
Since the client application includes a custom header, the browser initiates a preflight request which must pass CORS validation first.
2
Identify the required header parameter for custom headers.
The response to the preflight OPTIONS request must include the Access-Control-Allow-Headers header containing the name of the custom header.
Browsers reject requests with custom headers unless the destination server explicitly lists those headers as allowed.
3
Apply the configuration change and deploy.
Add the custom header to the OPTIONS method integration response in API Gateway and deploy the API to push changes to the active stage.
Changes made to the API Gateway configuration do not take effect until the API is deployed to a stage.

Key Concept

CORS preflight request handling with custom headers in API Gateway
Question 1318Question →

A developer is building a mobile application that needs to upload user-generated files directly to a private Amazon S3 bucket. The developer has configured an Amazon Cognito User Pool to handle user registration and sign-in. After successfully logging in, users receive JSON Web Tokens (JWTs), but the application receives an Access Denied error (HTTP 403) when attempting to upload files using the AWS SDK. Which two actions should the developer take to resolve this authorization failure? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create and configure an Amazon Cognito Identity Pool, specifying the Cognito User Pool as the authentication provider.; Attach an IAM policy to the Cognito Identity Pool's authenticated IAM role that allows the s3:PutObject action on the target S3 bucket.

Answer

Create and configure an Amazon Cognito Identity Pool with the User Pool as the authentication provider, and attach an IAM policy allowing the s3:PutObject action to the authenticated IAM role associated with the Identity Pool.
To resolve the authorization failure for direct S3 uploads, the application needs to use an Amazon Cognito Identity Pool to exchange Cognito User Pool tokens for temporary AWS credentials, and the authenticated IAM role associated with the Identity Pool must have an IAM policy attached that grants the s3:PutObject permission.

Step-by-Step Solution

1
Integrate Cognito Identity Pools
The application can now exchange authentication tokens for temporary AWS security credentials.
Cognito User Pools only authenticate users (providing identity tokens), but Cognito Identity Pools are required to authorize users to access AWS services directly by providing temporary AWS credentials.
2
Define permissions for authenticated users
The authenticated IAM role is configured with write permissions to the S3 bucket.
Once the identity pool is established, AWS assigns an IAM role to authenticated users. This role must carry the specific permissions (such as s3:PutObject) required to perform actions on the target AWS resource.

Key Concept

Federated identities in Cognito require both a User Pool for authentication and an Identity Pool for authorizing direct access to AWS resources using IAM roles.
Estimated Time:2m 0s
Question 1319Question →

A client-side Angular dashboard hosted on https://dashboard.cloudflow.net is integrated with an Amazon API Gateway REST API. When sending a PUT request to update user preferences, the browser console displays a CORS preflight blocked error. The API Gateway is configured with a Lambda proxy integration. Which two actions must the developer perform to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the API Gateway resource to handle the OPTIONS preflight request and return the appropriate Access-Control-Allow-Methods and Access-Control-Allow-Origin headers.; Update the backend Lambda function response payload to include the Access-Control-Allow-Origin header in the headers map.

Answer

Configure the API Gateway resource to handle the OPTIONS preflight request and return the appropriate Access-Control headers, and update the backend Lambda function response payload to include the Access-Control-Allow-Origin header in the headers map.
Resolving a CORS issue with a Lambda proxy integration requires addressing two parts of the request cycle: the preflight handshake and the actual request. First, the OPTIONS preflight request must be enabled on the API Gateway resource to return the allowed methods, headers, and origin. Second, because it is a proxy integration, the backend Lambda function itself must return the Access-Control-Allow-Origin header in the response payload of the actual request.

Step-by-Step Solution

1
Configure the OPTIONS method in API Gateway.
The API Gateway OPTIONS method handles the preflight handshake, returning Access-Control-Allow-Methods, Access-Control-Allow-Origin, and Access-Control-Allow-Headers to satisfy browser preflight checks.
Before sending non-simple HTTP requests (such as PUT), browsers send a preflight OPTIONS request to verify permissions.
2
Modify the backend Lambda function code to return CORS headers.
The Lambda function's return payload now includes the Access-Control-Allow-Origin header within its headers block, alongside the statusCode and body fields.
With Lambda proxy integrations, API Gateway does not modify the integration response headers; the backend integration itself must supply the required CORS headers for the actual request.

Key Concept

Handling CORS in API Gateway with Lambda Proxy Integration
Question 1320Question →

An engineer is deploying a serverless application using a template that defines a Lambda function triggered by an Amazon S3 event. The function needs to execute with a custom IAM role. During the deployment, the stack fails to create the resources successfully. The relevant section of the template is structured as follows:

yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
ProcessFileFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs20.x
Role: !GetAtt ProcessingRole.Arn
ProcessingRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal: Service: s3.amazonaws.com
Action: sts:AssumeRole

Which of the following modifications will resolve the deployment failure and allow the Lambda function to assume the role?

Show answer & explanation

Answer: Update the Service principal under the AssumeRolePolicyDocument of the ProcessingRole to lambda.amazonaws.com.

Answer

Update the Service principal under the AssumeRolePolicyDocument of the ProcessingRole to lambda.amazonaws.com.
The correct answer updates the Service principal in the trust policy to lambda.amazonaws.com. An IAM execution role for a Lambda function must have a trust relationship that allows the lambda.amazonaws.com service principal to perform the sts:AssumeRole action. Even though the function is triggered by S3, the S3 service does not assume the Lambda execution role directly; instead, S3 invokes the function, and the Lambda service assumes the role to execute the function runtime.

Step-by-Step Solution

1
Analyze the resource definitions in the template.
The template defines an AWS::Serverless::Function and a custom AWS::IAM::Role named ProcessingRole.
To understand the relationship between the Lambda function execution role and its configuration.
2
Inspect the AssumeRolePolicyDocument of the custom role.
The trust policy has the Service principal set to s3.amazonaws.com.
The trust policy dictates which AWS service or identity is allowed to assume the role. The Lambda execution role must be assumed by the AWS Lambda service (lambda.amazonaws.com) to execute the function code, not the event source (s3.amazonaws.com).
3
Select the correction that updates the trust relationship correctly.
Changing the principal service to lambda.amazonaws.com allows AWS Lambda to assume the role.
This establishes the correct trust relationship so the execution role can be successfully used by the function.

Key Concept

AWS Lambda Execution Role Trust Policy
PreviousPage 66 / 78Next
All practice questions — AWS Certified Developer - Associate | Examkin