Security

390 questions

All types390 Multiple choice195 Multiple select195

A startup is building a new mobile application for ride-sharing. The developer needs to establish a secure user directory that manages user registration, sign-in, password recovery, and multi-factor authentication (MFA).

Which Amazon Cognito feature should the developer implement to meet these requirements?

Amazon Cognito Identity Pools

Amazon Cognito User Pools

Amazon API Gateway Lambda Authorizer

AWS Identity and Access Management (IAM) Roles

Show answer & explanation

Answer: Amazon Cognito User Pools

Answer

Amazon Cognito User Pools

Amazon Cognito User Pools is the correct choice because it is a user directory that provides sign-up and sign-in options for web and mobile applications, including features like user directory management, password recovery, and multi-factor authentication (MFA).

Step-by-Step Solution

Identify the primary requirement, which is to build a secure user directory for managing user registration, sign-in, password recovery, and multi-factor authentication (MFA).

The requirement points to a user directory management and authentication solution.

Determining whether authentication/user directory or authorization/AWS resource access is needed.

Compare Cognito User Pools and Cognito Identity Pools.

User Pools handle authentication, registration, and user directory management, whereas Identity Pools handle authorization by exchanging tokens for temporary AWS credentials.

Cognito User Pools is the direct match for hosting a user directory and managing user signup/signin.

Key Concept

Amazon Cognito User Pools provide authentication and user directory management, whereas Identity Pools provide authorization to AWS resources.

Question 282Question →

A company has an administrative backend service exposed through an Amazon API Gateway REST API. A developer needs to grant access to this API to a serverless processing application running under a specific IAM role in a different AWS account. The connection must be secure and follow the principle of least privilege without requiring the maintenance of user directories or custom code. Which two configuration steps should the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Set the authorization type of the API Gateway method to AWS_IAM.

Apply a resource policy to the API Gateway REST API that grants execute-api:Invoke permissions to the consumer IAM role ARN.

Create a custom Lambda authorizer that receives the caller's role ARN and uses the AWS Security Token Service (AWS STS) to validate the signature.

Configure an Amazon Cognito Identity Pool to authenticate the serverless application's IAM role and generate a JSON Web Token (JWT) to pass to a Cognito User Pool authorizer.

Configure Lambda proxy integration for the API method and use a request body mapping template to extract and verify the caller's Signature Version 4 credentials.

Show answer & explanation

Answer: Set the authorization type of the API Gateway method to AWS_IAM.; Apply a resource policy to the API Gateway REST API that grants execute-api:Invoke permissions to the consumer IAM role ARN.

Answer

To implement cross-account access securely under least privilege without custom code or user directories, set the API Gateway method authorization to AWS_IAM and apply an API Gateway resource policy that grants the external IAM role ARN access to execute-api:Invoke.

To secure the API for cross-account access without using custom code or user directories, AWS_IAM authorization is the native and most secure solution. By setting the authorization type of the API Gateway method to AWS_IAM, the API will require all requests to be signed using Signature Version 4 (SigV4) with credentials associated with an IAM identity. Then, using an API Gateway resource policy allows cross-account authorization by explicitly permitting the specific external IAM role ARN to execute the API method.

Step-by-Step Solution

Enable IAM authentication on the API Gateway method.

The API method now requires all requests to be signed using Signature Version 4 (SigV4) with valid AWS IAM credentials.

This ensures that API Gateway natively evaluates the identity of the incoming caller using standard AWS IAM signatures.

Configure the REST API resource policy.

A resource policy is attached to the API Gateway that allows the principal ARN corresponding to the consumer's IAM role to invoke the 'execute-api:Invoke' action.

This permits cross-account API invocation by specifying exactly which external IAM identity is allowed access.

Key Concept

Cross-account IAM authentication and authorization for Amazon API Gateway REST APIs.

Estimated Time:1m 30s

Question 283Question →

A developer is setting up an AWS CodeBuild project that needs to upload build artifacts to an Amazon S3 bucket named `app-build-artifacts-2026`. The project fails with an authorization error during the build phase. The developer reviews the IAM role created for CodeBuild, which currently has no permissions policies attached, and has the following trust policy:

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

Which two changes are required to allow the CodeBuild project to upload artifacts to the S3 bucket? (Select TWO.)

Select all that apply

Update the Service principal in the trust policy to codebuild.amazonaws.com.

