Security

390 questions

All types390 Multiple choice195 Multiple select195

A developer is configuring a GitHub Actions workflow to deploy resources to an AWS account. To follow security best practices, the developer avoids using long-lived AWS credentials. Instead, they configure an OpenID Connect (OIDC) identity provider in IAM and create an IAM role named GitHubDeployRole to be assumed by the workflow.

The developer starts writing the following trust policy for the role, leaving two placeholders:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "________",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"________": "repo:my-organization/my-repo:ref:refs/heads/main"
}
}
}
]
}

Which two values must the developer use to replace the placeholders to establish this trust relationship securely? (Select TWO.)

Select all that apply

Set the Action element to sts:AssumeRoleWithWebIdentity

Set the second condition key to token.actions.githubusercontent.com:sub

Set the Action element to sts:AssumeRole

Set the second condition key to aws:PrincipalArn

Set the Action element to sts:AssumeRoleWithSAML

Show answer & explanation

Answer: Set the Action element to sts:AssumeRoleWithWebIdentity; Set the second condition key to token.actions.githubusercontent.com:sub

Answer

Setting the Action element to sts:AssumeRoleWithWebIdentity and setting the second condition key to token.actions.githubusercontent.com:sub.

To configure the OIDC trust relationship, the role must trust the OIDC provider and allow the action stating sts:AssumeRoleWithWebIdentity. To secure the trust relationship and prevent any GitHub workflow from assuming the role, the policy must use the condition key specifying token.actions.githubusercontent.com:sub to restrict access to only the specific organization, repository, and branch.

Step-by-Step Solution

Identify the authentication mechanism

OIDC federation via GitHub Actions

Since the pipeline uses OpenID Connect (OIDC) rather than SAML or standard AWS user credentials, we must use the STS action designed for web identity tokens.

Select the correct STS assume role action

sts:AssumeRoleWithWebIdentity

OIDC identity providers authenticate and request temporary security credentials using the AssumeRoleWithWebIdentity API call.

Identify the condition key to restrict repository scope

token.actions.githubusercontent.com:sub

To prevent unauthorized repositories from assuming the IAM role, the trust policy must assert a condition against the sub (subject) claim of the incoming token, which contains the repository organization, name, and branch reference.

Key Concept

IAM trust policies for OpenID Connect (OIDC) federation.

Question 362Question →

An engineering team is designing a client-side web application that integrates with an external OpenID Connect (OIDC) identity provider. Once authenticated, the web application must upload session logs directly to a specific folder within an Amazon S3 bucket (e.g., logs/{user_id}/). To minimize transfer latency and backend compute costs, the logs must be uploaded directly from the browser. Which architecture meets these requirements with the least operational overhead?

Create an IAM Role with a trust policy that allows the sts:AssumeRole action for the client application. Hardcode the IAM Role ARN in the client application, and have the client call AWS STS directly to assume the role using the OIDC token.

