Security

390 questions

All types390 Multiple choice195 Multiple select195

A developer is designing a serverless backend where a single-page application (SPA) needs to access a private REST API hosted on Amazon API Gateway. The developer wants to authenticate users using an Amazon Cognito User Pool and grant them access to the API Gateway endpoints. The client application needs to acquire a JSON Web Token (JWT) after user login and pass it to API Gateway for validation. Which configuration should the developer implement in API Gateway to authorize these requests with the least administrative effort and cost?

Create a Cognito User Pool Authorizer in API Gateway, and configure the API method to use this authorizer while specifying the Identity Source header.

Create a custom Lambda authorizer that receives the JWT, validates it using the Cognito public JSON Web Key Set (JWKS), and returns an IAM policy allowing the method execution.

Create an Amazon Cognito Identity Pool, configure API Gateway to use AWS_IAM authorization, and configure the client application to directly pass the Cognito Identity Pool ID in the request header.

Enable Lambda Proxy integration for the integration request, and parse the Cognito JWT inside the backend Lambda function to perform authorization checks before processing the business logic.

Show answer & explanation

Answer: Create a Cognito User Pool Authorizer in API Gateway, and configure the API method to use this authorizer while specifying the Identity Source header.

Answer

Create a Cognito User Pool Authorizer in API Gateway, and configure the API method to use this authorizer while specifying the Identity Source header.

The correct option is to create a Cognito User Pool Authorizer in API Gateway and configure the API method to use this authorizer. This option represents the native integration designed specifically for Amazon Cognito User Pools. It automatically validates incoming JWT signatures, expiration, and audiences at the API Gateway edge, requiring zero custom code and adding no extra execution costs for custom Lambda authorizers.

Step-by-Step Solution

Identify the authentication source and token type.

The authentication source is an Amazon Cognito User Pool, and the token is a standard JWT.

This determines which authorization mechanisms are natively supported by API Gateway.

Evaluate native API Gateway features against custom solutions.

API Gateway offers a built-in Cognito User Pool Authorizer that handles JWT validation natively.

A native feature reduces administrative overhead, eliminates the need for custom Lambda authorizers, and minimizes costs.

Configure the method execution settings.

Bind the API method to the Cognito User Pool Authorizer and define the header where the JWT will be supplied.

This ensures the API Gateway enforces authorization at the entry point prior to routing requests downstream.

Key Concept

API Gateway Cognito User Pool Authorizer

Estimated Time:1m 30s

Question 42Question →

A developer is implementing a serverless application where an AWS Lambda function in Account A ( $111122223333$ ) needs to access a DynamoDB table in Account B ( $444455556666$ ). The developer creates an IAM role named `CrossAccountDynamoDBRole` in Account B that has the required permissions to access the DynamoDB table. The Lambda function is configured with an execution role named `arn:aws:iam::111122223333:role/LambdaExecutionRole` and runs code that calls the `AssumeRole` API of AWS Security Token Service (STS) to assume `CrossAccountDynamoDBRole`.

However, when the Lambda function runs, the `AssumeRole` call fails with an `AccessDenied` error. The developer reviews the trust policy of `CrossAccountDynamoDBRole` in Account B:

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

Which modification to the trust policy of `CrossAccountDynamoDBRole` in Account B will resolve this error?

Keep the service principal as `lambda.amazonaws.com` but add a condition to restrict the `aws:SourceArn` to the Lambda function's ARN:

"Condition": {
"ArnEquals": {
"aws:SourceArn": "arn:aws:lambda:us-east-1:111122223333:function:my-function"
}
}

Update the `Principal` block to reference the ARN of the Lambda function's IAM execution role in Account A:

"Principal": {
"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
}

Update the `Principal` block to trust Account A's root user, but change the policy's `Action` from `sts:AssumeRole` to `sts:AssumeRoleWithWebIdentity`:

"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRoleWithWebIdentity"

Change the `Principal` service to the DynamoDB service principal so that the table can receive requests directly from the role:

"Principal": {
"Service": "dynamodb.amazonaws.com"
}

Show answer & explanation

Answer: Update the `Principal` block to reference the ARN of the Lambda function's IAM execution role in Account A:

"Principal": {
"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
}

Answer

Update the Principal block of the target role's trust policy in Account B to trust the Lambda execution role's ARN in Account A.

The correct option is correct because when Lambda code runs, the AWS SDK client initiates API calls signed with the function's execution role credentials. To assume the cross-account role, the trust policy in Account B must specify the caller's IAM execution role ARN (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) as the principal in the trust relationship statement.

Step-by-Step Solution

Analyze the IAM configuration and identify the entity calling the `AssumeRole` API.

The Lambda function uses its execution role (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) to sign and execute AWS API requests, including `sts:AssumeRole`.

When a function runs, it uses the temporary credentials of its execution role to authorize all actions.

Inspect the trust policy of the target role `CrossAccountDynamoDBRole` in Account B.

The current trust policy only allows the service principal `lambda.amazonaws.com` to assume the role.

This configuration is for allowing the Lambda service to assume an execution role, not for allowing an assumed role to call another role.

Update the trust policy of the target role to authorize the correct principal.

The principal is changed to `"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"`.

This establishes a cross-account trust relationship allowing the execution role in Account A to assume the role in Account B.

Key Concept

Cross-Account IAM Roles and Service vs. AWS Principals

Question 43Question →

A developer is setting up an application on an on-premises server that must archive daily transaction logs to a private Amazon S3 bucket. To implement this securely without storing long-term credentials on the server, the developer creates an IAM User named `archive-agent` in the AWS account `111122223333` and an IAM Role named `S3UploaderRole` that has permissions to write to the S3 bucket. The application will authenticate as `archive-agent` using short-term configurations and then assume `S3UploaderRole` to perform the S3 uploads.

Which two configuration policies are required to establish this role-assumption trust relationship and grant the necessary permissions? (Select two.)

Select all that apply

A trust policy attached to S3UploaderRole that allows the archive-agent user to assume the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "sts:AssumeRole"
}
]
}

A permissions policy attached to the archive-agent user that permits calling sts:AssumeRole on the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/S3UploaderRole"
}
]
}