Attach a permissions policy to the role that allows s3:PutObject on the resource arn:aws:s3:::app-build-artifacts-2026/*.

Change the Service principal in the trust policy to s3.amazonaws.com.

Add s3:PutObject to the Action array inside the existing trust policy statement.

Hardcode the AWS access key and secret access key of an administrator IAM user within the build command script.

Show answer & explanation

Answer: Update the Service principal in the trust policy to codebuild.amazonaws.com.; Attach a permissions policy to the role that allows s3:PutObject on the resource arn:aws:s3:::app-build-artifacts-2026/*.

Answer

The correct changes are to update the Service principal in the trust policy to codebuild.amazonaws.com, and to attach a permissions policy to the role that allows s3:PutObject on the resource arn:aws:s3:::app-build-artifacts-2026/*.

Updating the Service principal to codebuild.amazonaws.com allows CodeBuild to assume the execution role. Attaching a policy allowing s3:PutObject on arn:aws:s3:::app-build-artifacts-2026/* grants the required write permissions on the bucket's objects.

Step-by-Step Solution

Inspect and fix the trust relationship of the IAM role.

The Service principal is changed from ec2.amazonaws.com to codebuild.amazonaws.com, allowing CodeBuild to assume the role.

Since CodeBuild is running the build process, it needs permission to assume the IAM role associated with the project.

Create and attach a permissions policy for S3 write access.

A policy containing s3:PutObject for the resource arn:aws:s3:::app-build-artifacts-2026/* is attached to the role.

The role currently has no permissions policies, so it has no rights to perform S3 actions. Adding this policy permits uploading objects to the bucket.

Key Concept

An IAM role must have a trust policy allowing the executing AWS service principal to assume it, and a permissions policy granting the specific API access needed for resources.

Question 284Question →

A developer is configuring a serverless application where an AWS Lambda function in AWS Account A ( $111111111111$ ) needs to read objects from an Amazon S3 bucket named `company-data-shared` in AWS Account B ( $222222222222$ ). The Lambda function is associated with the execution role `arn:aws:iam::111111111111:role/LambdaExecutionRole`. Currently, the Lambda function fails with an `AccessDenied` error when attempting to fetch objects from the bucket. Which configuration changes must the developer make to resolve the error while maintaining the principle of least privilege? (Select two.)

Select all that apply

In Account A, attach a permission policy to the Lambda execution role that grants the `s3:GetObject` action on `arn:aws:s3:::company-data-shared/*`.

In Account B, update the bucket policy of `company-data-shared` to allow the `s3:GetObject` action on `arn:aws:s3:::company-data-shared/*` for the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole`.

In Account B, configure a trust policy on the S3 bucket that allows the Lambda execution role in Account A to perform `sts:AssumeRole` on the bucket.

Modify the Lambda function code to use hardcoded IAM access keys and secret keys of a user in Account B that has read permissions to the S3 bucket.

In Account A, update the trust policy of the Lambda execution role to allow the Amazon S3 service principal `s3.amazonaws.com` to assume the role.

Show answer & explanation

Answer: In Account A, attach a permission policy to the Lambda execution role that grants the `s3:GetObject` action on `arn:aws:s3:::company-data-shared/*`.; In Account B, update the bucket policy of `company-data-shared` to allow the `s3:GetObject` action on `arn:aws:s3:::company-data-shared/*` for the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole`.

Answer

In Account A, attach a permission policy to the Lambda execution role that grants the s3:GetObject action on the S3 bucket, and in Account B, update the bucket policy of the S3 bucket to allow s3:GetObject for the Lambda execution role principal.

For cross-account S3 access, permissions must be granted on both sides. The identity-based policy attached to the Lambda execution role in Account A must grant the `s3:GetObject` permission on the specific bucket resource in Account B. Simultaneously, the resource-based bucket policy on the S3 bucket in Account B must grant the same permission to the Lambda execution role's ARN as the principal. Without both configurations, cross-account access will be denied.

Step-by-Step Solution

Configure the IAM identity-based policy in Account A.

The Lambda execution role in Account A is granted permission to perform `s3:GetObject` on the S3 bucket in Account B.

Even for cross-account resources, the requesting identity must explicitly have the permission granted in its own account's policy.

Configure the S3 bucket policy (resource-based policy) in Account B.

The S3 bucket permits the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole` from Account A to read objects.

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

Verify the configuration using the Lambda function's execution context without using hardcoded credentials.

The Lambda function uses its execution role's temporary credentials automatically provided by the AWS SDK, resolving the access issue securely.

Hardcoding credentials violates security best practices and is unnecessary because the SDK automatically uses the IAM role credentials.

Key Concept

Cross-account resource access in AWS requires authorization from both the identity-based policy (source account) and the resource-based policy (destination account).

Question 285Question →

A developer is building a new web application that allows users to sign up, sign in, and download files directly from a private Amazon S3 bucket. The application must handle user directory management and authenticate users before granting them temporary access to S3. Which two Amazon Cognito resources should the developer configure to satisfy these authentication and authorization requirements?

Select all that apply

A Cognito User Pool to manage user registration, authentication, and the user directory.

A Cognito Identity Pool to exchange authentication tokens for temporary AWS credentials to access S3.

A Cognito User Pool to directly generate temporary IAM credentials for accessing the Amazon S3 bucket.

A Cognito Identity Pool to store user profiles and handle password recovery emails.

A custom API Gateway Lambda Authorizer to validate Cognito tokens and generate AWS STS temporary credentials for client S3 access.

Show answer & explanation

Answer: A Cognito User Pool to manage user registration, authentication, and the user directory.; A Cognito Identity Pool to exchange authentication tokens for temporary AWS credentials to access S3.

Answer

To meet the requirements, the developer must configure a Cognito User Pool to handle user directory management and authentication, and a Cognito Identity Pool to authorize access and provide temporary AWS credentials for the S3 bucket.

The correct solution involves configuring both a Cognito User Pool and a Cognito Identity Pool. The User Pool manages user directory services (registration, login, password recovery), and the Identity Pool handles authorization by exchanging the authenticated user's tokens for temporary AWS IAM credentials so the application can access the S3 bucket directly.

Step-by-Step Solution

Identify the authentication and directory management requirement.

Amazon Cognito User Pools must be configured because they act as the identity provider, handling registration, sign-in, and tokens.

User Pools are specifically designed to serve as a user directory and manage authentication flow.

Identify the authorization and AWS resource access requirement.

Amazon Cognito Identity Pools must be configured to federate the User Pool tokens.

Identity Pools are designed to exchange authentication tokens (such as OIDC tokens from a User Pool) for temporary AWS credentials via AWS STS.

Configure the client application to obtain S3 access.

The client app authenticates with the User Pool, sends the resulting token to the Identity Pool, receives temporary AWS credentials, and uses them to access the S3 bucket directly.

This flow leverages AWS best practices for secure web client interactions with AWS services.

Key Concept

Separation of concerns between Cognito User Pools (authentication/directory) and Cognito Identity Pools (authorization/AWS credentials).

Estimated Time:1m 0s

Question 286Question →

A developer is building a Python application running on Amazon ECS that must encrypt JSON telemetry reports of approximately $80\text{ KB}$ each before storing them in an Amazon S3 bucket. The application must use AWS Key Management Service (AWS KMS) for encryption. Which approach should the developer implement to meet these requirements?

Configure the ECS task definition with an ECS Task Execution Role that has `kms:GenerateDataKey` permissions, and call the KMS `GenerateDataKey` API operation from the application code to obtain the keys.

Call the KMS `GenerateDataKey` API operation using a customer managed key to obtain a plaintext data key and an encrypted data key. Encrypt the telemetry report locally using the plaintext data key, upload both the encrypted report and the encrypted data key to the S3 bucket, and then delete the plaintext data key from memory.

Call the KMS `Encrypt` API operation directly, passing the

80\text{ KB}

telemetry report as the `Plaintext` parameter, and upload the returned ciphertext to the S3 bucket.

Generate a symmetric key locally within the application code, store that key in AWS Secrets Manager, retrieve it using the Secrets Manager API to encrypt each telemetry report, and upload the encrypted reports to the S3 bucket.

Show answer & explanation

Answer: Call the KMS `GenerateDataKey` API operation using a customer managed key to obtain a plaintext data key and an encrypted data key. Encrypt the telemetry report locally using the plaintext data key, upload both the encrypted report and the encrypted data key to the S3 bucket, and then delete the plaintext data key from memory.

Answer

Calling the KMS `GenerateDataKey` API operation to obtain a plaintext and encrypted data key, performing local encryption with the plaintext key, storing the encrypted data and encrypted key, and deleting the plaintext key from memory.

The correct approach uses client-side envelope encryption. Since the JSON payload size is

80\text{ KB}

, direct encryption via the KMS `Encrypt` API is not possible due to its

4\text{ KB}

limit. By calling `GenerateDataKey` with a customer managed key, the application receives a plaintext data key to perform local encryption using a symmetric algorithm (like AES-256) and an encrypted data key. The application uploads the ciphertext data and the encrypted data key to the S3 bucket, then deletes the plaintext key from memory to prevent security leaks. Accessing KMS requires the credentials of the ECS Task Role, which is used by the application code.

Step-by-Step Solution

Analyze the size of the telemetry report payload.

The telemetry report is

80\text{ KB}

, which is larger than the

4\text{ KB}

direct encryption limit of the KMS `Encrypt` API.

Determines that the application must use envelope encryption rather than sending the raw payload to KMS.

Choose the appropriate KMS API operation for envelope encryption.

The KMS `GenerateDataKey` API operation is selected to generate the plaintext and encrypted versions of the data key.

Allows the application to encrypt the

80\text{ KB}

payload locally using the plaintext key and store the encrypted key with the data.

Verify ECS IAM configuration.

Ensure the KMS permission policy is attached to the ECS Task Role.

The application code running in the container relies on the Task Role for AWS SDK credentials, not the Task Execution Role.

Key Concept

AWS KMS Envelope Encryption and ECS IAM Roles

Question 287Question →

A developer is configuring an Amazon Elastic Container Service (ECS) task definition for a containerized application. The application code needs to retrieve objects from an Amazon S3 bucket at runtime. Additionally, the ECS container agent requires permissions to pull the private container image from Amazon Elastic Container Registry (ECR) to launch the task. Which configuration should the developer use to grant the appropriate permissions?

Assign an IAM role with Amazon S3 permissions to the Task Execution Role, and assign an IAM role with Amazon ECR permissions to the Task Role.

Configure the container's environment variables with the AWS Access Key ID and Secret Access Key of an IAM user that has both Amazon S3 and Amazon ECR permissions.

Assign an IAM role with Amazon S3 permissions to the Task Role, and assign an IAM role with Amazon ECR permissions to the Task Execution Role.

Assign an IAM role with both Amazon S3 and Amazon ECR permissions to the Task Execution Role, and leave the Task Role blank.

Show answer & explanation

Answer: Assign an IAM role with Amazon S3 permissions to the Task Role, and assign an IAM role with Amazon ECR permissions to the Task Execution Role.

Answer

Assign an IAM role with Amazon S3 permissions to the Task Role, and assign an IAM role with Amazon ECR permissions to the Task Execution Role.

The correct configuration requires assigning the application-specific permissions (Amazon S3 access) to the ECS Task Role so the containerized application code can access S3 at runtime. The container agent itself requires permissions to pull images from Amazon ECR, which must be assigned to the ECS Task Execution Role.

Step-by-Step Solution

Identify the resource-access requirements for the containerized application.

The application code itself needs to access Amazon S3 at runtime.

Application-level permissions must be mapped to the ECS Task Role.

Identify the resource-access requirements for the ECS container agent.

The ECS agent needs to pull the Docker image from Amazon ECR before the container starts.

Agent-level infrastructure permissions must be mapped to the ECS Task Execution Role.

Combine the configurations in the ECS task definition.

Assign S3 permissions to the Task Role and ECR permissions to the Task Execution Role.

This setup aligns with the principle of least privilege and ensures correct authorization separation.

Key Concept

ECS Task Role vs Task Execution Role

Estimated Time:1m 0s

Question 288Question →

An organization is migrating a legacy system to AWS and exposing its services through an Amazon API Gateway REST API. The client applications authenticate using custom JWTs issued by a proprietary on-premises identity provider that cannot be integrated with Amazon Cognito. The API Gateway must validate these tokens and extract custom claims to authorize requests before forwarding them to the backend microservices. Which authorization strategy should the developer implement to secure this API with the least operational complexity?

Configure a Lambda authorizer on the API Gateway to decode and validate the incoming JWT, and return an IAM policy that grants or denies access to the API methods.

Configure a Lambda proxy integration for the API, and write validation logic inside the backend Lambda function to decode the JWT and return a 401 Unauthorized status if invalid.

Configure an Amazon Cognito identity pool to authenticate the clients, exchange their proprietary JWTs for temporary AWS credentials, and enforce IAM authorization on the API.

Configure an Amazon Cognito user pool with a built-in Cognito authorizer on the API Gateway, and configure client applications to authenticate natively with User Pool endpoints.

Show answer & explanation

Answer: Configure a Lambda authorizer on the API Gateway to decode and validate the incoming JWT, and return an IAM policy that grants or denies access to the API methods.

Answer

Configure a Lambda authorizer on the API Gateway to decode and validate the incoming JWT, and return an IAM policy that grants or denies access to the API methods.

The correct strategy is to use a Lambda authorizer on the API Gateway. This allows the API Gateway to execute a custom Lambda function to validate the incoming proprietary JWT and return a cached IAM policy that controls access to the API methods, securing the API at the perimeter.

Step-by-Step Solution

Analyze the token source and integration requirements.

The clients use custom JWTs from a proprietary on-premises provider that cannot integrate with Amazon Cognito.

This rules out native Amazon Cognito User Pool authorizers since the tokens are not Cognito-native.

Evaluate where token validation and authorization should occur.

Validation should occur at the API Gateway boundary rather than in the backend proxy integration.

Performing checks at the gateway prevents unauthorized invocations of backend services, optimizing cost and security.

Select the correct API Gateway custom authentication mechanism.

Configure a Lambda authorizer.

Lambda authorizers are designed to parse custom tokens, validate them against custom logic, and return an IAM policy representing permissions.

Key Concept

Lambda Authorizers for Custom Token Validation

Estimated Time:1m 30s

Question 289Question →

A developer is configuring an Amazon API Gateway REST API to write execution logs to Amazon CloudWatch Logs. The developer creates an IAM role for API Gateway to assume and configures the following trust policy on the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "apigateway.amazonaws.com"
},
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
]
}
]
}

However, when testing the API Gateway REST API, the developer notices that no execution logs are appearing in CloudWatch. How should the developer correct this configuration?

Update the trust policy's Action to "sts:AssumeRole", and attach a separate IAM permissions policy to the role that grants the CloudWatch Logs actions.

Change the Service principal in the trust policy to "logs.amazonaws.com" to permit the CloudWatch Logs service to accept logs from API Gateway.

Add "sts:AssumeRole" to the Action array in the current trust policy to grant both role assumption and logging capabilities in a single statement.

Hardcode the AWS Access Key ID and Secret Access Key of an administrator IAM user inside the API Gateway integration's client code.

Show answer & explanation

Answer: Update the trust policy's Action to "sts:AssumeRole", and attach a separate IAM permissions policy to the role that grants the CloudWatch Logs actions.

Answer

Update the trust policy's Action to "sts:AssumeRole", and attach a separate IAM permissions policy to the role that grants the CloudWatch Logs actions.

The correct option is to update the trust policy's Action to "sts:AssumeRole" and attach a separate permissions policy to the role. In AWS IAM, a role has two types of policies: a trust policy (which defines which principal is trusted to assume the role) and a permissions policy (which defines what the identity assuming the role can do). A trust policy must specify "Action": "sts:AssumeRole". The functional permissions for CloudWatch Logs (such as logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents) must be attached to the role via an identity-based permissions policy, not specified in the trust policy.

Step-by-Step Solution

Analyze the IAM role's trust policy.

The current trust policy specifies logging actions directly in the Action block of the trust relationship, which is invalid.

An IAM role's trust policy (trust relationship) is only used to define which principals can assume the role. The only action it should grant is 'sts:AssumeRole'.

Separate trust relationships from permissions policies.

Modify the trust policy's Action to 'sts:AssumeRole' for the service principal 'apigateway.amazonaws.com'. Create a separate IAM permissions policy containing 'logs:CreateLogGroup', 'logs:CreateLogStream', and 'logs:PutLogEvents', and attach it to the role.

This establishes a valid trust relationship allowing API Gateway to assume the role, and grants the assumed role the necessary permissions to write to CloudWatch Logs.

Key Concept

IAM Trust Policies vs. Permissions Policies

Question 290Question →

An enterprise web application requires users to sign in using their corporate Identity Provider (IdP) via SAML 2.0. After successful authentication, the web application must access tenant-specific folders in an Amazon S3 bucket directly from the browser. Additionally, the application must make authorized calls to a backend REST API hosted on Amazon API Gateway. The developer wants to minimize custom coding for token validation and credential exchange. Which architecture configuration satisfies these requirements with the least operational overhead?

Configure an Amazon Cognito User Pool integrated with the SAML IdP to authenticate users and issue JWTs. Secure the REST API using an API Gateway Cognito Authorizer. Authorize direct S3 access by passing the Cognito User Pool ID token in the Authorization header of the S3 request.

Configure an Amazon Cognito User Pool integrated with the SAML IdP to authenticate users and issue JWTs. Configure an Amazon Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary IAM credentials for S3 access. Secure the REST API using an API Gateway Lambda authorizer that performs custom validation of the Cognito User Pool ID token.

Configure an Amazon Cognito User Pool integrated with the SAML IdP to authenticate users and issue JWTs. Configure an Amazon Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary IAM credentials for S3 access. Secure the REST API using an API Gateway Cognito Authorizer that validates the User Pool tokens.

Configure an Amazon Cognito Identity Pool with the SAML IdP configured as an identity provider to authenticate users and obtain temporary IAM credentials for S3 access. Secure the REST API using an API Gateway Cognito Authorizer that directly validates the temporary IAM credentials.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool integrated with the SAML IdP to authenticate users and issue JWTs. Configure an Amazon Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary IAM credentials for S3 access. Secure the REST API using an API Gateway Cognito Authorizer that validates the User Pool tokens.

Answer

Configure an Amazon Cognito User Pool integrated with the SAML IdP to authenticate users and issue JWTs, use an Amazon Cognito Identity Pool to obtain temporary IAM credentials for S3 access, and secure the REST API using an API Gateway Cognito Authorizer that validates User Pool tokens.

The correct option correctly uses Cognito User Pools to handle federation and authentication via SAML 2.0, Cognito Identity Pools to exchange user identity for temporary IAM credentials for S3 access, and the native API Gateway Cognito Authorizer to secure backend API requests. This aligns perfectly with the responsibilities of each Cognito component and achieves the requirements with the least operational and development overhead.

Step-by-Step Solution

Configure SAML federation in Cognito User Pool

Users can authenticate against the corporate IdP via SAML 2.0, and Cognito User Pool issues ID, access, and refresh tokens.

This establishes user identity and directory management using the existing corporate IdP.

Integrate Cognito Identity Pool with the User Pool

The application can exchange the Cognito User Pool ID token for temporary AWS IAM credentials.

This enables secure, direct access to S3 without exposing static AWS credentials or routing S3 uploads through a backend proxy.

Configure API Gateway with a Cognito User Pool Authorizer

API Gateway automatically validates incoming Cognito User Pool tokens to authorize REST API requests.

This secures the REST API using built-in platform capabilities, avoiding the overhead of custom Lambda validation code.

Key Concept

Integration of Cognito User Pools (authentication & token issuance), Cognito Identity Pools (temporary AWS credentials for direct resource access), and API Gateway Cognito Authorizers (token-based API security).

Question 291Question →

An application running on AWS Fargate needs to encrypt sensitive PDF contract files (each approximately $5\text{ MB}$ in size) before storing them in an Amazon Elastic File System (Amazon EFS) volume. The application must use envelope encryption with a customer managed key in AWS KMS.

Which two actions should a developer implement to meet these requirements? (Select TWO.)

Select all that apply

Call the GenerateDataKey API operation of AWS KMS using the customer managed key to obtain a plaintext data key and an encrypted data key.

Encrypt the PDF files locally with the plaintext data key, store the encrypted data key alongside the encrypted PDF files on Amazon EFS, and immediately delete the plaintext data key from memory.

Call the Encrypt API operation of AWS KMS with the customer managed key, passing the entire PDF file payload directly to return the encrypted ciphertext.

Call the GenerateDataKeyWithoutPlaintext API operation of AWS KMS to retrieve only the encrypted data key, and decrypt it locally using an SSL certificate.

Store the PDF files as secure parameters in AWS Systems Manager Parameter Store using a SecureString parameter type encrypted with the customer managed key.

Show answer & explanation

Answer: Call the GenerateDataKey API operation of AWS KMS using the customer managed key to obtain a plaintext data key and an encrypted data key.; Encrypt the PDF files locally with the plaintext data key, store the encrypted data key alongside the encrypted PDF files on Amazon EFS, and immediately delete the plaintext data key from memory.

Answer

Call the GenerateDataKey API operation of AWS KMS using the customer managed key to obtain a plaintext data key and an encrypted data key, and encrypt the PDF files locally with the plaintext data key, store the encrypted data key alongside the encrypted PDF files on Amazon EFS, and immediately delete the plaintext data key from memory.

To encrypt payloads larger than

4\text{ KB}

, envelope encryption is required. The developer calls the `GenerateDataKey` API operation, which returns a plaintext data key and an encrypted data key. The application encrypts the PDF locally using the plaintext key, stores the encrypted data key alongside the ciphertext on Amazon EFS, and discards the plaintext data key from memory.

Step-by-Step Solution

Generate a unique data key using AWS KMS.

The application receives a plaintext version and an encrypted version of the data key.

Because the files are larger than the

4\text{ KB}

limit of KMS direct encryption, envelope encryption must be used.

Perform local client-side encryption.

The PDF file is encrypted into ciphertext using the plaintext data key.

To secure the data locally before writing it to the shared file system.

Store the encrypted data key and cleanup memory.

The encrypted PDF file and the encrypted data key are written to Amazon EFS, and the plaintext data key is purged from memory.

The encrypted key is required for future decryption, and removing the plaintext key from memory protects against unauthorized memory dumps.

Key Concept

AWS KMS envelope encryption workflow for objects larger than

4\text{ KB}

Estimated Time:1m 30s

Question 292Question →

A developer is configuring an AWS Lambda function in Account A ( $111122223333$ ) to write data to an Amazon DynamoDB table in Account B ( $444455556666$ ). The function executes using the IAM execution role `AccountALambdaRole`. The developer creates an IAM role named `CrossAccountAccessRole` in Account B with a policy that allows write operations on the DynamoDB table. The trust policy for `CrossAccountAccessRole` is currently configured as follows:

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

When the Lambda function in Account A attempts to assume the role `CrossAccountAccessRole` using the AWS SDK to write to the DynamoDB table, it fails with an `AccessDenied` error. Which two of the following modifications are required to resolve this error and allow the Lambda function to write to the DynamoDB table?

Select all that apply

Update the trust policy of CrossAccountAccessRole in Account B to specify the Principal as "AWS": "arn:aws:iam::111122223333:role/AccountALambdaRole" instead of the lambda.amazonaws.com service principal.

Attach an IAM permission policy to AccountALambdaRole in Account A that grants the sts:AssumeRole action on the resource arn:aws:iam::444455556666:role/CrossAccountAccessRole.

Add a statement to the identity-based permission policy of AccountALambdaRole in Account A that includes a Principal element set to lambda.amazonaws.com with the sts:AssumeRole action.

Modify the trust policy of the Lambda execution role AccountALambdaRole in Account A to trust the role arn:aws:iam::444455556666:role/CrossAccountAccessRole.

Configure the Lambda function code to use hardcoded AWS access keys of an IAM user from Account B in the AWS SDK client constructor to write to the DynamoDB table directly.

Show answer & explanation

Answer: Update the trust policy of CrossAccountAccessRole in Account B to specify the Principal as "AWS": "arn:aws:iam::111122223333:role/AccountALambdaRole" instead of the lambda.amazonaws.com service principal.; Attach an IAM permission policy to AccountALambdaRole in Account A that grants the sts:AssumeRole action on the resource arn:aws:iam::444455556666:role/CrossAccountAccessRole.

Answer

To allow the Lambda function in Account A to write to the DynamoDB table in Account B, the developer must update the trust policy of the target role in Account B to trust the Lambda execution role's ARN, and attach an identity-based policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the target role's ARN.

For cross-account access using IAM roles, a two-way authorization flow must be established. First, the trust policy of the target role in Account B must be updated to specify the caller's ARN (Account A's Lambda role) as the trusted Principal. Second, the calling identity (Account A's Lambda role) must be granted the sts:AssumeRole permission on the target role's ARN in its identity-based policy. This establishes both the trust from the target and the permission from the source.

Step-by-Step Solution

Modify the trust policy in the target account (Account B).

The trust policy of CrossAccountAccessRole in Account B is updated to trust the ARN of AccountALambdaRole from Account A.

This establishes trust between Account B's role and the specific IAM principal in Account A, permitting the execution role to assume it.

Modify the permissions policy in the source account (Account A).

An identity-based policy is attached to AccountALambdaRole allowing the sts:AssumeRole action on the target role's ARN in Account B.

This grants the caller in Account A the necessary outbound permission to perform the role assumption operation.

Update the Lambda function code to use temporary credentials.

The AWS SDK calls AssumeRole, retrieves temporary credentials, and instantiates the DynamoDB client using them.

The function must run with the temporary credentials generated by the assumed role to access the DynamoDB table in Account B.

Key Concept

Cross-account IAM role assumption requires both a trust policy on the target role specifying the calling principal and a permission policy on the calling principal allowing sts:AssumeRole on the target role resource.

Question 293Question →

A developer is deploying an application on a standalone Amazon EC2 instance. The application needs to read messages from an Amazon SQS queue and write records to an Amazon DynamoDB table. To follow security best practices, the developer decides to use an IAM role. Which TWO configurations or steps are required to securely grant the EC2 instance the necessary permissions? (Select TWO.)

Select all that apply

Create an IAM role with a trust policy that allows the ec2.amazonaws.com service principal to assume the role.

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

Store an IAM user's long-term Access Key ID and Secret Access Key in the application's configuration file on the instance.

Configure the trust policy of the IAM role to allow the dynamodb.amazonaws.com service principal to assume the role.

Assign the application's permission policy directly to the ECS Task Execution Role of the instance.

Show answer & explanation

Answer: Create an IAM role with a trust policy that allows the ec2.amazonaws.com service principal to assume the role.; Associate the IAM role with an EC2 instance profile and attach the instance profile to the EC2 instance.

Answer

To securely grant the EC2 instance permissions, the developer must create an IAM role with a trust policy allowing the EC2 service principal to assume it, and attach this role to the EC2 instance using an EC2 instance profile.

The correct configurations are to create an IAM role with a trust policy that allows the EC2 service principal (ec2.amazonaws.com) to assume the role, and to associate this role with an EC2 instance profile which is then attached to the EC2 instance. This configuration allows the application running on the EC2 instance to securely retrieve temporary security credentials from the instance metadata without hardcoding secrets.

Step-by-Step Solution

Determine the service principal that needs to assume the role.

Since the application runs on an EC2 instance, the trust policy must specify 'ec2.amazonaws.com' as the principal.

The trust policy controls which AWS service or entity is allowed to assume the IAM role and retrieve temporary credentials.

Determine how the role is associated with the EC2 instance.

The IAM role must be associated with an EC2 instance profile, and that instance profile must be attached to the EC2 instance.

EC2 instances require an instance profile to act as a bridge to attach an IAM role to the instance.

Key Concept

Assigning IAM permissions to EC2 instances using Instance Profiles and Trust Policies

Question 294Question →

A developer is writing a backend service that needs to encrypt a sensitive JSON configuration payload of $3\text{ KB}$ before writing it to an Amazon DynamoDB table. The encryption must be performed client-side using AWS KMS, minimizing latency and the number of AWS API calls.

Which approach meets these requirements most efficiently?

Call the KMS GenerateDataKey API to retrieve a data key, encrypt the JSON payload locally using the plaintext key, and store the encrypted data key along with the ciphertext in the DynamoDB table.

Call the KMS Encrypt API directly using a customer managed key, and store the resulting ciphertext in the DynamoDB table.

Call the KMS GenerateDataKeyWithoutPlaintext API to obtain an encrypted data key, call the Decrypt API to retrieve the plaintext key, encrypt the JSON payload locally, and store it in the DynamoDB table.

Store the JSON configuration payload in AWS Secrets Manager as a secret, configure automatic rotation, and retrieve the secret using a DynamoDB stream trigger on every write operation.

Show answer & explanation

Answer: Call the KMS Encrypt API directly using a customer managed key, and store the resulting ciphertext in the DynamoDB table.

Answer

Call the KMS Encrypt API directly using a customer managed key, and store the resulting ciphertext in the DynamoDB table.

The correct option is to call the KMS Encrypt API directly because the payload size (

3\text{ KB}

) is less than the

4\text{ KB}

limit for direct KMS encryption. This approach minimizes latency by requiring only one API call and removes the complexity of managing envelope encryption keys locally.

Step-by-Step Solution

Determine the size of the payload to be encrypted.

The JSON payload is

3\text{ KB}

(

3072

bytes).

AWS KMS limits direct encryption via the Encrypt API to a maximum of

4\text{ KB}

(

4096

bytes).

Select the appropriate KMS API strategy.

Since

3\text{ KB} < 4\text{ KB}

, the payload can be encrypted directly using the Encrypt API rather than employing envelope encryption.

Direct encryption requires only a single API call and removes the operational overhead of managing data keys client-side.

Execute the encryption and store the output.

Send the plaintext payload to the KMS Encrypt API, receive the ciphertext, and store it in DynamoDB.

This achieves client-side encryption with minimum latency and complexity.

Key Concept

AWS KMS direct encryption capability and its

4\text{ KB}

payload limit.

Question 295Question →

A developer is configuring an AWS Lambda function that needs to read objects from an Amazon S3 bucket. The developer creates an IAM role containing the following permission policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-app-data/*"
}
]
}

Which configuration must be applied to the trust policy of this IAM role so that the Lambda function can successfully assume it?

A trust policy that grants the ec2.amazonaws.com service principal permission to perform the sts:AssumeRole action

A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

No trust policy is required; instead, the developer should initialize the AWS SDK client using static credentials of an IAM user hardcoded in the function code

A trust policy that grants the ecs-tasks.amazonaws.com service principal permission to perform the sts:AssumeRole action

Show answer & explanation

Answer: A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

Answer

A trust policy that grants the lambda.amazonaws.com service principal permission to perform the sts:AssumeRole action

For an AWS service like AWS Lambda to execute code and access other AWS resources, it must assume an IAM execution role. This requires a trust policy attached to the role that explicitly allows the 'lambda.amazonaws.com' service principal to call 'sts:AssumeRole'.

Step-by-Step Solution

Identify the AWS service attempting to assume the IAM role.

The service is AWS Lambda.

The execution environment requires the Lambda service principal to acquire temporary credentials.

Verify the correct service principal name for AWS Lambda.

The principal is lambda.amazonaws.com.

Each AWS service has a specific principal identifier used in trust policies.

Determine the API action required for assuming a role.

The action is sts:AssumeRole.

The Security Token Service (STS) action sts:AssumeRole is required to delegate access to services or accounts.

Key Concept

IAM trust policies define which principals (users, accounts, or services) are allowed to assume an IAM role.

Question 296Question →

A developer is implementing client-side decryption in an application. The application receives a data package containing a $5\text{ MB}$ ciphertext payload and an encrypted data key that was originally generated using an AWS KMS customer managed key. The application has the necessary IAM permissions to access the customer managed key.

Which sequence of steps must the developer perform in the application code to decrypt the payload?

Call the KMS GenerateDataKey API using the customer managed key to obtain the plaintext data key, decrypt the payload locally using this key, and then discard the new encrypted data key.

Submit the entire ciphertext payload directly to the KMS Decrypt API, allowing AWS KMS to automatically locate the customer managed key, decrypt the payload, and return the plaintext data.

Send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

Retrieve the plaintext data key from Systems Manager Parameter Store using the GetParameter API with the customer managed key's ARN, decrypt the payload locally, and store the decrypted data back in Parameter Store as a SecureString.

Show answer & explanation

Answer: Send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

Answer

The correct sequence is to send the encrypted data key to the KMS Decrypt API to retrieve the plaintext data key, decrypt the ciphertext payload locally using the plaintext data key, and then delete the plaintext data key from memory.

The correct sequence matches the standard client-side envelope decryption workflow. The application sends the encrypted data key (which is small enough to fit within KMS API limits) to the KMS Decrypt API. KMS uses the customer managed key to decrypt it and returns the plaintext data key. The application then performs local decryption on the

5\text{ MB}

payload and safely removes the plaintext key from memory.

Step-by-Step Solution

Send the encrypted data key to the AWS KMS Decrypt API.

The API returns the plaintext data key.

To perform client-side decryption, the application first needs the raw plaintext data key.

Decrypt the ciphertext payload locally using the retrieved plaintext data key.

The

5\text{ MB}

payload is decrypted into its original plaintext format.

Because KMS has a

4\text{ KB}

API limit, decryption must be handled locally by the application using cryptographic libraries.

Delete the plaintext data key from the application memory.

The plaintext data key is removed from memory.

Leaving the plaintext key in memory exposes it to potential security risks.

Key Concept

AWS KMS Envelope Decryption

Question 297Question →

A developer has deployed an AWS Lambda function named `DataProcessor` in Account A ( $111111111111$ ) and configured a Function URL with the authorization type set to `AWS_IAM`. An IAM role named `AppRole` in Account B ( $222222222222$ ) needs to invoke this function by sending HTTP requests directly to the Function URL. Which combination of configuration steps will successfully and securely grant `AppRole` the necessary permissions to invoke the Function URL?

Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunction` permissions to `AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunction` on the function ARN in Account A.

Attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` with the Resource element set to the function's HTTP URL, and add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` to Account B.

Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` permissions to the Principal `arn:aws:iam::222222222222:role/AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` on the function ARN in Account A.

Modify the trust policy of `AppRole` in Account B to trust the AWS Lambda service principal (`lambda.amazonaws.com`), and attach an identity-based policy to `AppRole` allowing `sts:AssumeRole` on the Lambda function ARN in Account A.

Show answer & explanation

Answer: Add a resource-based policy to the Lambda function in Account A that grants `lambda:InvokeFunctionUrl` permissions to the Principal `arn:aws:iam::222222222222:role/AppRole`, and attach an identity-based policy to `AppRole` in Account B that allows `lambda:InvokeFunctionUrl` on the function ARN in Account A.

Answer

The correct configuration uses the specific `lambda:InvokeFunctionUrl` action, which is required for Lambda Function URLs. Because the access is cross-account, both the resource-based policy in Account A (which must list the external role ARN as the principal) and the identity-based policy in Account B (which must allow the action on the function ARN) are required.

Step-by-Step Solution

Identify the correct IAM action required for Function URL invocations.

The action is `lambda:InvokeFunctionUrl` rather than `lambda:InvokeFunction`.

AWS separates standard API-based invocations (`lambda:InvokeFunction`) from HTTP-based Function URL invocations (`lambda:InvokeFunctionUrl`).

Configure permissions for cross-account access.

Permissions must be configured on both the target resource (resource-based policy) and the calling identity (identity-based policy).

For cross-account access, trust must be established bidirectionally: the hosting account must allow the external entity, and the external entity must allow its identity to perform the action on the destination resource.

Verify resource identifier compliance in the policy syntax.

The Resource block must reference the Lambda function ARN, not the HTTP URL endpoint.

IAM Resource elements do not support HTTP URLs; they only accept valid AWS Amazon Resource Names (ARNs).

Key Concept

Cross-account IAM authorization for AWS Lambda Function URLs

Estimated Time:2m 0s

Question 298Question →

A developer is building a web application that stores user-specific files in a private Amazon S3 bucket. The application uses an Amazon Cognito User Pool for user authentication. The developer wants to authorize users to access their department's files in S3 using temporary AWS credentials. The user's department is stored in a custom attribute named custom:department in the User Pool. The developer has created a separate IAM role for each department. Which approach should the developer use to assign the correct IAM role to each user with the least operational overhead?

Create an Amazon Cognito Identity Pool and add the User Pool as an identity provider. Configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

Configure the Amazon Cognito User Pool to issue temporary AWS credentials directly by mapping the custom:department attribute to the AWS STS AssumeRole API parameters in the User Pool app client settings.

Create an Amazon Cognito Identity Pool with a single authenticated role. Use the IAM policy variable ${cognito-identity.amazonaws.com:custom:department} in the role's permission policy to dynamically grant access to the department's S3 folder.

Configure an API Gateway REST API with a custom Lambda authorizer that validates the User Pool ID token and calls the AWS STS AssumeRole API to generate and return temporary credentials to the client.

Show answer & explanation

Answer: Create an Amazon Cognito Identity Pool and add the User Pool as an identity provider. Configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

Answer

Create an Amazon Cognito Identity Pool, add the User Pool as an identity provider, and configure rules-based role mapping on the identity provider to match the custom:department claim in the ID token to the corresponding IAM role.

The correct solution uses an Amazon Cognito Identity Pool to exchange the ID token from the User Pool for temporary AWS credentials. By configuring rules-based role mapping on the User Pool identity provider within the Identity Pool, the developer can inspect the custom:department claim present in the authenticated user's ID token and dynamically assign the corresponding department-specific IAM role. This requires zero custom code and leverages native AWS features, minimizing operational overhead.

Step-by-Step Solution

Identify the separation of concerns between Amazon Cognito User Pools and Identity Pools.

Confirm that User Pools handle authentication (user sign-in and profile attributes) while Identity Pools handle authorization (exchanging tokens for temporary AWS credentials).

Since the client needs direct access to S3, temporary AWS credentials must be vended via an Identity Pool.

Determine how to map the custom attribute from the User Pool to the required IAM role.

Leverage the rules-based role mapping feature of Cognito Identity Pools.

Rules-based mapping allows evaluating the custom:department claim from the ID token and dynamically assigning one of the pre-created department-specific IAM roles.

Eliminate options that introduce unnecessary custom code or rely on unsupported policy variables.

Reject solutions involving custom Lambda authorizers on API Gateway or unsupported Cognito Identity Pool policy variables.

These alternatives increase operational complexity and fail to utilize the built-in, native integrations of Amazon Cognito.

Key Concept

Role mapping in Amazon Cognito Identity Pools based on Cognito User Pool ID token claims

Question 299Question →

A developer is building a document processing application that runs on an Amazon EC2 instance. The application needs to encrypt scanned PDF documents (each averaging $15\text{ MB}$ in size) before sending them to a third-party storage system. Security policy requires that the files be encrypted using client-side envelope encryption with an AWS KMS customer managed key.

Which TWO steps should the developer take to implement this encryption workflow?

Select all that apply

Call the GenerateDataKey API operation against the customer managed key to retrieve a plaintext data key and an encrypted data key.

Encrypt the PDF document locally using the plaintext data key, and then immediately remove the plaintext data key from memory.

Send the PDF documents directly to the AWS KMS Encrypt API operation to perform server-side encryption.

Call the GenerateDataKeyWithoutPlaintext API operation to obtain the encrypted key, and decrypt it locally using a public key pair.

Store the generated plaintext data key in AWS Systems Manager Parameter Store as a SecureString parameter for later decryption.

Show answer & explanation

Answer: Call the GenerateDataKey API operation against the customer managed key to retrieve a plaintext data key and an encrypted data key.; Encrypt the PDF document locally using the plaintext data key, and then immediately remove the plaintext data key from memory.

Answer

To implement client-side envelope encryption for files larger than

4\text{ KB}

, the developer should call GenerateDataKey to obtain a plaintext and encrypted data key, encrypt the file locally using the plaintext key, and then immediately destroy the plaintext key from memory. The encrypted data key is stored alongside the encrypted data.

The correct strategy involves calling the GenerateDataKey API operation to retrieve both a plaintext and an encrypted data key. The plaintext key is used to encrypt the

15\text{ MB}

document locally, and is then immediately deleted from memory to minimize exposure. The encrypted data key is stored with the ciphertext.

Step-by-Step Solution

Generate the data keys using AWS KMS.

The application calls the GenerateDataKey API operation, specifying the Customer Managed Key (CMK) ID, and receives a plaintext data key and an encrypted version of the data key.

This is required to obtain a unique key for symmetric local encryption while keeping the master CMK secure inside KMS.

Perform local client-side encryption.

The application uses the plaintext data key to encrypt the PDF document locally using a symmetric algorithm such as AES-256.

Because the PDF size (

15\text{ MB}

) exceeds the

4\text{ KB}

limit of direct KMS Encrypt API, the encryption must be performed client-side.

Secure memory and store the ciphertexts.

The plaintext data key is purged from memory, and the encrypted PDF document is stored alongside the encrypted data key.

This prevents memory exposure of the plaintext key and ensures the key can be recovered later by sending the encrypted data key back to KMS Decrypt.

Key Concept

AWS KMS client-side envelope encryption workflow

Question 300Question →

A developer is integrating a third-party SaaS monitoring platform with their company's AWS account. The SaaS platform runs in AWS Account $123456789012$ and needs to assume an IAM role in the developer's AWS Account $987654321098$ to retrieve CloudWatch metric data. To prevent the confused deputy problem, the SaaS platform requires the developer to configure an External ID of `SaaS-Monitor-99x`.

Which two actions must the developer perform to establish this cross-account access securely? (Select TWO.)

Select all that apply

Create an IAM role with a trust policy that allows the `sts:AssumeRole` action, designates the principal as `arn:aws:iam::123456789012:root`, and contains a condition block that checks if `sts:ExternalId` matches `SaaS-Monitor-99x`.

Attach an identity-based permissions policy to the IAM role that allows the `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions.

Create an IAM role with a trust policy that designates the principal as the AWS service principal `monitoring.amazonaws.com` and includes the External ID condition.

Configure a resource-based policy on the CloudWatch metric namespaces to allow the SaaS platform's IAM role to perform the `sts:AssumeRole` action.

Hardcode the AWS access keys of an IAM user created in the developer's account directly inside the SaaS platform's client configuration.

Show answer & explanation

Answer: Create an IAM role with a trust policy that allows the `sts:AssumeRole` action, designates the principal as `arn:aws:iam::123456789012:root`, and contains a condition block that checks if `sts:ExternalId` matches `SaaS-Monitor-99x`.; Attach an identity-based permissions policy to the IAM role that allows the `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions.

Answer

To securely configure cross-account access, the developer must create an IAM role with a trust policy that allows the `sts:AssumeRole` action for the external AWS account principal with a condition checking the External ID, and attach an identity-based permissions policy to the role that allows the necessary CloudWatch actions.

Establishing cross-account access for a third-party application requires creating an IAM role in the trusting account. The trust policy of this role must specify the external account ID as the principal and allow the `sts:AssumeRole` action. To prevent the confused deputy problem, a condition block must enforce the `sts:ExternalId` provided by the third-party. Additionally, the role itself must have an identity-based permissions policy attached to it that defines what AWS APIs the assumed role can call (specifically the CloudWatch metric retrieval APIs).

Step-by-Step Solution

Analyze the requirements for cross-account access and security constraints.

Identify that the third-party application operates in AWS Account

123456789012

, requires access to CloudWatch metrics in AWS Account

987654321098

, and requires the mitigation of the confused deputy problem using an External ID.

This establishes the parameters needed to configure the IAM role trust policy and permission policies.

Configure the trust policy of the IAM role to grant assume-role permission to the external account.

Define a trust policy allowing `sts:AssumeRole` with principal `arn:aws:iam::123456789012:root` and a condition block validating that `sts:ExternalId` is `SaaS-Monitor-99x`.

The trust policy establishes which entity can assume the role and validates the External ID to secure the delegation.

Configure the permissions policy of the IAM role to grant access to the required resources.

Define an identity-based policy allowing `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions, and attach it to the role.

The permissions policy defines the API operations the external entity is authorized to execute after assuming the role.

Key Concept

Establishing secure cross-account delegation via IAM roles, trust policies, and External IDs to prevent the confused deputy problem.

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