Configure an Amazon Cognito Identity Pool, register the OIDC provider as an authentication provider, and assign an authenticated IAM role. Use an IAM policy for this role that grants S3 write permissions to resources matching arn:aws:s3:::my-bucket/logs/${cognito-identity.amazonaws.com:sub}/*.

Configure an Amazon Cognito User Pool, register the OIDC provider as a federated Identity Provider (IdP), and configure a custom attribute to map the user ID to S3 folder access. Use the User Pool ID token directly to authenticate and authorize the client's S3 uploads.

Create an Amazon API Gateway REST API with a custom Lambda Authorizer. Have the authorizer validate the OIDC tokens, call AWS Security Token Service (STS) to generate temporary credentials, and return these credentials to the client to perform the S3 uploads.

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool, register the OIDC provider as an authentication provider, and assign an authenticated IAM role. Use an IAM policy for this role that grants S3 write permissions to resources matching arn:aws:s3:::my-bucket/logs/${cognito-identity.amazonaws.com:sub}/*.

Answer

Using an Amazon Cognito Identity Pool is the standard, least-overhead method to exchange external OIDC identity tokens for temporary, limited-privilege AWS credentials. The identity pool acts as the credential provider, mapping the OIDC token to an authenticated IAM role. By using the policy variable ${cognito-identity.amazonaws.com:sub}, you can dynamically restrict users to their specific folders within the S3 bucket without requiring custom backend code.

Step-by-Step Solution

Configure an Amazon Cognito Identity Pool and configure it to trust the external OIDC identity provider.

Enables the client-side application to present OIDC tokens to Cognito in exchange for a unique Cognito Identity ID.

Identity Pools are the service component responsible for federating identity providers to authorize AWS resource access.

Assign an authenticated IAM role to the Identity Pool, representing signed-in users.

Users who present valid OIDC tokens will automatically assume this role and receive temporary AWS credentials.

IAM roles define what permissions the authenticated identity has within the AWS environment.

Apply a policy to the IAM role that uses the dynamic variable ${cognito-identity.amazonaws.com:sub} in the S3 resource ARN.

Enforces fine-grained isolation, ensuring users can only write to their own folder within the S3 bucket.

This avoids hardcoding or managing individual folders manually, providing secure and automated resource isolation.

Key Concept

Amazon Cognito Identity Pools broker temporary AWS credentials for federated users, allowing direct and secure access to AWS resources like S3 using dynamic policy variables.

Estimated Time:1m 30s

Question 363Question →

A developer is deploying an application on an Amazon EC2 instance. The application is designed to read messages from an Amazon SQS queue named `orders-queue` and write the processed items to an Amazon DynamoDB table named `orders-table`. The developer wants to configure the necessary permissions by following security best practices and avoiding hardcoded credentials. Which two configurations are required to meet these requirements? (Select TWO.)

Select all that apply

Create an IAM role with a permissions policy that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the queue ARN, and the `dynamodb:PutItem` action on the table ARN.

Associate the IAM role with an IAM instance profile, and attach the instance profile to the EC2 instance.

Configure the IAM role's trust policy to trust `sqs.amazonaws.com` and `dynamodb.amazonaws.com` as the principal services.

Store AWS Access Key ID and Secret Access Key in a local application configuration file on the EC2 instance to initialize the SDK client.

Add a statement to the IAM role's trust policy that allows the IAM instance profile ARN to assume the role.

Show answer & explanation

Answer: Create an IAM role with a permissions policy that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the queue ARN, and the `dynamodb:PutItem` action on the table ARN.; Associate the IAM role with an IAM instance profile, and attach the instance profile to the EC2 instance.

Answer

Create an IAM role with a permissions policy that allows SQS and DynamoDB actions, and associate the IAM role with an IAM instance profile attached to the EC2 instance.

To grant the EC2 instance access to SQS and DynamoDB without hardcoding credentials, the developer must create an IAM role with a permissions policy allowing SQS and DynamoDB actions, and associate the role with an IAM instance profile attached to the EC2 instance. This allows the application to retrieve temporary credentials automatically via the instance metadata service.

Step-by-Step Solution

Define permissions in an IAM policy.

An IAM permissions policy is created that allows `sqs:ReceiveMessage` and `sqs:DeleteMessage` on the SQS queue, and `dynamodb:PutItem` on the DynamoDB table.

This grants the application the minimum permissions required to interact with SQS and DynamoDB.

Create an IAM role and configure its trust policy.

An IAM role is created with a trust policy that allows the Amazon EC2 service (`ec2.amazonaws.com`) to assume the role via `sts:AssumeRole`.

The EC2 service needs permission to assume the role on behalf of the application running on the instance.

Attach the role to the EC2 instance using an instance profile.

An IAM instance profile is created, the IAM role is added to it, and the instance profile is attached to the EC2 instance.

This allows the application code to automatically retrieve temporary security credentials from the EC2 instance metadata service.

Key Concept

To securely grant applications running on EC2 instances access to AWS resources, create an IAM role with the required permissions, configure its trust policy to trust the EC2 service, and associate the role with the instance using an IAM instance profile.

Question 364Question →

A developer is building a mobile health-tracking application. Users will log in using an external OpenID Connect (OIDC) compliant identity provider. After logging in, the mobile application must upload raw telemetry log files directly to a private Amazon S3 bucket, and invoke a private REST API hosted on Amazon API Gateway to fetch user profile data. Which TWO Amazon Cognito configurations are required to support this architecture?

Select all that apply

A Cognito User Pool federated with the OIDC identity provider to handle user authentication and issue identity and access tokens.

A Cognito Identity Pool configured to accept the OIDC-federated tokens and assume an IAM role for temporary AWS credentials to upload files to Amazon S3.

A Cognito User Pool group with an attached IAM role configured to directly authorize the client application to put objects into the S3 bucket.

An API Gateway Lambda Authorizer configured to validate the OIDC tokens and generate temporary AWS credentials for the S3 bucket access.

An API Gateway Cognito Authorizer configured to validate the OIDC tokens and return temporary AWS credentials to the mobile client.

Show answer & explanation

Answer: A Cognito User Pool federated with the OIDC identity provider to handle user authentication and issue identity and access tokens.; A Cognito Identity Pool configured to accept the OIDC-federated tokens and assume an IAM role for temporary AWS credentials to upload files to Amazon S3.

Answer

To support this architecture, the developer must configure a Cognito User Pool federated with the OIDC identity provider to handle user authentication, and a Cognito Identity Pool to exchange the OIDC tokens for temporary AWS credentials to write to the Amazon S3 bucket.

To authenticate users through an external OIDC identity provider and obtain user directory tokens (such as identity or access tokens), a Cognito User Pool must be configured with federation. To allow the mobile application to upload files directly to a private S3 bucket without routing through a server, a Cognito Identity Pool is required to exchange the OIDC-federated tokens for temporary, limited-privilege AWS credentials.

Step-by-Step Solution

Configure a Cognito User Pool with the OIDC identity provider as an external identity provider.

The User Pool validates OIDC authentication and issues identity, access, and refresh tokens to the mobile application.

A User Pool acts as the user directory and manages federation for user sign-in.

Configure a Cognito Identity Pool (Federated Identities) with the Cognito User Pool as an authentication provider.

The Identity Pool exchanges the OIDC-federated tokens for temporary, limited-privilege AWS credentials.

An Identity Pool is required to translate external identity tokens into IAM roles and temporary credentials for direct access to AWS resources like S3.

Key Concept

Distinction and integration between Amazon Cognito User Pools (authentication) and Cognito Identity Pools (authorization for AWS resources).

Question 365Question →

A developer is deploying a containerized application on Amazon ECS (Fargate). The application needs to read messages from an Amazon SQS queue and write items to an Amazon DynamoDB table. During deployment, the developer notices that the container starts up successfully but fails with an AccessDenied error when attempting to write to the DynamoDB table. Which of the following configurations will resolve this authorization issue while following the principle of least privilege?

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs-tasks.amazonaws.com service principal to assume the role.

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to the ECS Task Execution Role (executionRoleArn) so that the container agent can pass these permissions to the application at runtime.

Generate long-term IAM access keys with SQS and DynamoDB permissions, store them in the application's environment variables, and configure the application code to explicitly initialize the AWS SDK client with these credentials.

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs.amazonaws.com service principal to assume the role.

Show answer & explanation

Answer: Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs-tasks.amazonaws.com service principal to assume the role.

Answer

The correct configuration is to create an IAM role for the task itself (ECS Task Role) and attach the necessary application permissions (sqs:ReceiveMessage and dynamodb:PutItem). The trust policy of this IAM role must allow the 'ecs-tasks.amazonaws.com' service principal to assume the role. This permits the containerized application to automatically fetch temporary security credentials using the AWS SDK.

Step-by-Step Solution

Differentiate between the ECS Task Role and the ECS Task Execution Role.

Identify that permissions required by the application code itself (like DynamoDB and SQS access) must be granted via the Task Role (taskRoleArn), while permissions required by the ECS agent (like ECR image pulls) use the Task Execution Role.

This ensures the application container obtains the necessary credentials at runtime.

Configure the IAM role trust policy.

Verify that the trust relationship of the Task Role is configured to allow the service principal 'ecs-tasks.amazonaws.com' to call 'sts:AssumeRole'.

Without this trust relationship, ECS cannot assign the role to the running task, resulting in authorization errors.

Attach a least-privilege IAM policy to the Task Role.

Create and attach an IAM policy that allows only the required actions ('sqs:ReceiveMessage' and 'dynamodb:PutItem') on the specific SQS queue and DynamoDB table resources.

This fulfills the authorization requirement while adhering to the security principle of least privilege.

Key Concept

ECS Task Role vs. ECS Task Execution Role and IAM Trust Policies

Question 366Question →

A developer is implementing authentication and authorization for a mobile retail shopping application. The application needs to allow users to sign up and sign in, make authorized calls to a backend order processing API hosted on Amazon API Gateway, and upload scan logs directly to a private Amazon S3 bucket. Which architecture meets these requirements with the least operational overhead?

Configure a Cognito User Pool to handle user registration and login. Set up a Cognito Authorizer on Amazon API Gateway to validate the tokens generated by the User Pool. Configure a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS IAM credentials to authorize direct S3 uploads.

Configure a Cognito Identity Pool to manage user registration and authentication. Set up a custom Lambda Authorizer on Amazon API Gateway to validate the session state, and use Cognito User Pool groups to authorize direct S3 uploads.

Configure a Cognito User Pool to handle user registration and login. Create a custom API Gateway Lambda Authorizer that parses the user identity from the User Pool, generates temporary IAM credentials, and returns them to the client to authorize S3 uploads and API calls.

Configure a Cognito User Pool to handle user registration. Write a custom IAM trust policy on the Amazon S3 bucket that allows direct write access based on the User Pool client ID, and use an API Gateway resource policy to authenticate API requests.

Show answer & explanation

Answer: Configure a Cognito User Pool to handle user registration and login. Set up a Cognito Authorizer on Amazon API Gateway to validate the tokens generated by the User Pool. Configure a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS IAM credentials to authorize direct S3 uploads.

Answer

The correct solution leverages Cognito User Pools to authenticate users and generate JSON Web Tokens (JWTs). These tokens are verified directly by API Gateway using a built-in Cognito Authorizer, which requires no custom coding. To allow the mobile application to upload files directly to Amazon S3 without exposing static credentials or passing data through a backend, a Cognito Identity Pool is used to exchange the User Pool tokens for temporary, short-lived AWS IAM credentials.

Step-by-Step Solution

Select Amazon Cognito User Pools for authentication.

Enables user signup, signin, and directory management, producing JSON Web Tokens (JWTs) upon successful authentication.

User Pools are built specifically for identity management and authentication.

Configure API Gateway with a native Cognito Authorizer.

Enables API Gateway to validate User Pool tokens automatically without custom code or running a Lambda function.

Minimizes operational overhead and cost compared to custom Lambda authorizers.

Configure a Cognito Identity Pool (Federated Identities).

Allows authenticated User Pool users to exchange their tokens for temporary AWS credentials mapped to an IAM role with S3 write permissions.

Identity Pools are the standard AWS mechanism to authorize users for direct access to AWS resources like Amazon S3.

Key Concept

Cognito User Pools handle authentication (identity directory), while Cognito Identity Pools handle authorization (temporary AWS credentials for direct resource access). API Gateway Cognito Authorizers natively validate User Pool tokens.

Question 367Question →

A developer is building a client proofing portal for a photography studio. The portal must authenticate clients using email and password, allow them to upload selection feedback files directly to a secure Amazon S3 bucket, and access private backend APIs on Amazon API Gateway. Which TWO actions must the developer take to configure the authentication and authorization flow?

Select all that apply

Set up a Cognito User Pool to handle user registration and sign-in, and configure a Cognito User Pool Authorizer on API Gateway to secure the APIs.

Set up a Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary AWS credentials for S3 bucket uploads.

Set up a Cognito User Pool to generate temporary AWS credentials for S3 uploads using Cognito Sync.

Create a custom API Gateway Lambda Authorizer that decodes and validates the Cognito User Pool identity tokens to authorize API calls.

Create a Cognito Identity Pool to store user profiles and authenticate users directly via email and password.

Show answer & explanation

Answer: Set up a Cognito User Pool to handle user registration and sign-in, and configure a Cognito User Pool Authorizer on API Gateway to secure the APIs.; Set up a Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary AWS credentials for S3 bucket uploads.

Answer

To configure the authentication and authorization flow, the developer must set up a Cognito User Pool to manage authentication and secure the API Gateway using a Cognito User Pool Authorizer, and set up a Cognito Identity Pool referencing the User Pool to obtain temporary AWS credentials for S3 uploads.

The system requires a Cognito User Pool to handle user directory registration, login, and token generation. The backend APIs are secured with minimal complexity by using the native Cognito User Pool Authorizer on API Gateway. Direct uploads to Amazon S3 are enabled by exchanging the user token for temporary AWS credentials via a Cognito Identity Pool, which assumes an authenticated IAM role with the necessary S3 permissions.

Step-by-Step Solution

Configure a Cognito User Pool.

Establishes a user directory for client registration and authentication, issuing identity and access tokens (JWTs) upon successful login.

A User Pool is required to manage credentials and handle user sign-in.

Create a Cognito User Pool Authorizer on Amazon API Gateway.

API Gateway validates the token automatically for incoming requests without requiring custom code.

Using the native Cognito Authorizer reduces operational overhead and simplifies API security.

Create a Cognito Identity Pool and link it to the User Pool.

The client application can exchange User Pool tokens for temporary AWS credentials mapped to an IAM role with S3 write permissions.

An Identity Pool is necessary to delegate temporary AWS access for direct interaction with S3.

Key Concept

Amazon Cognito User Pools vs. Identity Pools and API Gateway Authorization

Question 368Question →

A developer is building a personal finance application. Users must be able to sign up, sign in, and access secured REST API endpoints on Amazon API Gateway. Additionally, users must be able to upload scanned monthly statements directly to a private Amazon S3 bucket. Which architecture meets these requirements with the least operational overhead?

Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito Identity Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito User Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito User Pool for user registration and authentication, write a custom Lambda authorizer to manually parse and validate the Cognito JSON Web Tokens (JWT) for the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and configure the application client with an IAM user's long-term access keys to handle the Amazon S3 uploads.

Show answer & explanation

Answer: Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Answer

The correct architecture uses a Cognito User Pool to handle user registration and login, an API Gateway Cognito user pool authorizer to secure REST API endpoints with no coding effort, and a Cognito Identity Pool to dynamically exchange user pool tokens for temporary IAM credentials that authorize the client application to upload files directly to S3.

Step-by-Step Solution

Set up user authentication and directory services.

Create an Amazon Cognito User Pool to manage user registration, sign-in, and user attributes.

A User Pool serves as a user directory and issues JSON Web Tokens (JWT) upon successful authentication.

Protect the REST API endpoints in API Gateway.

Create a built-in Cognito User Pool authorizer in API Gateway and configure the API methods to require this authorizer.

Using the built-in Cognito authorizer allows API Gateway to natively validate the user's ID or access tokens without requiring custom Lambda code, minimizing operational overhead.

Configure secure access to Amazon S3.

Create an Amazon Cognito Identity Pool, specify the User Pool as the authentication provider, and map authenticated users to an IAM role with write permissions to the destination S3 bucket.

Cognito Identity Pools authorize access to AWS resources by exchanging external authentication tokens for scoped, temporary AWS credentials.

Key Concept

Distinction between Amazon Cognito User Pools (authentication) and Cognito Identity Pools (authorization to access AWS resources), alongside native API Gateway Cognito authorizer integration.

Estimated Time:2m 0s

Question 369Question →

A developer is building a serverless web application for a fitness tracking portal. The application must allow users to log in using their existing Google or Facebook accounts. Once authenticated, the application must allow users to retrieve their profile data from an Amazon API Gateway REST API and upload workout videos directly to a private Amazon S3 bucket. Which TWO configuration steps should the developer perform to implement this authentication and authorization workflow with the least operational overhead?

Select all that apply

Configure a Cognito User Pool with Google and Facebook social identity providers, and configure a Cognito Authorizer on the API Gateway REST API.

Configure a Cognito Identity Pool, set the Cognito User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

Configure a Cognito User Pool with Google and Facebook, and associate an IAM role with the User Pool to generate temporary credentials for writing directly to the S3 bucket.

Configure a custom API Gateway Lambda Authorizer to validate the social identity provider tokens, and have it return temporary AWS credentials to the client for the S3 uploads.

Configure a custom API Gateway Lambda Authorizer to validate the Cognito Identity Pool token for the REST API endpoint.

Show answer & explanation

Answer: Configure a Cognito User Pool with Google and Facebook social identity providers, and configure a Cognito Authorizer on the API Gateway REST API.; Configure a Cognito Identity Pool, set the Cognito User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

Answer

Configure a Cognito User Pool with Google and Facebook social identity providers, configure a Cognito Authorizer on the API Gateway REST API, configure a Cognito Identity Pool using the User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

To implement authentication with Google and Facebook and access both API Gateway and S3 with the least operational overhead, the developer should combine a Cognito User Pool with a Cognito Identity Pool. The Cognito User Pool authenticates the federated social users and provides tokens. These tokens are natively validated by the API Gateway Cognito Authorizer to secure REST API endpoints without custom code. To allow direct upload to a private S3 bucket, the application must exchange the User Pool tokens for temporary AWS credentials using a Cognito Identity Pool, which maps the authenticated session to an IAM role with S3 write permissions.

Step-by-Step Solution

Set up User Directory and Social Federation

Configure an Amazon Cognito User Pool with Google and Facebook as identity providers to handle user registration, login, and identity token issuance.

A User Pool acts as the user directory and manages federation, allowing the application to authenticate users and receive JSON Web Tokens (JWTs) representing their identity.

Authorize API Access

Configure a Cognito Authorizer on the Amazon API Gateway REST API endpoints.

The Cognito Authorizer natively validates the identity tokens (JWTs) passed in the authorization header of incoming API requests, securing the backend with zero custom code.

Enable S3 Write Permissions

Create an Amazon Cognito Identity Pool, configure the User Pool as the authentication provider, and associate the authenticated IAM role with S3 write permissions.

An Identity Pool (Federated Identities) is required to exchange the authenticated User Pool token for temporary, short-lived AWS credentials, enabling the client application to directly upload video files to S3 without using a proxy backend.

Key Concept

Amazon Cognito Authentication and Authorization

Question 370Question →

A developer is configuring an AWS Lambda function in Account A ( $111111111111$ ) that needs to write items to an Amazon DynamoDB table in Account B ( $222222222222$ ). The developer wants to use cross-account IAM roles to implement secure access following the principle of least privilege. An IAM role named `CrossAccountDynamoDBWriter` has been created in Account B with the necessary permission policy to write to the DynamoDB table.

Which two configuration steps must the developer perform to enable the Lambda function to access the DynamoDB table?

Select all that apply

In Account B, configure the trust policy of the `CrossAccountDynamoDBWriter` role to allow the Lambda function's execution role in Account A to assume the role.

In Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the `CrossAccountDynamoDBWriter` role in Account B.

In Account A, configure the trust policy of the Lambda function's execution role to trust the `CrossAccountDynamoDBWriter` role in Account B.

In Account A, configure the Lambda function to use hardcoded access keys of an IAM user from Account B that has write access to the DynamoDB table.

In Account A, configure the Lambda function to assume the `CrossAccountDynamoDBWriter` role by adding a resource-based policy directly to the Lambda function.

Show answer & explanation

Answer: In Account B, configure the trust policy of the `CrossAccountDynamoDBWriter` role to allow the Lambda function's execution role in Account A to assume the role.; In Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the `CrossAccountDynamoDBWriter` role in Account B.

Answer

In Account B, configure the trust policy of the role to allow the Lambda function's execution role in Account A to assume the role, and in Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the role in Account B.

For cross-account access, a two-way permission handshake is required. The role in the trusting account (Account B) must have a trust policy allowing the trusted identity (Account A's Lambda execution role) to assume it. Concurrently, the trusted identity in Account A must have an identity-based policy allowing it to call `sts:AssumeRole` on the target role in Account B.

Step-by-Step Solution

Configure the trust relationship on the target role in Account B.

The `CrossAccountDynamoDBWriter` role in Account B trusts the Lambda function's execution role in Account A.

A role must explicitly declare which identities are trusted to assume it via its trust policy.

Grant permission to the Lambda execution role in Account A to perform the assume role action.

The Lambda execution role in Account A is authorized to perform `sts:AssumeRole` on the target role's ARN.

An IAM identity must be explicitly granted permission to perform the `sts:AssumeRole` API call on a target resource.

Key Concept

Cross-account IAM role access requires configuring both a trust policy on the resource role and an identity-based permission policy on the calling principal.

Estimated Time:2m 0s

Question 371Question →

An enterprise web application needs to allow employees to sign in using their corporate Identity Provider (IdP) via SAML 2.0. Once authenticated, the application must allow users to upload files directly to a user-specific folder in an Amazon S3 bucket. The architecture must minimize operational overhead and avoid storing long-term credentials on the client. Which solution meets these requirements with the least operational overhead?

Configure an Amazon Cognito User Pool integrated with the SAML IdP. Retrieve the ID token upon successful authentication and pass it directly to the Amazon S3 API headers to authorize direct client-side uploads.

Configure an Amazon API Gateway endpoint with a custom Lambda Authorizer that validates the SAML assertions, creates a Cognito User Pool user on the fly, and uses the API Gateway service integration to upload files directly to S3.

Configure an Amazon Cognito User Pool integrated with the SAML IdP, and associate it with an Amazon Cognito Identity Pool. Use the Identity Pool to map the federated users to an IAM role that grants access to the user-specific S3 folder using the cognito-identity.amazonaws.com:sub variable.

Configure an Amazon Cognito User Pool integrated with the SAML IdP. Set up an API Gateway endpoint backed by a Lambda function that contains hardcoded IAM access keys to upload files to the S3 bucket on behalf of the user.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool integrated with the SAML IdP, and associate it with an Amazon Cognito Identity Pool. Use the Identity Pool to map the federated users to an IAM role that grants access to the user-specific S3 folder using the cognito-identity.amazonaws.com:sub variable.

Answer

The correct solution leverages Amazon Cognito User Pools to manage authentication with the corporate SAML Identity Provider, and Amazon Cognito Identity Pools to exchange the authentication tokens for temporary AWS IAM credentials. The IAM policy attached to the authenticated role uses the cognito-identity.amazonaws.com:sub policy variable to dynamically restrict access to the user's specific folder in the S3 bucket, ensuring security with minimal operational overhead.

Step-by-Step Solution

Configure SAML federation with the corporate Identity Provider within an Amazon Cognito User Pool.

Users can authenticate against their corporate IdP and receive Cognito User Pool tokens.

This establishes user authentication without managing passwords locally or creating custom SAML validation logic.

Link the Cognito User Pool as an authentication provider in an Amazon Cognito Identity Pool.

The Identity Pool can verify the Cognito User Pool tokens and exchange them for temporary AWS credentials.

Cognito Identity Pools are designed to authorize users and provide temporary AWS IAM credentials.

Create an IAM role for authenticated users with a policy permitting S3 PutObject actions restricted to user-specific prefixes using the cognito-identity.amazonaws.com:sub variable, and associate it with the Identity Pool.

Authenticated users receive dynamic, scope-limited temporary credentials to upload directly to their own S3 folder.

This implements secure, direct client-to-S3 uploads with minimal latency, avoiding the need for an intermediary backend server or hardcoded credentials.

Key Concept

Amazon Cognito Identity Pools are used to federate identities and obtain temporary AWS credentials for accessing AWS resources like Amazon S3, whereas Cognito User Pools handle user directory management and authentication.

Estimated Time:2m 0s

Question 372Question →

A developer is configuring an AWS CodeBuild project to deploy an infrastructure stack using AWS CloudFormation. The deployment process requires CloudFormation to assume a specific IAM service role named `CFNDeploymentRole` to create resources. The CodeBuild build container runs under an IAM role named `CodeBuildExecutionRole`.

Which two configuration steps must the developer perform to ensure the deployment succeeds? (Select two.)

Select all that apply

Attach an IAM policy to `CodeBuildExecutionRole` that grants the `iam:PassRole` action on the `CFNDeploymentRole` resource ARN.

Configure the trust policy of `CFNDeploymentRole` to allow the `cloudformation.amazonaws.com` service principal to assume the role.

Configure the trust policy of `CFNDeploymentRole` to allow the `codebuild.amazonaws.com` service principal to assume the role.

Attach an IAM policy to `CFNDeploymentRole` that grants `iam:AssumeRole` permission for the `CodeBuildExecutionRole` ARN.

Store the AWS access key ID and secret access key of an administrative IAM user as environment variables in the CodeBuild project configuration.

Show answer & explanation

Answer: Attach an IAM policy to `CodeBuildExecutionRole` that grants the `iam:PassRole` action on the `CFNDeploymentRole` resource ARN.; Configure the trust policy of `CFNDeploymentRole` to allow the `cloudformation.amazonaws.com` service principal to assume the role.

Answer

To ensure successful deployment, the developer must attach an IAM policy to `CodeBuildExecutionRole` granting `iam:PassRole` on `CFNDeploymentRole`, and configure `CFNDeploymentRole`'s trust policy to allow `cloudformation.amazonaws.com` to assume it.

To successfully deploy the stack, two main configurations are required. First, the CodeBuild execution role must have the authority to pass the deployment role to AWS CloudFormation, which is accomplished via the `iam:PassRole` permission. Second, the deployment role must allow CloudFormation to assume it, which is configured by adding `cloudformation.amazonaws.com` to the trust policy of the deployment role.

Step-by-Step Solution

Identify that the CodeBuild environment must pass the deployment role to AWS CloudFormation.

Determine that the build execution role (`CodeBuildExecutionRole`) requires `iam:PassRole` permissions on the deployment role.

When passing service roles to other AWS services, the calling entity must have the `iam:PassRole` permission.

Determine which service principal needs to assume the deployment role.

Identify that the trust policy of the deployment role (`CFNDeploymentRole`) must trust `cloudformation.amazonaws.com`.

Since AWS CloudFormation is the service executing the stack creation, it must be allowed to assume the service role.

Key Concept

IAM Role delegation and the use of the `iam:PassRole` permission to pass service roles to AWS services.

Question 373Question →

A developer is designing a smart-home mobile application that allows authenticated users to read their device telemetry data directly from an Amazon DynamoDB table. The solution must minimize backend server management and allow the mobile app to make direct, secure SDK calls to DynamoDB using temporary AWS credentials, restricting users to only access their own data. Which architecture should the developer implement to meet these requirements?

Configure an Amazon Cognito User Pool for user authentication and directory services, and an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials. Associate an IAM role with the Identity Pool that uses a policy with a dynamodb:LeadingKeys condition matching the Cognito identity ID.

Configure an Amazon Cognito User Pool for user authentication. Have the mobile application send the User Pool ID token directly in the authorization header of the AWS SDK client to perform DynamoDB operations.

Configure an Amazon Cognito User Pool for user authentication. Set up Amazon API Gateway with a custom Lambda Authorizer that parses the JWT, validates it against the User Pool, and performs the DynamoDB operations directly within the authorizer function.

Configure an Amazon Cognito Identity Pool as the user directory to manage user sign-ups and logins. Configure the mobile application to use the Identity Pool credentials to access DynamoDB, relying on application-side logic to filter data access.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool for user authentication and directory services, and an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials. Associate an IAM role with the Identity Pool that uses a policy with a dynamodb:LeadingKeys condition matching the Cognito identity ID.

Answer

The correct architecture uses Cognito User Pools to authenticate the users, and Cognito Identity Pools to exchange those tokens for temporary AWS credentials. By applying a policy with a dynamodb:LeadingKeys condition matching the Cognito identity ID on the IAM role assumed via the Identity Pool, the developer achieves direct, fine-grained access control to the DynamoDB table with minimal operational overhead.

Step-by-Step Solution

Determine the authentication and directory mechanism.

Implement an Amazon Cognito User Pool to act as the identity provider, managing user registration, sign-in, and authentication tokens.

User Pools are specifically designed for user directories, handling authentication, and generating JSON Web Tokens (JWTs).

Determine the authorization and credential retrieval mechanism.

Implement an Amazon Cognito Identity Pool, configuring the User Pool as an authentication provider.

Identity Pools are designed to exchange authentication tokens (such as User Pool JWTs) for temporary, limited-privilege AWS credentials needed for direct SDK calls.

Apply fine-grained access control in the authorized IAM role.

Attach a policy to the Identity Pool's authenticated IAM role with a dynamodb:LeadingKeys condition set to the user's Cognito identity ID.

Using the dynamodb:LeadingKeys condition ensures that the authenticated user is restricted to reading and writing items in the DynamoDB table where the partition key matches their unique Cognito identity ID.

Key Concept

Integration of Amazon Cognito User Pools and Identity Pools for direct, fine-grained access to AWS services.

Estimated Time:2m 0s

Question 374Question →

A developer is configuring a third-party SaaS monitoring application to collect performance metrics from Amazon EC2 instances in their AWS account. The SaaS vendor's application runs in AWS account 123456789012. The vendor requires a secure delegation mechanism using an external ID value of VendorTokenXYZ.

The developer creates an IAM role named SaaSMonitoringRole with the following trust policy:

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

And attaches the following permissions policy to the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:Describe*",
"Resource": "*",
"Condition": {
"StringEquals": {
"sts:ExternalId": "VendorTokenXYZ"
}
}
}
]
}

However, the third-party application is unable to retrieve the EC2 metrics. Which of the following changes will resolve the authorization issue and follow security best practices?

Move the sts:ExternalId condition block from the permissions policy to the condition block of the trust policy.

Add the Principal element directly to the permissions policy and declare the third-party AWS account ID within it.

Modify the trust policy to change the allowed action from sts:AssumeRole to sts:AssumeRoleWithWebIdentity.

Create an IAM user with administrative permissions, generate access keys, and configure the third-party application to use these long-term credentials.

Show answer & explanation

Answer: Move the sts:ExternalId condition block from the permissions policy to the condition block of the trust policy.

Answer

Move the sts:ExternalId condition block from the permissions policy to the condition block of the trust policy.

The correct action is to move the sts:ExternalId condition block from the permissions policy to the trust policy of the IAM role. The sts:ExternalId context key is only populated during the AssumeRole operation handled by AWS STS. Once the role is assumed and the caller makes subsequent calls to Amazon EC2, the sts:ExternalId context key is no longer available, causing any policy checking this context key during EC2 operations to fail. Evaluating it in the trust policy ensures that the external ID is verified at the moment of role assumption.

Step-by-Step Solution

Analyze the IAM policies to identify where the sts:ExternalId condition is evaluated.

The sts:ExternalId context key is currently placed inside the identity-based permissions policy attached to the role.

This is incorrect because sts:ExternalId is only present in the request context during the sts:AssumeRole API call, not during subsequent calls to services like Amazon EC2.

Determine the proper location for the sts:ExternalId condition.

The condition must be placed within the trust policy of the IAM role.

The trust policy governs who can call sts:AssumeRole to obtain temporary credentials for the role. Placing the condition here allows AWS STS to validate the External ID when the SaaS application attempts to assume the role.

Modify the policies to follow standard security practices.

The permissions policy is updated to allow ec2:Describe* without the sts:ExternalId condition, and the trust policy is updated to include the Condition block checking the External ID.

This ensures successful role assumption and resource authorization while protecting against the confused deputy problem.

Key Concept

IAM trust policies vs permissions policies and the usage of External ID during AssumeRole operations

Estimated Time:1m 30s

Question 375Question →

A developer is configuring an Amazon ECS task definition to deploy a containerized application on AWS Fargate. The application running inside the container needs to write records to an Amazon Kinesis data stream. During task startup, the Amazon ECS container agent must pull the private container image from Amazon Elastic Container Registry (Amazon ECR) and retrieve a database password from AWS Secrets Manager.

The developer creates an IAM role named AppTaskRole to grant the application access to the Kinesis data stream. However, when attempting to run the task, the container agent fails to pull the image and cannot retrieve the secret.

Which TWO actions must the developer perform to resolve this issue?

Select all that apply

Configure the task definition by specifying an IAM role with policies that allow ECR image pull and Secrets Manager read permissions as the Task Execution Role (executionRoleArn).

Configure the task definition by specifying the AppTaskRole, which contains Kinesis write permissions, as the Task Role (taskRoleArn).

Attach the ECR image pull and Secrets Manager read permissions directly to AppTaskRole and omit the Task Execution Role configuration in the task definition.

Modify the trust policy of the IAM roles to allow the ecs.amazonaws.com service principal to assume the roles.

Inject static AWS access keys and secret keys as container environment variables in the task definition to authenticate the application client.

Show answer & explanation

Answer: Configure the task definition by specifying an IAM role with policies that allow ECR image pull and Secrets Manager read permissions as the Task Execution Role (executionRoleArn).; Configure the task definition by specifying the AppTaskRole, which contains Kinesis write permissions, as the Task Role (taskRoleArn).

Answer

Specify an IAM role with ECR and Secrets Manager permissions as the Task Execution Role, and associate the AppTaskRole with Kinesis permissions as the Task Role in the task definition.

The correct configurations describe the separate roles required by ECS Fargate tasks: the Task Execution Role (executionRoleArn) is used by the ECS container agent to pull ECR images and retrieve Secrets Manager secrets, while the Task Role (taskRoleArn) is assumed by the application code running inside the container to make AWS API requests like writing to a Kinesis data stream.

Step-by-Step Solution

Differentiate between container agent tasks and application container tasks.

The ECS agent performs the image pull and secret resolution before container startup. The application container performs the Kinesis write operations during execution.

ECS Fargate separates operations performed by the infrastructure agent from operations performed by the application code itself.

Assign the appropriate role to the executionRoleArn configuration parameter.

The ECS agent is authorized to pull ECR images and read Secrets Manager secrets.

The Task Execution Role provides credentials to the ECS container agent.

Assign the AppTaskRole to the taskRoleArn configuration parameter.

The application code running inside the container receives credentials to write to the Kinesis data stream.

The Task Role provides credentials directly to the containerized application.

Key Concept

Distinguishing ECS Task Role from ECS Task Execution Role

Question 376Question →

A developer is creating an AWS Lambda function that must write logs to Amazon CloudWatch Logs and read objects from an Amazon S3 bucket. The developer creates an IAM role with the necessary permissions policy attached. However, when the developer tries to create the Lambda function and associate it with this IAM role, the operation fails with an authorization error. The developer reviews the trust policy currently associated with the IAM role:

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

Which action will resolve this issue and allow the Lambda function to run with the required permissions?

Modify the trust policy of the IAM role to change the Action element from sts:AssumeRole to cloudwatch:PutLogEvents and s3:GetObject.

Modify the trust policy of the IAM role to change the service principal in the Principal block to lambda.amazonaws.com.

Add the lambda:InvokeFunction permission directly to the Action element of the trust policy, and specify the Lambda function's ARN in the Principal block.

Initialize the AWS SDK clients inside the Lambda function code by passing the AWS access key ID and secret access key of an IAM admin user.

Show answer & explanation

Answer: Modify the trust policy of the IAM role to change the service principal in the Principal block to lambda.amazonaws.com.

Answer

Modify the trust policy of the IAM role to change the service principal in the Principal block to lambda.amazonaws.com.

The trust policy of an IAM role defines which security principal (in this case, an AWS service) is allowed to assume the role using the Security Token Service (STS). For an AWS Lambda function to assume the role, the service principal must be set to 'lambda.amazonaws.com'. Changing the principal from 'ec2.amazonaws.com' to 'lambda.amazonaws.com' resolves the authorization failure.

Step-by-Step Solution

Analyze the error message and the trust policy.

The trust policy allows the service principal 'ec2.amazonaws.com' to assume the role.

To determine why the Lambda service is unauthorized to assume the role.

Identify the required service principal for the Lambda function.

The AWS Lambda service needs to assume the role, which requires the principal 'lambda.amazonaws.com'.

Different AWS services require different service principals in their trust policies to assume execution roles.

Change the Principal.Service value in the trust policy.

Update the trust policy to allow 'lambda.amazonaws.com' to assume the role.

This allows the Lambda service to successfully assume the execution role when running the function.

Key Concept

IAM Trust Policies define which entities (such as AWS services) are allowed to assume an IAM role. A permissions policy defines what actions the assumed role can perform.

Question 377Question →

An application is running on an Amazon EC2 instance in Account A (111111111111). The application needs to read data from an Amazon DynamoDB table in Account B (222222222222) by assuming an IAM role named CrossAccountDynamoDBRole in Account B. The EC2 instance is launched with an IAM instance profile associated with the IAM role EC2AppRole in Account A.

Which IAM trust policy must be attached to the CrossAccountDynamoDBRole in Account B to allow the EC2 application to assume it?

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/EC2AppRole"
},
"Action": "sts:AssumeRole"
}
]
}

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

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:instance-profile/EC2AppInstanceProfile"
},
"Action": "sts:AssumeRole"
}
]
}

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/EC2AppRole"
},
"Action": "dynamodb:GetItem"
}
]
}

Show answer & explanation

Answer:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/EC2AppRole"
},
"Action": "sts:AssumeRole"
}
]
}

Answer

The trust policy that allows the IAM role EC2AppRole from Account A to assume the role in Account B using the action sts:AssumeRole.

The correct trust policy designates the IAM role in Account A (arn:aws:iam::111111111111:role/EC2AppRole) as the trusted principal and allows the sts:AssumeRole action. When the application on the EC2 instance calls AssumeRole, AWS STS verifies that the trust policy of the target role in Account B allows this specific role to assume it.

Step-by-Step Solution

Identify the principal that needs to perform the assume role action.

The identity calling sts:AssumeRole is the IAM role EC2AppRole associated with the EC2 instance in Account A (111111111111).

Since the application runs under the credentials of EC2AppRole, the trust policy in Account B must explicitly target this role's ARN as the principal.

Select the correct Action for the trust policy.

The action must be sts:AssumeRole.

Trust policies govern role assumption and must specify sts:AssumeRole as the allowed action.

Construct the trust policy JSON.

A policy statement containing Effect: Allow, Principal: AWS referencing the role ARN, and Action: sts:AssumeRole.

This structure satisfies both the principal identity and the STS action requirements.

Key Concept

Cross-account IAM role trust relationships

Estimated Time:1m 30s

Question 378Question →

A developer is building a serverless web portal for a medical scheduling system. Users must authenticate using their corporate Google Workspace accounts through OpenID Connect (OIDC). Once authenticated, the web portal must invoke private API routes hosted on Amazon API Gateway. The developer needs to validate the user session token at the API Gateway layer with the least operational overhead and without writing custom validation code.

Which solution meets these requirements?

Configure an Amazon Cognito User Pool federated with the Google Workspace OIDC provider, and set up an API Gateway Cognito authorizer that directly validates the identity tokens.

Configure an Amazon Cognito Identity Pool federated with the Google Workspace OIDC provider, enable AWS IAM authorization on API Gateway, and sign the client API requests using AWS Signature Version 4.

Configure an Amazon Cognito User Pool federated with the Google Workspace OIDC provider, and write a custom API Gateway Lambda authorizer to parse and validate the JSON Web Tokens (JWT) manually.

Configure an Amazon Cognito Identity Pool federated with the Google Workspace OIDC provider, and create an API Gateway Cognito authorizer linked to the Identity Pool to validate the client tokens.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool federated with the Google Workspace OIDC provider, and set up an API Gateway Cognito authorizer that directly validates the identity tokens.

Answer

Configure an Amazon Cognito User Pool federated with the Google Workspace OIDC provider, and set up an API Gateway Cognito authorizer that directly validates the identity tokens.

The correct solution uses an Amazon Cognito User Pool to handle the OpenID Connect federation with Google Workspace, which issues standard JSON Web Tokens. By using the built-in API Gateway Cognito authorizer, API Gateway validates these tokens automatically, eliminating the need to write custom validation logic or perform complex request signing on the client.

Step-by-Step Solution

Determine if User Pools or Identity Pools are appropriate for the user federation and token generation requirement.

Amazon Cognito User Pools is chosen to act as the user directory and federated identity consumer for the OIDC provider (Google Workspace).

User Pools are used for authentication and directories, producing JSON Web Tokens (JWTs) such as identity and access tokens.

Select the API Gateway authorizer that validates the authentication tokens with the least operational overhead.

Select the built-in API Gateway Cognito authorizer.

API Gateway's native Cognito authorizer handles JWT validation out of the box, requiring zero custom code and removing the need to manage Lambda functions or sign requests using Signature Version 4.

Key Concept

Selecting the correct Cognito service and API Gateway authorizer type to minimize custom development when integrating external identity providers.

Estimated Time:1m 30s

Question 379Question →

A developer is configuring a Python application running on an Amazon EC2 instance in Account A ( $111122223333$ ) to retrieve files from a private Amazon S3 bucket located in Account B ( $444455556666$ ). The EC2 instance is associated with an IAM instance profile utilizing a role named `EC2ReadRole`. The developer creates an IAM role named `S3AccessRole` in Account B. However, when the application attempts to assume the role, it receives an `AccessDenied` error. The trust policy for `S3AccessRole` in Account B is currently configured as follows:

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

Which two configuration steps must the developer perform to successfully establish this cross-account access and resolve the `AccessDenied` error? (Select TWO.)

Select all that apply

Attach a permissions policy to the EC2ReadRole in Account A that allows the sts:AssumeRole action on the arn:aws:iam::444455556666:role/S3AccessRole resource.

Attach a permissions policy to the S3AccessRole in Account B that allows the s3:GetObject action on the target S3 bucket resource.

Add a statement to the S3AccessRole permissions policy in Account B that allows the sts:AssumeRole action targeting the EC2ReadRole ARN.

Modify the S3 bucket policy in Account B to allow the sts:AssumeRole action for the EC2ReadRole ARN.

Modify the application code on the EC2 instance to initialize the AWS SDK client with hardcoded AWS access keys of an IAM user from Account B.

Show answer & explanation

Answer: Attach a permissions policy to the EC2ReadRole in Account A that allows the sts:AssumeRole action on the arn:aws:iam::444455556666:role/S3AccessRole resource.; Attach a permissions policy to the S3AccessRole in Account B that allows the s3:GetObject action on the target S3 bucket resource.

Answer

To resolve the AccessDenied error and secure cross-account access, the developer must attach a permissions policy to the EC2 role in Account A allowing it to perform the assume-role action on the target role, and attach an IAM policy to the target role in Account B allowing it to perform the S3 read operations.

For cross-account access via role assumption, both sides of the trust and delegation must be configured. The EC2ReadRole in Account A must have permissions to execute the sts:AssumeRole call (as described in the option to attach a permissions policy to EC2ReadRole), and the assumed S3AccessRole in Account B must be authorized to perform the s3:GetObject operations on the target bucket (as described in the option to attach an S3 permissions policy to S3AccessRole).

Step-by-Step Solution

Analyze the IAM trust relationship configuration.

The trust policy on S3AccessRole in Account B correctly lists Account A's EC2ReadRole as a trusted entity that can execute sts:AssumeRole.

This verifies that Account B permits Account A to assume the role, meaning the issue must lie in Account A's permissions or the permissions of the assumed role.

Configure the permissions of the calling identity in Account A.

Attach an IAM policy to EC2ReadRole in Account A allowing the sts:AssumeRole action on the ARN of S3AccessRole.

By default, IAM roles have no outbound permissions unless explicitly granted. The EC2 role must have permission to request the STS token.

Configure the permissions of the assumed role in Account B.

Attach an IAM policy to S3AccessRole in Account B allowing the s3:GetObject action on the target S3 bucket.

When the application assumes S3AccessRole, it inherits only the permissions assigned to that role. It must be explicitly permitted to perform S3 actions on the target resource.

Key Concept

IAM trust policies define which entities are trusted to assume a role, while permissions policies define what actions the assumed role can perform on AWS resources.

Question 380Question →

A developer is configuring an AWS Lambda function in Account A ( $111122223333$ ) to be triggered by an Amazon SQS queue named `IncomingQueue` in Account B ( $444455556666$ ). The developer wants to establish this cross-account event source mapping under the principle of least privilege, without requiring the Lambda function to perform an explicit assume-role operation in its application code.

The developer has already attached the following permissions policy to the Lambda function's execution role, `LambdaQueueReaderRole`, in Account A:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sqs:ReceiveMessage",
"sqs:DeleteMessage",
"sqs:GetQueueAttributes"
],
"Resource": "arn:aws:sqs:us-east-1:444455556666:IncomingQueue"
}
]
}

Which of the following configurations are also required to establish this cross-account trigger? (Select TWO.)

Select all that apply

Configure the resource-based policy of the SQS queue in Account B to allow the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions for the principal `arn:aws:iam::111122223333:role/LambdaQueueReaderRole`.

Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the SQS service principal (`sqs.amazonaws.com`) to perform the `sts:AssumeRole` action.

Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the Lambda service principal (`lambda.amazonaws.com`) to perform the `sts:AssumeRole` action.

Store static AWS access keys for an IAM User created in Account B within the Lambda function's environment variables and initialize the SQS client with them.

Modify the resource-based policy of the SQS queue in Account B to allow the `sts:AssumeRole` action for the `LambdaQueueReaderRole` principal.

Show answer & explanation

Answer: Configure the resource-based policy of the SQS queue in Account B to allow the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions for the principal `arn:aws:iam::111122223333:role/LambdaQueueReaderRole`.; Configure the trust policy of `LambdaQueueReaderRole` in Account A to allow the Lambda service principal (`lambda.amazonaws.com`) to perform the `sts:AssumeRole` action.

Answer

Configure the resource-based policy of the SQS queue in Account B to grant access to the Lambda execution role, and configure the trust policy of the Lambda execution role in Account A to allow the Lambda service principal to assume the role.

For cross-account SQS integration to work with AWS Lambda, the Lambda execution role in Account A must have the necessary IAM permissions to call SQS APIs, and its trust policy must allow `lambda.amazonaws.com` to assume it. Additionally, since the queue resides in Account B, the SQS queue's resource policy must permit the Lambda execution role ARN from Account A to execute the required consumer actions.

Step-by-Step Solution

Verify Lambda Execution Role Trust Policy

The trust policy of the execution role in Account A must trust the service principal `lambda.amazonaws.com` so that the Lambda service has permission to assume the role.

Without this trust relationship, AWS Lambda cannot assume the execution role to poll the queue or invoke the function.

Configure the Cross-Account Resource Policy

Update the SQS queue policy in Account B to allow the Lambda execution role's ARN in Account A to perform the `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `sqs:GetQueueAttributes` actions.

For cross-account access to SQS, both the identity-based policy in the source account and the resource-based policy in the destination account must explicitly allow the actions.

Key Concept

Cross-account SQS integration requires both an identity-based policy in the source account and a resource-based policy in the destination account, alongside a properly configured trust relationship for the executing service principal.

Estimated Time:2m 0s

PreviousPage 19 / 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