A trust policy attached to S3UploaderRole containing S3 permissions directly:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::company-logs-bucket/*"
}
]
}

A permissions policy attached to S3UploaderRole that references the user as a resource:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:user/archive-agent"
}
]
}

A local credentials file containing static credentials for the AWS Account Root User to bypass role assumption:

{
"aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
"aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

Show answer & explanation

Answer: A trust policy attached to S3UploaderRole that allows the archive-agent user to assume the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "sts:AssumeRole"
}
]
}
; A permissions policy attached to the archive-agent user that permits calling sts:AssumeRole on the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/S3UploaderRole"
}
]
}

Answer

To establish the trust relationship and grant permissions, the developer must attach a trust policy to the S3UploaderRole that lists the archive-agent user as the trusted principal allowed to perform the sts:AssumeRole action, and attach an IAM permissions policy to the archive-agent user that permits calling sts:AssumeRole on the role's Amazon Resource Name (ARN).

Role assumption is a two-way handshake. The trust policy attached to the S3UploaderRole must declare the archive-agent IAM User as a trusted principal that is permitted to execute the sts:AssumeRole action. Simultaneously, the archive-agent user must possess a permissions policy that explicitly permits it to perform the sts:AssumeRole action against the target role's ARN. This combination ensures that the user is authorized to request the role and the role is authorized to trust the user.

Step-by-Step Solution

Configure the trust policy on the destination IAM Role.

The target role (S3UploaderRole) allows sts:AssumeRole requests originating from the archive-agent IAM User principal.

An IAM Role's trust policy establishes which trusted identities (principals) are authorized to assume it.

Configure the permissions policy on the source IAM User.

The archive-agent user has explicit permission to call sts:AssumeRole on the ARN of the S3UploaderRole.

By default, IAM users do not have permissions to call STS AssumeRole; this must be explicitly granted in their permissions policy.

Key Concept

Role assumption requires permissions configured on both sides: a trust policy on the role defining who can assume it, and an identity permissions policy on the user permitting the assume role action.

Question 44Question →

A developer is deploying a microservices application to AWS App Runner. The application needs to retrieve two configuration settings:

1. Database credentials for an Amazon Aurora PostgreSQL database that must be rotated automatically every 30 days.
2. A public API endpoint URL for an external service that is non-sensitive and frequently accessed.

Which combination of actions should the developer perform to manage and retrieve these configurations securely and cost-effectively? (Select TWO.)

Select all that apply

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString parameter and enable native scheduled rotation.

Store the external service endpoint URL in AWS Secrets Manager to keep all external references in a single service.

Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in AWS Lambda rotation function.

Store the external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Embed the database credentials directly in the application code as environment variables within the Dockerfile.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in AWS Lambda rotation function.; Store the external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Answer

The developer should store the database credentials in AWS Secrets Manager and configure automatic rotation, and store the non-sensitive external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

AWS Secrets Manager is designed for storing database credentials securely and provides native support for RDS/Aurora automatic rotation via Lambda. AWS Systems Manager Parameter Store is the most cost-effective storage for non-sensitive configuration data like API endpoints, as standard parameters are free.

Step-by-Step Solution

Determine the appropriate storage service for the database credentials.

Identify AWS Secrets Manager as the best choice because it offers native integration with Amazon Aurora and built-in automatic credential rotation.

AWS Secrets Manager is specifically built for secrets requiring lifecycle management and rotation, reducing custom scripting effort.

Determine the appropriate storage service for the public API endpoint URL.

Identify AWS Systems Manager Parameter Store as the correct choice since the configuration is non-sensitive and does not require rotation.

Parameter Store standard parameters are free and ideal for non-sensitive application settings, optimizing costs.

Key Concept

Selecting between AWS Secrets Manager and Systems Manager Parameter Store based on security features (like automatic rotation) and cost-efficiency.

Question 45Question →

A developer is implementing a backend service integration for automated partner applications. The partner applications must programmatically upload raw telemetry data directly to an Amazon S3 bucket. The partners authenticate using their own enterprise OpenID Connect (OIDC) identity provider. The developer must ensure that these external applications obtain temporary AWS credentials with permission to write only to a specific folder in the S3 bucket without requiring long-lived IAM user credentials. Which TWO configuration steps should the developer perform to meet these requirements?

Select all that apply

Create and configure an Amazon Cognito identity pool, specifying the partner's OIDC provider as an authentication provider.

Associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the Cognito identity pool.

Create an Amazon Cognito user pool, register the OIDC provider, and use user pool groups to grant direct access to the S3 bucket.

Implement an Amazon API Gateway Lambda authorizer that generates temporary IAM credentials using AWS STS and returns them in the context object.

Generate long-lived IAM access keys for a partner service account and configure the partner applications to use these keys in their SDK calls.

Show answer & explanation

Answer: Create and configure an Amazon Cognito identity pool, specifying the partner's OIDC provider as an authentication provider.; Associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the Cognito identity pool.

Answer

Create and configure an Amazon Cognito identity pool with the external OIDC provider as an authentication provider, and associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the identity pool.

To access AWS resources directly from an external identity provider (such as an OIDC provider), Amazon Cognito identity pools are used to vend temporary AWS credentials. The client first authenticates with the OIDC provider, passes the token to the identity pool, and receives temporary AWS credentials mapped to an IAM role. This role must have a trust policy allowing the identity pool to assume it and an IAM policy with the necessary S3 folder permissions.

Step-by-Step Solution

Select Cognito Identity Pools instead of User Pools for AWS resource authorization.

Allows external users to exchange credentials.

Identity pools are designed specifically to vend temporary AWS credentials for direct resource access.

Configure the OIDC provider in the identity pool authentication settings.

Enables trust relationship between external OIDC token and AWS STS.

Allows AWS Cognito to validate identity tokens presented by the partner applications.

Define an IAM policy with targeted S3 write access and bind it to the IAM role mapped for authenticated users.

Enforces least-privilege folder-level access for the partner applications.

Ensures that the vended temporary credentials only permit uploading to the designated S3 folder.

Key Concept

Amazon Cognito Identity Pools (Federated Identities) for vending temporary AWS credentials to external OIDC-authenticated users.

Estimated Time:2m 0s

Question 46Question →

A developer is implementing a mobile e-commerce application. The application requires a secure user sign-up and sign-in system. Once authenticated, the application must make secure REST API requests to an Amazon API Gateway backend to fetch order history. The developer wants to use a managed user directory and ensure that API Gateway automatically validates the JSON Web Tokens (JWT) sent in the request header without maintaining custom authentication code or custom backend validation logic.

Which setup meets these requirements with the lowest operational complexity?

Use an Amazon Cognito User Pool to handle user registration and sign-in. Configure a Cognito User Pool Authorizer on the API Gateway REST API method to validate the ID or access token sent by the mobile application.

Use an Amazon Cognito Identity Pool to handle user registration and sign-in. Configure a Cognito Authorizer on the API Gateway REST API method to validate the identity pool tokens directly.

Use an Amazon Cognito User Pool to handle user registration and sign-in. Create a custom API Gateway Lambda authorizer that retrieves the public JSON Web Key Set (JWKS) from Cognito to verify the signature and validity of the incoming JWT for each request.

Store the user accounts in a backend database. Hardcode an IAM user's AWS access key and secret key within the mobile application's source code, using the AWS SDK to sign each HTTP request before sending it to the API Gateway.

Show answer & explanation

Answer: Use an Amazon Cognito User Pool to handle user registration and sign-in. Configure a Cognito User Pool Authorizer on the API Gateway REST API method to validate the ID or access token sent by the mobile application.

Answer

The correct option is to use an Amazon Cognito User Pool to manage sign-in and sign-up, and configure a Cognito User Pool Authorizer on API Gateway. Cognito User Pools natively handle the user directory and issue JWTs (ID/access tokens) upon authentication. API Gateway's built-in Cognito Authorizer directly validates these JWTs without requiring custom Lambda code, which reduces development effort and operational overhead.

Step-by-Step Solution

Determine the service needed for user directory management, registration, and sign-in.

Identify Amazon Cognito User Pools as the service that manages user directories and issues JSON Web Tokens (JWTs) upon successful authentication.

Cognito User Pools serve as the identity provider (IdP) for user management, whereas Identity Pools are used for exchanging tokens for AWS credentials.

Evaluate the method for securing the API Gateway REST API using these Cognito tokens without writing custom validation code.

Select the built-in Cognito User Pool Authorizer in API Gateway.

The Cognito User Pool Authorizer natively integrates with API Gateway, extracting and validating the JWT from the request headers automatically, thus eliminating the need for a custom Lambda authorizer.

Key Concept

Amazon Cognito User Pools provide authentication and token issuance, which can be natively validated at API Gateway using a built-in Cognito User Pool Authorizer to secure API endpoints with minimal operational overhead.

Question 47Question →

A developer is implementing an AWS Lambda function in AWS Account $111111111111$ (Account A) that must write messages to an Amazon SQS queue in AWS Account $222222222222$ (Account B). The security team requires using temporary security credentials via IAM role assumption for cross-account access. The Lambda function is configured with an execution role named `LambdaExecutionRole` in Account A.

The developer attempts to set up an IAM role in Account B named `QueueWriterRole` with the following trust policy:

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

Which of the following actions are required to successfully and securely establish this cross-account access? (Select TWO.)

Select all that apply

Modify the trust policy of `QueueWriterRole` in Account B to replace `lambda.amazonaws.com` with `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"` in the `Principal` element.

Attach an identity-based policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on the Amazon Resource Name (ARN) of `QueueWriterRole` in Account B.

Modify the trust policy of `QueueWriterRole` in Account B to replace the `Action` value of `"sts:AssumeRole"` with `"sqs:SendMessage"`.

Attach a resource policy to the Amazon SQS queue in Account B that allows the service principal `lambda.amazonaws.com` to perform the `sts:AssumeRole` action.

Store the long-term Access Key ID and Secret Access Key of an IAM user from Account B in the Lambda environment variables, and use them to initialize the Amazon SQS client in the function code.

Show answer & explanation

Answer: Modify the trust policy of `QueueWriterRole` in Account B to replace `lambda.amazonaws.com` with `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"` in the `Principal` element.; Attach an identity-based policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on the Amazon Resource Name (ARN) of `QueueWriterRole` in Account B.

Answer

To establish cross-account access securely, the trust policy of the IAM role in the destination account must be updated to trust the source role's ARN, and the execution role in the source account must have an identity-based policy allowing it to perform the assume role action on the destination role.

Cross-account delegation requires configuration on both sides. First, the destination role's trust policy in Account B must define who is trusted to assume it. This is done by modifying the principal element to target the specific execution role ARN of the Lambda function. Second, the execution role in Account A must be granted permission to perform the `sts:AssumeRole` action on the destination role's ARN.

Step-by-Step Solution

Inspect the initial trust policy on the role in the destination account (Account B) and identify the principal misconfiguration.

The current trust policy uses the service principal `lambda.amazonaws.com`. This configuration only allows the AWS Lambda service within the same account to assume the role directly, not a specific role from a different AWS account.

Correcting the trust relationship is necessary because cross-account trust requires specifying the specific AWS account or IAM principal in the trust policy.

Modify the trust policy of the target role in Account B to trust the specific IAM role in Account A.

The `Principal` element is changed to `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"`.

This establishes that the role in Account B trusts the execution role of the Lambda function in Account A.

Grant the execution role in Account A the permission to perform `sts:AssumeRole` on the target role in Account B.

An identity-based policy with the `sts:AssumeRole` action and the target role's ARN as the resource is attached to `LambdaExecutionRole` in Account A.

Even if the target role trusts the source role, the source role must explicitly be granted permission to perform the assume-role operation.

Key Concept

Cross-account IAM role delegation requires two-way permission configuration: a trust policy on the target role trusting the source principal, and an identity-based permission policy on the source principal allowing the assume-role action.

Question 48Question →

A developer is building a mobile application that allows users to upload high-resolution photos directly to a private Amazon S3 bucket. The application must authenticate users using an enterprise OpenID Connect (OIDC) identity provider. The developer wants to use Amazon Cognito to facilitate authorization, ensuring that users can only upload files to their own prefix (folder) within the S3 bucket using temporary, least-privilege credentials, without exposing any long-lived credentials. Which TWO configuration steps should the developer perform to meet these requirements?

Select all that apply

Configure an Amazon Cognito Identity Pool and add the OIDC identity provider as an authentication provider in the Identity Pool settings.

Create an IAM role for authenticated users with a trust policy for cognito-identity.amazonaws.com and a permissions policy that utilizes the cognito-identity.amazonaws.com:sub policy variable to grant s3:PutObject access to user-specific prefixes.

Create an Amazon Cognito User Pool, register the enterprise OIDC provider as an identity provider, and configure the S3 bucket policy to authorize write operations using the Cognito User Pool's ID token.

Implement an API Gateway custom Lambda authorizer that validates the user's OIDC ID token and returns an IAM policy containing s3:PutObject permissions directly to the client application.

Create an Amazon Cognito User Pool client, map the OIDC provider attributes, and configure the mobile app to call the Cognito User Pool token endpoint to retrieve temporary AWS credentials.

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool and add the OIDC identity provider as an authentication provider in the Identity Pool settings.; Create an IAM role for authenticated users with a trust policy for cognito-identity.amazonaws.com and a permissions policy that utilizes the cognito-identity.amazonaws.com:sub policy variable to grant s3:PutObject access to user-specific prefixes.

Answer

To meet the requirements, the developer must configure an Amazon Cognito Identity Pool with the OIDC provider as an authentication provider, and associate an authenticated IAM role that utilizes the cognito-identity.amazonaws.com:sub policy variable to restrict S3 bucket upload access to the user's specific prefix.

To upload files directly to Amazon S3, a client requires temporary AWS credentials. Amazon Cognito Identity Pools (federated identities) enable this by allowing users to federate with external identity providers (such as an OIDC provider) and obtain temporary AWS credentials. Access to S3 can be scoped to user-specific folders by using the authenticated IAM role associated with the Identity Pool. By incorporating the cognito-identity.amazonaws.com:sub policy variable into the resource block of the IAM role's permission policy, the policy dynamically evaluates to the authenticated user's unique identity ID, thereby enforcing that users can only upload objects to their own folder prefix.

Step-by-Step Solution

Set up federation between the OIDC provider and AWS.

Configure an Amazon Cognito Identity Pool and register the OIDC provider within its settings.

This allows users authenticated via the enterprise OIDC provider to exchange their OIDC token for temporary AWS credentials using Cognito.

Define authorization permissions using an IAM role.

Create an authenticated IAM role with a trust relationship pointing to cognito-identity.amazonaws.com.

Cognito Identity Pools require an IAM role that defines the permissions granted to authenticated users. The trust policy permits Cognito to assume this role on behalf of the federated user.

Implement prefix-level isolation in the IAM permissions policy.

Reference the cognito-identity.amazonaws.com:sub policy variable in the S3 bucket resource ARN (e.g., arn:aws:s3:::my-bucket/${cognito-identity.amazonaws.com:sub}/*).

This dynamically limits each user's S3 put operations to their unique Cognito identity ID, ensuring proper isolation and data security.

Key Concept

Federation using Cognito Identity Pools and access control using Cognito policy variables

Question 49Question →

A retail company has developed a mobile application where users authenticate using Amazon Cognito User Pools. The backend services are exposed through an Amazon API Gateway REST API. The company needs to restrict API access so that only authenticated users with a valid JSON Web Token (JWT) can invoke the API methods. The developer wants to implement this validation with the lowest development effort and without writing any custom authorization code. Which configuration should the developer choose to secure the API?

Configure a built-in API Gateway Cognito authorizer that directly validates the incoming user pool tokens.

Create a custom Lambda authorizer that decodes, verifies, and validates the Cognito JSON Web Token (JWT) on every request.

Set up an Amazon Cognito Identity Pool to exchange user tokens for temporary AWS credentials and secure the API using IAM authorization.

Enable a Lambda proxy integration and perform token decoding and validation manually inside the backend Lambda function.

Show answer & explanation

Answer: Configure a built-in API Gateway Cognito authorizer that directly validates the incoming user pool tokens.

Answer

Configure a built-in API Gateway Cognito authorizer that directly validates the incoming user pool tokens.

Configuring a built-in API Gateway Cognito authorizer is the most operationally efficient solution. It natively integrates API Gateway with Amazon Cognito User Pools, allowing API Gateway to automatically validate the incoming JWT signature, expiration, and client ID. This requires zero custom code and incurs no additional Lambda execution costs for authorization.

Step-by-Step Solution

Analyze the requirement to secure an Amazon API Gateway REST API using tokens from Amazon Cognito User Pools.

Identify that the solution must validate Cognito JSON Web Tokens (JWTs).

Cognito User Pools issue JWTs upon successful user authentication.

Determine the approach that requires the lowest development effort and zero custom authorization code.

Select the built-in API Gateway Cognito authorizer.

The Cognito authorizer is a native, code-free integration within API Gateway that automatically validates JWT signature, expiration, and audience.

Key Concept

API Gateway Cognito User Pool Authorizer

Question 50Question →

A developer is configuring an AWS Lambda function inside a private subnet of a VPC. The Lambda function needs to read messages from an Amazon SQS queue and write records to an Amazon ElastiCache for Redis cluster located in another private subnet within the same VPC. The Lambda function is successfully writing to ElastiCache but is unable to connect to the Amazon SQS service. Which configuration change should the developer make to resolve this connectivity issue in the most secure manner?

Modify the IAM trust policy of the Lambda function's execution role to include the Amazon SQS service principal (sqs.amazonaws.com) as a trusted entity.

Move the Lambda function to a public subnet within the VPC to allow it to communicate directly with the public Amazon SQS endpoints.

Create an interface VPC endpoint for Amazon SQS in the VPC, and update the security groups to allow traffic between the Lambda function and the endpoint.

Store the SQS queue URL in AWS Secrets Manager, and configure the Lambda function to retrieve it using the Secrets Manager API to bypass the network route.

Show answer & explanation

Answer: Create an interface VPC endpoint for Amazon SQS in the VPC, and update the security groups to allow traffic between the Lambda function and the endpoint.

Answer

Create an interface VPC endpoint for Amazon SQS in the VPC, and update the security groups to allow traffic between the Lambda function and the endpoint.

Creating an interface VPC endpoint (powered by AWS PrivateLink) for Amazon SQS allows resources in private subnets to communicate privately with the service without traversing the public internet or needing a NAT Gateway. Since the Lambda function is in a private subnet, it can route SQS traffic through this private endpoint.

Step-by-Step Solution

Identify the destination endpoint requirements.

Amazon SQS is a public AWS service, which means a resource inside a private subnet without internet access cannot reach it directly.

The Lambda function needs a path to reach the public SQS API, which can be accomplished either via public internet routing (NAT Gateway) or a private path (VPC endpoint).

Select the most secure connectivity method that does not expose the traffic to the public internet.

An Interface VPC Endpoint for SQS (com.amazonaws.region.sqs) provides private, secure connectivity.

VPC endpoints use AWS PrivateLink to keep traffic within the AWS network, satisfying the security requirement.

Update security groups and routing to allow traffic.

Ensure the Lambda function's security group allows outbound traffic to the VPC endpoint, and the endpoint's security group allows inbound HTTPS traffic from the Lambda function.

Security groups are stateful and must explicitly allow the connection from the client to the endpoint.

Key Concept

Establishing private connectivity to public AWS services from within a VPC using Interface VPC Endpoints (AWS PrivateLink).

Estimated Time:1m 30s

Question 51Question →

A developer is designing a REST API using Amazon API Gateway. The API must support two distinct clients: a mobile application where users authenticate and receive JSON Web Tokens (JWTs) from Amazon Cognito, and a legacy third-party application that sends custom tokens that must be validated against an external database.

Which two authorization mechanisms should the developer configure on API Gateway to secure these client requests? (Select TWO.)

Select all that apply

Configure a Cognito User Pools authorizer to validate the JWTs sent by the mobile application.

Configure a custom Lambda authorizer to parse and validate the legacy client application tokens.

Configure a Cognito Identity Pools authorizer to validate the JWTs sent by the mobile application.

Configure a custom Lambda authorizer to decode and validate the Cognito User Pool ID tokens.

Configure a Lambda proxy integration to validate the custom legacy client tokens within the backend integration.

Show answer & explanation

Answer: Configure a Cognito User Pools authorizer to validate the JWTs sent by the mobile application.; Configure a custom Lambda authorizer to parse and validate the legacy client application tokens.

Answer

Configure a Cognito User Pools authorizer to validate the JWTs sent by the mobile application, and configure a custom Lambda authorizer to parse and validate the legacy client application tokens.

To secure the API requests, a native Cognito User Pools authorizer should be used for the mobile application since API Gateway natively decodes and validates Cognito JWTs. For the legacy client application, a custom Lambda authorizer is required to extract the token and perform custom validation logic against the external database.

Step-by-Step Solution

Determine the auth mechanism for the Cognito-authenticated mobile app.

Identify that the Cognito User Pools authorizer is a native, built-in feature of API Gateway designed to validate Cognito user pool tokens without extra code.

Reduces implementation overhead, avoids Lambda execution costs for auth, and complies with best practices.

Determine the auth mechanism for the legacy partner client using custom tokens.

Identify that a custom Lambda authorizer (token-based or request-based) is necessary to run the custom validation logic against the external database.

API Gateway does not natively support external database lookups for auth, making a Lambda authorizer the proper extension point.

Key Concept

Selecting native Cognito User Pools authorizers for Cognito JWTs and custom Lambda authorizers for custom token structures and external database lookups.

Question 52Question →

A developer is configuring an AWS Lambda function to retrieve messages from an Amazon SQS queue. To follow the security principle of least privilege, the developer decides to create a custom IAM role for the Lambda function. Which of the following configurations are required to establish this access? (Select TWO.)

Select all that apply

An IAM permissions policy attached to the IAM role that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the specific SQS queue ARN.

An IAM trust policy on the IAM role that allows the `lambda.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

Hardcoded AWS access keys and secret access keys stored in the Lambda function's environment variables to authenticate SDK client requests.

An IAM trust policy attached directly to the Lambda function resource that allows the SQS service principal to perform the `sts:AssumeRole` action.

A trust policy attached directly to the SQS queue that allows the queue to assume the Lambda function's execution role.

Show answer & explanation

Answer: An IAM permissions policy attached to the IAM role that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the specific SQS queue ARN.; An IAM trust policy on the IAM role that allows the `lambda.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

Answer

The configurations required are: an IAM permissions policy attached to the IAM role that allows SQS actions on the queue ARN, and an IAM trust policy on the IAM role that allows the Lambda service principal to assume the role.

The correct options specify the two key components of an IAM execution role. First, the trust policy (trust relationship) is configured on the IAM role to allow the AWS Lambda service principal (lambda.amazonaws.com) to assume the role. Second, a permissions policy is attached to the IAM role to grant the permissions necessary for the function's code to run, which in this case includes actions such as reading and deleting messages from the specific SQS queue resource.

Step-by-Step Solution

Configure the trust relationship on the IAM role.

The trust policy allows the AWS Lambda service principal (lambda.amazonaws.com) to assume the role using the sts:AssumeRole action.

This enables the Lambda service to obtain temporary security credentials when executing the function.

Configure the permissions policy on the IAM role.

The identity-based permissions policy grants the role specific access to the SQS queue resource using actions like sqs:ReceiveMessage.

This enforces the principle of least privilege, ensuring the Lambda function can only perform authorized operations on designated resources.

Key Concept

IAM Roles, Permissions Policies, and Trust Policies

Estimated Time:1m 30s

Question 53Question →

A developer is designing a serverless document management system where users upload sensitive documents of approximately $500\text{ KB}$ each. The application must perform client-side envelope encryption on these documents before uploading them to an Amazon S3 bucket. The developer wants to use an AWS KMS customer managed key for this process.

Which of the following actions must the developer perform to encrypt the documents and prepare them for storage? (Select TWO.)

Select all that apply

Call the KMS `GenerateDataKey` API with the customer managed key to retrieve a plaintext data key and a ciphertext data key.

Encrypt the document locally using the plaintext data key, upload the encrypted document and the ciphertext data key to Amazon S3, and delete the plaintext data key from memory.

Call the KMS `Encrypt` API directly to encrypt the document payload, as customer managed keys support direct payload encryption up to

5\text{ MB}

Call the KMS `GenerateDataKeyWithoutPlaintext` API to retrieve the ciphertext data key, and use it to encrypt the document locally before uploading it to Amazon S3.

Store the encrypted document in Amazon S3, and save the plaintext data key in AWS Systems Manager Parameter Store with secure string parameters for future decryption.

Show answer & explanation

Answer: Call the KMS `GenerateDataKey` API with the customer managed key to retrieve a plaintext data key and a ciphertext data key.; Encrypt the document locally using the plaintext data key, upload the encrypted document and the ciphertext data key to Amazon S3, and delete the plaintext data key from memory.

Answer

To perform client-side envelope encryption, the developer must call the KMS GenerateDataKey API to obtain both the plaintext and ciphertext data keys. The document is encrypted locally using the plaintext data key, and both the encrypted document and ciphertext data key are stored in S3, while the plaintext data key is discarded from memory.

To implement client-side envelope encryption, the developer needs to generate a unique data key using the customer managed key. The KMS GenerateDataKey API returns both the plaintext data key (for immediate encryption) and the ciphertext data key (for storage). The document is encrypted locally using the plaintext key. After encryption, the encrypted document and ciphertext data key are uploaded to S3, and the plaintext data key is discarded from memory to prevent unauthorized access.

Step-by-Step Solution

Generate a data key from AWS KMS.

A plaintext data key and a ciphertext data key are obtained using the GenerateDataKey API and the customer managed key.

The plaintext data key is needed for local encryption, and the ciphertext data key is needed to decrypt the document later.

Perform local client-side encryption.

The document payload is encrypted using the plaintext data key.

Local encryption keeps the plaintext data secure before it is transmitted to S3.

Store the encrypted artifacts and clean up memory.

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

Storing the ciphertext data key alongside the document ensures it can be decrypted later by calling KMS Decrypt, while discarding the plaintext key minimizes exposure risk.

Key Concept

AWS KMS Envelope Encryption Workflow

Question 54Question →

A developer needs to encrypt database backup files, each approximately $45\text{ MB}$ in size, before uploading them to an Amazon S3 bucket. The security policy requires client-side encryption using a customer managed key in AWS KMS. Which of the following actions must the developer perform to implement client-side envelope encryption for these files? (Select TWO.)

Select all that apply

Call the GenerateDataKey API operation, passing the KMS key identifier, to obtain a plaintext data key and an encrypted data key.

Encrypt the file locally using the plaintext data key, upload the encrypted file and the encrypted data key to Amazon S3, and then delete the plaintext data key from memory.

Call the Encrypt API operation directly, passing the KMS key identifier and the entire

45\text{ MB}

file payload.

Call the GenerateDataKeyWithoutPlaintext API operation to obtain the data key for local encryption of the backup files.

Configure AWS Systems Manager Parameter Store to automatically rotate the database credentials and generate a database backup key.

Show answer & explanation

Answer: Call the GenerateDataKey API operation, passing the KMS key identifier, to obtain a plaintext data key and an encrypted data key.; Encrypt the file locally using the plaintext data key, upload the encrypted file and the encrypted data key to Amazon S3, and then delete the plaintext data key from memory.

Answer

Call the GenerateDataKey API operation to obtain both a plaintext data key and an encrypted data key, encrypt the file locally using the plaintext key, and then delete the plaintext key from memory.

The correct options outline the standard KMS envelope encryption workflow. A developer calls the GenerateDataKey API operation to get both the plaintext key and the encrypted key. The plaintext key is used to encrypt the large payload locally, and then it is immediately deleted from memory. The encrypted data key is stored with the encrypted data for future decryption.

Step-by-Step Solution

Generate a unique data key using AWS KMS.

Obtained a plaintext data key and an encrypted version of the data key.

The developer must call GenerateDataKey. KMS returns both the plaintext key to encrypt the large data locally and the encrypted key to store alongside the data.

Encrypt the file locally and clean up the memory.

The file is securely encrypted using a symmetric algorithm, and the plaintext data key is removed from memory.

To prevent unauthorized access, the plaintext key is deleted immediately after the encryption is complete, leaving only the encrypted data and the encrypted key.

Key Concept

Envelope encryption involves generating a unique data key to encrypt large data payloads locally, then storing the encrypted data key alongside the encrypted data while discarding the plaintext key from memory.

Question 55Question →

A developer is designing a containerized microservice that runs on Amazon ECS. The microservice must store sensitive customer data in an Amazon DynamoDB table. Due to compliance requirements, the data must be encrypted client-side before it is sent to DynamoDB. The developer wants to use envelope encryption with an AWS KMS customer managed key to minimize KMS API calls and encrypt the data efficiently. Which two API operations must the developer implement in the microservice code to manage the keys for this client-side encryption and decryption workflow? (Select TWO.)

Select all that apply

kms:GenerateDataKey

kms:Decrypt

kms:GenerateDataKeyWithoutPlaintext

kms:Encrypt

ssm:GetParameter

Show answer & explanation

Answer: kms:GenerateDataKey; kms:Decrypt

Answer

The correct answer consists of the operations kms:GenerateDataKey and kms:Decrypt.

The correct operations are kms:GenerateDataKey and kms:Decrypt. In envelope encryption, the application calls kms:GenerateDataKey to obtain a plaintext data key (to encrypt the payload locally) and a ciphertext data key (to store alongside the encrypted payload). To decrypt the data, the application calls kms:Decrypt with the ciphertext data key to retrieve the plaintext data key, which is then used to decrypt the payload locally.

Step-by-Step Solution

Analyze the requirement for client-side envelope encryption and decryption of DynamoDB items using a customer managed key.

Identify that the application needs to dynamically generate a unique symmetric data key for each item, encrypt the payload locally, store the encrypted key with the item, and retrieve the plaintext key for decryption later.

This establishes the workflow where the KMS customer managed key is only used to protect the data keys, not the database payloads directly.

Determine the API operation required for the encryption phase.

Identify kms:GenerateDataKey as the API call that provides the plaintext key for immediate local encryption and the ciphertext key for storage.

Using kms:GenerateDataKeyWithoutPlaintext would require an additional round-trip to decrypt the key, and kms:Encrypt violates envelope encryption by sending the payload itself to KMS.

Determine the API operation required for the decryption phase.

Identify kms:Decrypt as the API call used to decrypt the stored ciphertext data key back to its plaintext form.

The microservice retrieves the ciphertext key from the DynamoDB item and must call kms:Decrypt before it can decrypt the customer data locally.

Key Concept

Envelope encryption workflow with AWS KMS

Estimated Time:1m 30s

Question 56Question →

A developer is configuring an AWS CodeBuild project that runs integration tests. These tests require credentials to access an Amazon RDS PostgreSQL database. The database credentials must be rotated automatically every $30$ days. How should the developer store and retrieve these credentials to meet the requirements with the least operational overhead?

Store the credentials in AWS Systems Manager Parameter Store as a SecureString parameter, and configure a custom AWS Lambda function triggered by an Amazon EventBridge scheduled rule to handle rotation.

Store the credentials in AWS Secrets Manager, configure automatic rotation using the built-in AWS Lambda rotation template for Amazon RDS, and reference the secret in the CodeBuild project's buildspec file.

Store the credentials in AWS Systems Manager Parameter Store as a String parameter, and enable Parameter Store's native database rotation integration to update the credentials every

30

days.

Store the credentials as plaintext environment variables in the AWS CodeBuild project configuration, and run a custom CLI script during the pre_build phase to update the credentials.

Show answer & explanation

Answer: Store the credentials in AWS Secrets Manager, configure automatic rotation using the built-in AWS Lambda rotation template for Amazon RDS, and reference the secret in the CodeBuild project's buildspec file.

Answer

Storing the credentials in AWS Secrets Manager is the correct approach. Secrets Manager provides native integration with Amazon RDS, allowing automatic credential rotation using built-in Lambda templates without writing custom code. CodeBuild can securely fetch these credentials dynamically during the build run by referencing them in the buildspec file.

Step-by-Step Solution

Evaluate the requirement for automatic rotation of database credentials every

30

days.

Identify that AWS Secrets Manager provides native, out-of-the-box support for rotating Amazon RDS credentials using built-in AWS Lambda templates.

Using native features minimizes custom code and operational overhead compared to manual or custom-coded solutions.

Compare Secrets Manager and Systems Manager Parameter Store for credential rotation.

Acknowledge that Parameter Store (even with SecureString parameters) lacks built-in automatic rotation templates for RDS, requiring custom Lambda functions and EventBridge rules.

This step eliminates options proposing Parameter Store due to the higher operational overhead requirement.

Integrate the secret retrieval into the AWS CodeBuild pipeline.

Reference the secret using Secrets Manager syntax in the buildspec file of the CodeBuild project.

This ensures the build environment retrieves the latest rotated credentials securely at runtime without exposing them in configuration logs or plaintext variables.

Key Concept

AWS Secrets Manager built-in rotation vs Systems Manager Parameter Store capabilities

Question 57Question →

A developer is configuring a machine learning pipeline in Amazon SageMaker. The pipeline needs to retrieve a personal access token (PAT) to pull training code from a private Git repository. This PAT must be rotated monthly and accessed by pipelines running across multiple AWS accounts in the same organization. Additionally, the pipeline needs to retrieve non-sensitive training hyperparameters (such as learning rate and batch size) that are only used within the local AWS account. How should the developer store these values to meet the requirements securely and cost-effectively?

Store the private Git repository token in AWS Secrets Manager and attach a resource-based policy to the secret to allow cross-account access. Store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Store the private Git repository token as a SecureString parameter in AWS Systems Manager Parameter Store and attach a resource-based policy to the parameter to allow cross-account access. Store the hyperparameters in AWS Secrets Manager.

Hardcode the private Git repository token directly in the SageMaker pipeline's script, and store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Store both the private Git repository token and the hyperparameters in AWS Secrets Manager, enabling automatic rotation for both to centralize secret management.

Show answer & explanation

Answer: Store the private Git repository token in AWS Secrets Manager and attach a resource-based policy to the secret to allow cross-account access. Store the hyperparameters as String parameters in AWS Systems Manager Parameter Store.

Answer

The correct answer correctly identifies that AWS Secrets Manager should be used for the private Git repository token because it natively supports resource-based policies for cross-account sharing and automatic rotation. It also correctly identifies that Systems Manager Parameter Store is the most cost-effective service for storing non-sensitive hyperparameters, avoiding unnecessary Secrets Manager costs.

Step-by-Step Solution

Analyze the requirements for the private Git repository token.

Identify that the token is sensitive, needs automatic monthly rotation, and requires cross-account access.

This determines the best security service to use based on features like resource-based policies and rotation.

Analyze the requirements for the hyperparameters.

Identify that the hyperparameters are non-sensitive configuration data, do not require rotation, and are only accessed locally.

This helps select the most cost-effective storage option for non-sensitive configurations.

Compare AWS Secrets Manager and Systems Manager Parameter Store features and cost.

AWS Secrets Manager is selected for the token because it supports resource-based policies for cross-account access and automatic rotation. Systems Manager Parameter Store is selected for the hyperparameters because standard parameters are free and suitable for non-sensitive data.

Ensures the solution is both secure and optimized for cost.

Key Concept

Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on rotation, cross-account access, and cost-efficiency.

Estimated Time:1m 30s

Question 58Question →

A developer is configuring an AWS Lambda function in AWS Account A (111111111111) that needs to read objects from an Amazon S3 bucket in AWS Account B (222222222222) by assuming an IAM role named CrossAccountS3Reader in Account B. The Lambda function is assigned an execution role in Account A named LambdaExecutionRole. However, when the Lambda function attempts to assume the CrossAccountS3Reader role using AWS STS, the API call fails with an AccessDenied error. Which of the following configurations are required to resolve this issue? (Select TWO.)

Select all that apply

In Account A, attach an IAM policy to the LambdaExecutionRole that allows the sts:AssumeRole action on the ARN of the CrossAccountS3Reader role in Account B.

In Account B, update the trust policy of the CrossAccountS3Reader role to allow the ARN of the LambdaExecutionRole from Account A to perform the sts:AssumeRole action.

In Account B, update the trust policy of the CrossAccountS3Reader role to specify lambda.amazonaws.com as the trusted service principal allowed to perform the sts:AssumeRole action.

In Account A, configure a resource-based policy on the Lambda function that allows Account B to call the lambda:InvokeFunction action.

In Account A, initialize the Amazon S3 client in the Lambda function by hardcoding temporary credentials generated from Account B.

Show answer & explanation

Answer: In Account A, attach an IAM policy to the LambdaExecutionRole that allows the sts:AssumeRole action on the ARN of the CrossAccountS3Reader role in Account B.; In Account B, update the trust policy of the CrossAccountS3Reader role to allow the ARN of the LambdaExecutionRole from Account A to perform the sts:AssumeRole action.

Answer

In Account A, attach an IAM policy to the LambdaExecutionRole that allows the sts:AssumeRole action on the ARN of the CrossAccountS3Reader role in Account B, and in Account B, update the trust policy of the CrossAccountS3Reader role to allow the ARN of the LambdaExecutionRole from Account A to perform the sts:AssumeRole action.

For cross-account role assumption using AWS STS, two configurations are required: first, the identity-based policy of the caller (the Lambda execution role in Account A) must grant permission to perform sts:AssumeRole on the target role; second, the trust policy of the target role in Account B must trust the caller's role ARN.

Step-by-Step Solution

Configure the calling principal's permissions in Account A.

Attached an identity-based IAM policy to the LambdaExecutionRole allowing sts:AssumeRole targeting the ARN of the CrossAccountS3Reader role.

The entity attempting to assume a role must have explicit permission to perform the assume-role operation.

Configure the target role's trust relationship in Account B.

Updated the CrossAccountS3Reader role's trust policy to include the LambdaExecutionRole ARN as a trusted principal.

The destination role must trust the specific calling identity from the external account to successfully complete the sts:AssumeRole API call.

Key Concept

Cross-account IAM role delegation using AWS STS

Question 59Question →

A developer is implementing a desktop gaming client that needs to authenticate users and allow them to upload gameplay screenshots directly to a private Amazon S3 bucket. The application must also communicate with a backend API hosted on Amazon API Gateway, where endpoints should only be accessible to authenticated users.

Which TWO actions must the developer take to implement this authentication and authorization design? (Select TWO.)

Select all that apply

Configure an Amazon Cognito User Pool to handle user registration and authentication, and use the Cognito Authorizer on the API Gateway endpoints.

Configure an Amazon Cognito Identity Pool using the User Pool as an identity provider to obtain temporary AWS credentials for S3 uploads.

Configure the Amazon Cognito User Pool to generate temporary AWS credentials with an attached IAM policy for the S3 bucket.

Deploy a custom Lambda Authorizer in API Gateway to decrypt, verify, and validate the signature of the User Pool tokens for basic endpoint security.

Hardcode a set of long-term IAM access keys within the desktop client to sign the S3 upload requests.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool to handle user registration and authentication, and use the Cognito Authorizer on the API Gateway endpoints.; Configure an Amazon Cognito Identity Pool using the User Pool as an identity provider to obtain temporary AWS credentials for S3 uploads.

Answer

To implement this architecture, configure an Amazon Cognito User Pool to handle user registration and authentication, and use the Cognito Authorizer on the API Gateway endpoints. Additionally, configure an Amazon Cognito Identity Pool using the User Pool as an identity provider to obtain temporary AWS credentials for S3 uploads.

To secure the backend API endpoints, the developer should configure an Amazon Cognito User Pool for user authentication and use the built-in API Gateway Cognito Authorizer, which natively validates JWTs without custom backend code. To enable direct uploads to Amazon S3 without exposing long-term credentials, the developer must configure an Amazon Cognito Identity Pool using the User Pool as an identity provider, which issues temporary AWS credentials with appropriate IAM permissions.

Step-by-Step Solution

Set up a Cognito User Pool to manage authentication.

Users can sign up, log in, and receive standard JSON Web Tokens (JWTs) representing their identity.

A User Pool acts as the primary identity provider for the application.

Integrate the User Pool with API Gateway.

API Gateway uses the Cognito User Pool Authorizer to inspect the Authorization header and validate the JWTs.

This secures the API endpoints with minimal operational overhead and zero custom code.

Set up a Cognito Identity Pool and link it to the User Pool.

The desktop client can exchange User Pool JWTs for temporary, short-lived AWS credentials via IAM roles defined in the Identity Pool.

This allows the client application to upload files directly to S3 securely without hardcoding long-term credentials.

Key Concept

Integration of Amazon Cognito User Pools for authentication and Identity Pools (Federated Identities) for authorizing access to AWS resources like S3.

Question 60Question →

A developer is deploying a Java application on Amazon EC2 instances in AWS account `123456789012`. The application requires access to retrieve database credentials from AWS Systems Manager Parameter Store. The developer creates an IAM role named `SSMParameterReaderRole` and attaches a permissions policy that allows the `ssm:GetParameter` action. The developer then configures an Amazon EC2 Instance Profile to associate the EC2 instances with this role. During startup, the application fails to retrieve the parameters, and CloudTrail logs show that the EC2 service was unable to assume the role.

The trust policy currently attached to `SSMParameterReaderRole` is as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "sts:AssumeRole"
}
]
}

Which modification must the developer make to the trust policy of `SSMParameterReaderRole` to resolve this issue?

Attach a permissions policy directly to the Amazon EC2 instances that grants the `sts:AssumeRole` permission for the IAM role.

Change the trust policy's Action field to specify the `ssm:GetParameter` API action instead of the `sts:AssumeRole` API action.

Update the trust policy's Principal block to specify the EC2 service principal (`"Service": "ec2.amazonaws.com"`) instead of the AWS account root principal.

Modify the application's SDK client configuration to hardcode the IAM role's temporary credentials directly in the code.

Show answer & explanation

Answer: Update the trust policy's Principal block to specify the EC2 service principal (`"Service": "ec2.amazonaws.com"`) instead of the AWS account root principal.

Answer

Update the trust policy's Principal block to specify the EC2 service principal (`"Service": "ec2.amazonaws.com"`) instead of the AWS account root principal.

The correct answer is to update the trust policy's Principal block to specify the EC2 service principal. When an application runs on an EC2 instance and uses an instance profile, the EC2 service must assume the associated IAM role on behalf of the instance. Therefore, the IAM role's trust policy must trust the service principal `ec2.amazonaws.com` rather than the AWS account root principal, which only allows IAM identities within the account to assume the role via direct STS calls.

Step-by-Step Solution

Analyze the CloudTrail error indicating that the Amazon EC2 service is unable to assume the IAM role.

Identified that the issue is with the trust relationship of the IAM role, which defines which principals are allowed to assume it.

To allow a service like EC2 to assume a role, the trust policy must explicitly grant permission to that service principal.

Examine the current trust policy of the IAM role.

Observed that the Principal is set to the AWS account root (`arn:aws:iam::123456789012:root`) rather than the service principal.

The current configuration only allows IAM users or roles within the account to assume this role via STS, not the EC2 service itself.

Update the Principal field in the trust policy to specify the EC2 service principal.

The Principal is modified to `"Service": "ec2.amazonaws.com"`.

This allows the EC2 service to successfully perform `sts:AssumeRole` on behalf of the instance, enabling the application to access AWS resources using the instance profile.

Key Concept

IAM Role Trust Policy vs Permissions Policy

Estimated Time:1m 30s

PreviousPage 3 / 20Next

Security

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept