Security

390 questions

All types390 Multiple choice195 Multiple select195

A developer is building a multi-region active-active web application deployed across `us-east-1` and `us-west-2` using AWS Lambda. The application must securely retrieve a database credential that requires automatic rotation every $30$ days, as well as a region-specific database connection endpoint URL that is non-sensitive. The solution must minimize cross-region latency for credential retrieval and optimize cost. Which combination of services and configuration should the developer use to meet these requirements?

Store the database credential as a SecureString parameter in AWS Systems Manager Parameter Store in `us-east-1` with cross-region replication enabled. Store the connection endpoint URL in AWS Secrets Manager as a secret replicated to `us-west-2`.

Store the database credential in AWS Secrets Manager in `us-east-1` with automatic rotation configured, and replicate the secret to `us-west-2`. Store the non-sensitive connection endpoint URL in AWS Systems Manager Parameter Store as a regional String parameter in each region.

Store both the database credential and the connection endpoint URL in a single secret in AWS Secrets Manager in `us-east-1`, replicate it to `us-west-2`, and hardcode AWS IAM access keys in the Lambda function code to decrypt and retrieve the secret across regions.

Store the database credential in AWS Secrets Manager in `us-east-1` and write a custom Lambda function to copy the secret value to `us-west-2` after each rotation. Store the connection endpoint URL as a SecureString parameter in AWS Systems Manager Parameter Store in `us-east-1` and access it across regions.

Show answer & explanation

Answer: Store the database credential in AWS Secrets Manager in `us-east-1` with automatic rotation configured, and replicate the secret to `us-west-2`. Store the non-sensitive connection endpoint URL in AWS Systems Manager Parameter Store as a regional String parameter in each region.

Answer

Storing the database credential in AWS Secrets Manager meets the requirement for automatic rotation, and replication to the secondary region ensures low-latency local access. Utilizing Systems Manager Parameter Store for the connection endpoint is cost-effective, and storing it as a regional parameter in each region eliminates cross-region latency.

Step-by-Step Solution

Analyze credential requirements

Database credentials require security, automatic rotation, and cross-region availability with minimum latency.

AWS Secrets Manager is designed for managing sensitive secrets, supporting automated rotation and built-in cross-region replication.

Analyze non-sensitive configuration requirements

The connection endpoint is region-specific, non-sensitive, and needs to be retrieved cost-effectively.

AWS Systems Manager Parameter Store is ideal and cost-effective for storing non-sensitive config parameters, and storing them as regional parameters avoids cross-region latency.

Assess IAM and replication configurations

Identify the solution that avoids custom replication code and hardcoded credentials.

Native Secrets Manager replication handles cross-region secret syncing automatically, and using Lambda execution roles avoids hardcoding credentials.

Key Concept

Selecting the correct secret and parameter management service based on sensitivity, replication, rotation, and cost constraints.

Estimated Time:2m 0s

Question 22Question →

A developer is designing a serverless backend using AWS Lambda that processes sensitive customer records. Each record contains a profile payload averaging $15$ KB in size. The application must encrypt these payloads before storing them in an Amazon DynamoDB table. To meet strict performance and cost-efficiency requirements, the developer must implement client-side envelope encryption using a Customer Managed Key (CMK) managed by AWS KMS. Which of the following application workflows represents the most secure, cost-effective, and architecturally correct implementation of client-side envelope encryption?

Call the KMS Encrypt API directly, passing the

15

KB customer record as the plaintext payload. Store the returned ciphertext blob directly in the DynamoDB table.

Generate a symmetric key locally in the Lambda function, encrypt the customer record with it, and call the KMS Encrypt API to encrypt the local key. Store the encrypted record in DynamoDB, and store the encrypted symmetric key in AWS Secrets Manager using a unique secret per customer record.

Call the KMS GenerateDataKeyWithoutPlaintext API to retrieve an encrypted data key. Store this key in Systems Manager Parameter Store, and then call the KMS Decrypt API within the Lambda function to get the plaintext key to encrypt the payload.

Call the KMS GenerateDataKey API to obtain both a plaintext data key and an encrypted data key. Encrypt the customer record payload locally using the plaintext data key, delete the plaintext data key from memory, and store the encrypted payload and the encrypted data key together in the DynamoDB item.

Show answer & explanation

Answer: Call the KMS GenerateDataKey API to obtain both a plaintext data key and an encrypted data key. Encrypt the customer record payload locally using the plaintext data key, delete the plaintext data key from memory, and store the encrypted payload and the encrypted data key together in the DynamoDB item.

Answer

The correct workflow calls the KMS GenerateDataKey API to obtain both the plaintext data key and the encrypted data key in a single request. The plaintext key is used locally to encrypt the payload and then immediately cleared from memory, while the encrypted data key is stored directly alongside the encrypted payload in the DynamoDB table.

The correct workflow uses the GenerateDataKey API, which yields both a plaintext data key and an encrypted data key in a single request. The plaintext key is used locally to encrypt the payload and then immediately cleared from memory, while the encrypted data key is stored directly alongside the encrypted payload in the DynamoDB table. This implements client-side envelope encryption securely and efficiently, bypassing the

4

KB size limit of the Encrypt API without introducing unnecessary API calls or storage overhead.

Step-by-Step Solution

Evaluate the payload size and KMS constraints.

The record size of

15

KB exceeds the

4

KB direct encryption limit of the KMS Encrypt API, indicating envelope encryption is required.

To determine if direct KMS encryption is a viable or correct option.

Analyze key generation and retrieval efficiency.

Using GenerateDataKey provides both the plaintext key (for immediate encryption) and the ciphertext key in a single API call, whereas GenerateDataKeyWithoutPlaintext would require a second Decrypt API call.

To minimize KMS API costs and latency.

Determine the storage location for the encrypted data key.

The encrypted data key should be stored directly alongside the encrypted payload in the DynamoDB item, rather than external systems like Secrets Manager or Parameter Store.

To avoid external resource overhead, scale efficiently, and follow proper envelope encryption architecture.

Key Concept

AWS KMS Envelope Encryption Workflow

Estimated Time:3m 0s

Question 23Question →

A developer is designing a web application hosted on Amazon ECS behind an Application Load Balancer (ALB). The application requires users to authenticate via an Amazon Cognito User Pool. The ALB must authenticate incoming HTTP requests and forward the verified user identity claims to the backend ECS containers without requiring token validation logic inside the container code. Additionally, authenticated users must be able to upload profile images directly from their web client to their own folder within an Amazon S3 bucket. Which TWO configurations must the developer implement to meet these requirements?

Select all that apply

Add an authenticate action using Cognito to the Application Load Balancer listener rule, which verifies the user session and forwards user claims to the target group in the x-amzn-oidc-data header.

Configure a Cognito Identity Pool using the User Pool as an identity provider, and attach an IAM policy to the authenticated role that grants permission to upload to the resource path arn:aws:s3:::my-bucket/uploads/${cognito-identity.amazonaws.com:sub}/*.

Create an Amazon API Gateway Cognito Authorizer and associate it with the Application Load Balancer listener to authenticate incoming HTTP requests and populate the container headers.

Enable Cognito User Pool Hosted UI on the client, and configure the client to use the User Pool JSON Web Token (JWT) directly as the AWS Access Key and Secret Key to authenticate S3 PutObject calls.

Configure the Cognito User Pool to automatically assume an IAM role for each authenticated session and return temporary credentials directly in the ID token for S3 uploads.

Show answer & explanation

Answer: Add an authenticate action using Cognito to the Application Load Balancer listener rule, which verifies the user session and forwards user claims to the target group in the x-amzn-oidc-data header.; Configure a Cognito Identity Pool using the User Pool as an identity provider, and attach an IAM policy to the authenticated role that grants permission to upload to the resource path arn:aws:s3:::my-bucket/uploads/${cognito-identity.amazonaws.com:sub}/*.

Answer

To meet the requirements, the developer must configure an authenticate action using Cognito on the Application Load Balancer listener rule and set up a Cognito Identity Pool with the User Pool as an identity provider, associating it with an IAM policy that allows access to the user-specific S3 folder path using the identity sub variable.

To offload authentication, the Application Load Balancer listener rule must be configured with an authenticate action using Cognito. The ALB then verifies the tokens and forwards the user information to backend targets via the x-amzn-oidc-data header. For S3 access, the client requires temporary AWS credentials, which are obtained by creating a Cognito Identity Pool that uses the User Pool as an identity provider. The IAM policy attached to the authenticated role uses the ${cognito-identity.amazonaws.com:sub} policy variable to dynamically restrict access to the folder matching the user's Cognito identity ID.

Step-by-Step Solution

Identify that the Application Load Balancer needs to offload authentication.

Recognize that ALB supports a native integration with Cognito User Pools using listener rules with an authenticate action.

This avoids having to write custom token validation logic inside the ECS container application code.

Determine how the Application Load Balancer passes user identities.

The ALB passes user claims to the targets in HTTP headers such as x-amzn-oidc-data.

This allows the backend application to read claims such as the user ID or email without performing JWT signature checks.

Determine how the client can directly upload to S3.

Configure a Cognito Identity Pool to exchange the user pool tokens for temporary credentials.

Since S3 requires AWS IAM credentials and does not natively accept Cognito User Pool tokens, a Cognito Identity Pool must act as the credential provider.

Secure the S3 upload path using a policy variable.

Apply an IAM policy to the authenticated role that references ${cognito-identity.amazonaws.com:sub} to restrict each user to their own upload folder.

This dynamically resolves to the Cognito Identity ID of the authenticated user, achieving fine-grained access control.

Key Concept

Integrating Application Load Balancers with Cognito User Pools for authentication and using Cognito Identity Pools for temporary AWS credentials to access S3.

Estimated Time:2m 30s

Question 24Question →

A developer is configuring an application deployed on AWS App Runner in Account A. The application needs to retrieve database credentials to connect to an Amazon RDS database hosted in Account B. The database credentials must be rotated automatically every 30 days. Additionally, the application requires access to a public API endpoint URL that is non-sensitive and does not change. The developer wants to implement a secure, cost-effective parameter storage solution that allows cross-account access where necessary. Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Store the database credentials in AWS Secrets Manager in Account B, configure automatic rotation, and attach a resource-based policy to the secret that grants retrieve permissions to the App Runner instance role in Account A.

Store the public API endpoint URL in AWS Systems Manager Parameter Store in Account A as a Standard String parameter.

Store the database credentials in AWS Systems Manager Parameter Store in Account B as a SecureString parameter, and attach a resource-based policy to the parameter to grant access to Account A.

Store the public API endpoint URL in AWS Secrets Manager in Account A, and configure a custom Lambda function to rotate the URL daily to optimize storage costs.

Hardcode the database credentials in the application's configuration file within the App Runner container image, and restrict access to the container image using Amazon ECR repository policies.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager in Account B, configure automatic rotation, and attach a resource-based policy to the secret that grants retrieve permissions to the App Runner instance role in Account A.; Store the public API endpoint URL in AWS Systems Manager Parameter Store in Account A as a Standard String parameter.

Answer

Store the database credentials in AWS Secrets Manager in Account B with a resource-based policy granting access to Account A, and store the public API endpoint URL in AWS Systems Manager Parameter Store in Account A as a Standard String parameter.

The correct options are to store the database credentials in AWS Secrets Manager in Account B with a resource-based policy, and store the public API endpoint URL in AWS Systems Manager Parameter Store in Account A. AWS Secrets Manager supports automatic rotation and allows direct cross-account access via resource-based policies. Systems Manager Parameter Store is a cost-effective choice for non-sensitive, static configurations since standard parameters have no storage costs.

Step-by-Step Solution

Evaluate credential storage and sharing requirements.

Database credentials need to be stored in Account B, rotated every 30 days, and accessed by Account A. AWS Secrets Manager supports automatic rotation and resource-based policies, which allow cross-account sharing directly.

This satisfies the security requirement for automatic rotation and cross-account access.

Evaluate non-sensitive configuration storage.

The public API endpoint URL is non-sensitive and static. AWS Systems Manager Parameter Store Standard parameters are ideal because they are free and do not require rotation.

This satisfies the cost-effectiveness requirement.

Configure permissions for Account A's App Runner service.

Attach a resource-based policy to the Secrets Manager secret in Account B, specifying the App Runner instance role ARN from Account A as the principal with 'secretsmanager:GetSecretValue' permissions.

This enables secure retrieval of the credentials without hardcoding them or setting up complex cross-account IAM role assumption.

Key Concept

Secrets Manager vs Parameter Store feature comparison, including rotation, pricing, and cross-account capabilities.

Question 25Question →

An application running on an Amazon ECS container using AWS Fargate in Account $A$ ( $111122223333$ ) needs to write objects to an Amazon S3 bucket in Account $B$ ( $444455556666$ ). The application code uses the AWS SDK to call the AWS Security Token Service (STS) `AssumeRole` API to assume an IAM role named `CrossAccountS3Writer` in Account $B$ . However, the application receives an `AccessDenied` error on the `AssumeRole` call.

The ECS task definition is configured with the `taskRoleArn` parameter set to `arn:aws:iam::111122223333:role/ecsTaskRole` and the `executionRoleArn` parameter set to `arn:aws:iam::111122223333:role/ecsTaskExecutionRole`.

Which two actions are required to resolve this access issue and allow the application to write to the S3 bucket? (Select TWO.)

Select all that apply

Update the trust policy of the CrossAccountS3Writer role in Account B to trust the principal arn:aws:iam::111122223333:role/ecsTaskRole.

Update the trust policy of the CrossAccountS3Writer role in Account B to trust the principal arn:aws:iam::111122223333:role/ecsTaskExecutionRole.

Modify the application code to initialize the S3 client using the temporary security credentials returned by the AssumeRole call.

Hardcode a set of long-term IAM user access keys from Account B directly in the application configuration files to bypass STS.

Attach the AmazonS3FullAccess policy to the ecsTaskExecutionRole in Account A to authorize the S3 client.

Show answer & explanation

Answer: Update the trust policy of the CrossAccountS3Writer role in Account B to trust the principal arn:aws:iam::111122223333:role/ecsTaskRole.; Modify the application code to initialize the S3 client using the temporary security credentials returned by the AssumeRole call.

Answer

Update the trust policy of the CrossAccountS3Writer role in Account B to trust the principal arn:aws:iam::111122223333:role/ecsTaskRole, and modify the application code to initialize the S3 client using the temporary security credentials returned by the AssumeRole call.

The correct options involve updating the trust policy of the CrossAccountS3Writer role in Account B to trust the principal arn:aws:iam::111122223333:role/ecsTaskRole, and modifying the application code to initialize the S3 client using the temporary security credentials returned by the AssumeRole call. The application runs using the container task role (ecsTaskRole), so the trust relationship must target this role. The SDK must also explicitly use the temporary credentials retrieved from AWS STS to interact with the S3 bucket.

Step-by-Step Solution

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

The application code running inside the container uses the ECS Task Role for AWS API permissions. The ECS Task Execution Role is used only by the container agent for setup tasks.

This determines which role identity makes the sts:AssumeRole call.

Configure the trust relationship in Account B.

The role CrossAccountS3Writer in Account B must list the ECS Task Role (arn:aws:iam::111122223333:role/ecsTaskRole) as a trusted entity in its assume role policy document.

This permits the application running under the Task Role identity to assume the target role.

Utilize temporary credentials in the application.

Capture the AccessKeyId, SecretAccessKey, and SessionToken returned by the AssumeRole API call and pass them to the AWS SDK client builder.

The client must use these temporary credentials rather than its default credentials to access the cross-account S3 bucket.

Key Concept

Cross-account access and task-level role delegation in Amazon ECS

Question 26Question →

An AWS Lambda function is configured to run within private subnets of a custom VPC to securely query an Amazon Aurora database. The function also needs to retrieve database credentials stored as secure strings in AWS Systems Manager Parameter Store. During testing, the Lambda function times out when attempting to retrieve the parameters, though database connectivity works perfectly. A developer confirms that there is no NAT Gateway configured in the VPC.

Which configuration change will resolve the timeout issue while maintaining the current network architecture and database security?

Establish an interface VPC endpoint for Systems Manager (ssm) within the private subnets, associating a security group that allows inbound HTTPS traffic from the Lambda function's security group.

Attach an IAM policy to the Lambda execution role that grants ssm:GetParameters access, which enables the VPC-bound Lambda function to bypass the private subnet's routing table to reach the public Systems Manager service.

Update the trust relationship policy document of the Lambda execution role to allow the Systems Manager service principal (ssm.amazonaws.com) to assume the role and push parameter values.

Migrate the database credentials from Parameter Store to AWS Secrets Manager, as Systems Manager Parameter Store does not support private VPC endpoint connections or secure string encryption.

Show answer & explanation

Answer: Establish an interface VPC endpoint for Systems Manager (ssm) within the private subnets, associating a security group that allows inbound HTTPS traffic from the Lambda function's security group.

Answer

Establish an interface VPC endpoint for Systems Manager (ssm) within the private subnets, associating a security group that allows inbound HTTPS traffic from the Lambda function's security group.

The correct answer is to establish an interface VPC endpoint for Systems Manager (ssm) within the private subnets, associating a security group that allows inbound HTTPS traffic from the Lambda function's security group. Since the Lambda function is running in a private subnet with no NAT Gateway, it has no route to the public internet to reach the default Systems Manager endpoint. Creating an interface VPC endpoint places Elastic Network Interfaces (ENIs) with private IP addresses directly in the private subnets. The Lambda function can then access Parameter Store privately over port 443, provided the endpoint's security group allows inbound traffic from the Lambda function's security group.

Step-by-Step Solution

Analyze the network configuration of the Lambda function.

The Lambda function resides in a private subnet with no NAT Gateway, preventing access to public AWS service endpoints.

By default, resource-bound Lambda functions route traffic through the VPC's routing tables. Without a NAT Gateway or VPC endpoint, they cannot resolve or connect to public services.

Select the correct AWS PrivateLink service endpoint.

Identify that Systems Manager Parameter Store can be accessed privately via an interface VPC endpoint (ssm service).

Interface VPC endpoints provision Elastic Network Interfaces (ENIs) within the subnets, enabling private routing within the AWS network.

Configure the security groups for the VPC endpoint.

Associate a security group with the interface VPC endpoint that allows inbound HTTPS (port 443) traffic from the Lambda function's security group.

Since security groups are stateful and default to blocking all inbound traffic, the endpoint's security group must explicitly allow inbound requests from the client (Lambda).

Key Concept

VPC Interface Endpoints (AWS PrivateLink) and Security Group configurations for private AWS service integration.

Estimated Time:2m 30s

Question 27Question →

A serverless invoice processing application uses a Lambda function to query a relational database residing in a private subnet of a custom VPC. The function also needs to call a third-party billing service endpoint on the public internet.

Which of the following configurations are required to establish this network connectivity while maintaining secure access? (Select TWO.)

Select all that apply

Associate the Lambda function with the private subnets of the VPC, and route outbound internet traffic through a NAT Gateway located in a public subnet.

Configure a security group for the Lambda function that permits outbound traffic to the database port and to the internet on HTTPS port 443.

Place the Lambda function in a public subnet of the VPC and enable the default auto-assign public IP setting on the function configuration to reach the billing endpoint directly.

Modify the Lambda function's execution role trust policy to allow inbound database connections from the security group of the database.

Store the database credentials in Systems Manager Parameter Store and enable the native database credential rotation feature.

Show answer & explanation

Answer: Associate the Lambda function with the private subnets of the VPC, and route outbound internet traffic through a NAT Gateway located in a public subnet.; Configure a security group for the Lambda function that permits outbound traffic to the database port and to the internet on HTTPS port 443.

Answer

To establish network connectivity for the Lambda function, associate it with the private subnets of the VPC and route outbound internet traffic through a NAT Gateway in a public subnet. Additionally, configure the function's security group to allow outbound traffic to the database port and to the internet on HTTPS port 443.

The correct configurations are to associate the Lambda function with the private subnets of the VPC, routing outbound internet traffic through a NAT Gateway in a public subnet, and configure a security group for the Lambda function that permits outbound traffic to both the database port and HTTPS port 443. This setup ensures that the Lambda function can resolve and reach local resources like the database, while securely routing outbound internet traffic to the external endpoint via the NAT Gateway.

Step-by-Step Solution

Determine subnet placement for the Lambda function.

The Lambda function is associated with private subnets of the custom VPC to allow secure communication with the database.

Private resources should not be exposed to the public internet, and Lambda needs VPC network interfaces (ENIs) in the same subnets to reach the database.

Enable internet connectivity for the private subnets.

Configure a NAT Gateway in a public subnet, and add a route in the private subnets' route table pointing 0.0.0.0/0 traffic to the NAT Gateway.

Lambda functions in private subnets cannot reach the public internet directly; they require a NAT Gateway to translate private IPs to a public IP for internet access.

Configure the Lambda function's Security Group rules.

Add outbound rules allowing traffic to the database's Security Group on its port, and outbound HTTPS traffic to the internet.

Security groups are stateful and must explicitly allow the outbound traffic initiated by the Lambda function.

Key Concept

VPC Security for Lambda and Resource Access

Estimated Time:1m 30s

Question 28Question →

A developer is implementing a serverless analytics dashboard. Users must register and log in to the dashboard, which is built as a single-page application (SPA). The application needs to call secure endpoints on Amazon API Gateway to fetch user profile data. Additionally, the client-side application must publish telemetry logs directly to an Amazon Kinesis Data Stream for real-time analysis. Which TWO steps should the developer perform to meet these security requirements with the least operational overhead?

Select all that apply

Configure a Cognito User Pool to manage user authentication, and create a Cognito User Pool Authorizer in API Gateway to validate the ID tokens sent in the HTTP request headers.

Create a Cognito Identity Pool that uses the User Pool as an identity provider, and assign an authenticated IAM role with permissions to write to the Kinesis Data Stream.

Develop a custom Lambda Authorizer in API Gateway that parses the Cognito User Pool access token, performs manual verification against the public JWKS endpoint, and generates an IAM policy for the REST API.

Configure API Gateway to use AWS_IAM authorization, and utilize the Cognito User Pool directly to issue temporary IAM credentials for signing requests to the REST API.

Integrate the Kinesis Data Stream with the Cognito User Pool, configuring a User Pool client-side policy to grant stream write permissions to authenticated users.

Show answer & explanation

Answer: Configure a Cognito User Pool to manage user authentication, and create a Cognito User Pool Authorizer in API Gateway to validate the ID tokens sent in the HTTP request headers.; Create a Cognito Identity Pool that uses the User Pool as an identity provider, and assign an authenticated IAM role with permissions to write to the Kinesis Data Stream.

Answer

To meet the requirements with the least operational overhead, the developer should configure a Cognito User Pool with a Cognito Authorizer in API Gateway to secure the API endpoints, and use a Cognito Identity Pool linked to the User Pool to provide temporary IAM credentials that grant write permissions to the Kinesis Data Stream.

The correct solution uses the native features of AWS services to minimize custom code. By configuring a Cognito User Pool, the developer establishes a user directory. Setting up a Cognito User Pool Authorizer on API Gateway allows the platform to natively inspect and validate the ID tokens. To interact with Amazon Kinesis directly from the client, the developer uses a Cognito Identity Pool to trade the User Pool's JWTs for temporary, restricted AWS IAM credentials, which contain permission to execute the write action on the stream.

Step-by-Step Solution

Configure a Cognito User Pool to provide user authentication and management for the single-page application.

The application can authenticate users and receive JSON Web Tokens (ID, Access, and Refresh tokens).

User Pools act as the primary user directory and handle user registration and login flows.

Create a Cognito User Pool Authorizer on the API Gateway REST API and configure it to validate the incoming ID tokens in the Authorization header.

API Gateway automatically validates the signature, expiration, and audience of the JWTs without requiring custom Lambda code.

This utilizes the native API Gateway integration to minimize operational overhead and custom code.

Set up a Cognito Identity Pool (Federated Identities) and configure the Cognito User Pool as an authentication provider.

The identity pool can federate users authenticated by the user pool and exchange their JWTs for temporary AWS IAM credentials.

Identity Pools are designed to authorize access to AWS resources by issuing temporary AWS credentials.

Assign an IAM role to authenticated users in the Identity Pool with a policy that allows the 'kinesis:PutRecord' action on the target stream.

Authenticated users obtain temporary AWS credentials with permissions to publish telemetry logs directly from the browser SDK.

This establishes fine-grained authorization to access AWS resources directly from client-side code.

Key Concept

Integration of Cognito User Pools for user directory authentication, Cognito Identity Pools for authorizing direct AWS resource access (such as S3, DynamoDB, or Kinesis) via temporary credentials, and API Gateway Cognito Authorizers for securing REST endpoints.

Question 29Question →

An enterprise web application requires federated authentication via an external SAML 2.0 Identity Provider (IdP). Once authenticated, users must be able to download files directly from an Amazon S3 bucket. Access must be restricted such that users can only download objects from an S3 prefix that matches their department name (e.g., `company-data/hr/*` for the 'hr' department). The department name is supplied as a custom SAML assertion claim named `department`.

Which configuration should the developer implement to meet these requirements with the least administrative and coding overhead?

Configure an Amazon Cognito Identity Pool with the SAML IdP. Set up Attribute Mapping to map the SAML `department` claim to the principal tag `department`. In the IAM policy attached to the authenticated role, grant `s3:GetObject` permission for the resource `arn:aws:s3:::company-data/${aws:PrincipalTag/department}/*`.

Configure an Amazon Cognito User Pool with the SAML IdP. Create a Post Authentication AWS Lambda trigger that checks the user's `department` attribute, generates temporary AWS credentials with a dynamic policy, and stores them in the User Pool's custom user attributes for the client to retrieve.

Configure an Amazon API Gateway endpoint with a custom Lambda Authorizer. Send the SAML assertion to API Gateway, and have the Lambda Authorizer validate it, perform an AWS STS `AssumeRole` call to get temporary credentials for the specific department prefix, and return the credentials inside the authorizer's output context.

Configure an Amazon Cognito Identity Pool with the SAML IdP. Create separate IAM roles for each department with corresponding S3 bucket policies. Use a custom Lambda function to update the Identity Pool's role mapping rules daily to map each user's email address to their specific department's IAM role.

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool with the SAML IdP. Set up Attribute Mapping to map the SAML `department` claim to the principal tag `department`. In the IAM policy attached to the authenticated role, grant `s3:GetObject` permission for the resource `arn:aws:s3:::company-data/${aws:PrincipalTag/department}/*`.

Answer

Configure an Amazon Cognito Identity Pool with the SAML IdP, map the SAML attribute to the principal tag, and reference the tag in the IAM policy using a policy variable.

The correct option maps the SAML assertion claim to a principal tag in the Cognito Identity Pool configuration. This allows the IAM role to use Attribute-Based Access Control (ABAC) and dynamic policy variables (`${aws:PrincipalTag/department}`) to restrict access to department-specific prefixes in S3 with a single IAM role, minimizing overhead.

Step-by-Step Solution

Configure the Identity Pool with the SAML Identity Provider.

This enables federation, allowing Cognito to accept SAML assertions from the external IdP.

Cognito Identity Pools broker access to AWS resources by exchanging external identity tokens for temporary AWS credentials.

Set up Attribute Mapping in the Identity Pool.

The `department` claim from the SAML assertion is mapped to the principal tag `department` in the AWS security token context.

This enables Attribute-Based Access Control (ABAC) by attaching the department tag to the assumed IAM role session.

Reference the principal tag in the IAM role's permission policy.

A dynamic resource ARN `arn:aws:s3:::company-data/${aws:PrincipalTag/department}/*` is used in the policy.

This allows a single IAM role to scale across multiple departments without requiring manual configuration changes or multiple roles.

Key Concept

Attribute-Based Access Control (ABAC) with Amazon Cognito Identity Pools and SAML federation

Estimated Time:2m 0s

Question 30Question →

An organization hosts a critical multi-region web application on Amazon ECS Fargate across the us-east-1 and us-west-2 Regions. The application connects to an Amazon Aurora Global Database. A developer needs to design a secure solution to manage the database password. The password must be rotated every 30 days, and ECS tasks in both Regions must be able to retrieve the credentials locally with minimal latency. Which solution meets these requirements with the least operational overhead?

Store the database credentials as a SecureString parameter in AWS Systems Manager Parameter Store in us-east-1 and us-west-2. Configure an AWS Lambda function triggered by an Amazon EventBridge scheduled rule to update the database password, update the parameter in the primary Region, and copy it to the secondary Region.

Store the database credentials in AWS Secrets Manager in the primary Region. In the ECS task application code, initialize the AWS SDK client using hardcoded IAM user access keys to authenticate and retrieve the secret value from the primary Region during application startup.

Store the database credentials in AWS Secrets Manager in the primary Region, configure automatic rotation using the built-in RDS rotation template, and replicate the secret to the secondary Region. In the ECS task definition, assign the permission to retrieve the secret to the ECS Task Role, and reference the local Secrets Manager ARN in the container definition's environment variables (valueFrom).

Store the database credentials in AWS Secrets Manager in the primary Region, configure automatic rotation using the built-in RDS rotation template, and replicate the secret to the secondary Region. In the ECS task definition, assign the permission to retrieve the secret to the ECS Task Execution Role, and reference the local Secrets Manager ARN in the container definition's environment variables (valueFrom).

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager in the primary Region, configure automatic rotation using the built-in RDS rotation template, and replicate the secret to the secondary Region. In the ECS task definition, assign the permission to retrieve the secret to the ECS Task Execution Role, and reference the local Secrets Manager ARN in the container definition's environment variables (valueFrom).

Answer

Store the database credentials in AWS Secrets Manager in the primary Region, configure automatic rotation using the built-in RDS rotation template, and replicate the secret to the secondary Region. In the ECS task definition, assign the permission to retrieve the secret to the ECS Task Execution Role, and reference the local Secrets Manager ARN in the container definition's environment variables (valueFrom).

The correct solution leverages AWS Secrets Manager's native support for automatic rotation of database credentials using built-in AWS Lambda rotation templates. Replicating the secret to the secondary Region ensures that ECS Fargate tasks can retrieve the secret locally, minimizing latency. To inject secrets as environment variables during task startup, the ECS container agent retrieves the secret, which requires the necessary permissions to be attached to the ECS Task Execution Role, rather than the ECS Task Role.

Step-by-Step Solution

Identify the service that natively supports automatic credential rotation and multi-region replication.

AWS Secrets Manager supports automatic rotation for Amazon RDS/Aurora and cross-region replication, whereas Parameter Store lacks these native features.

Using Secrets Manager minimizes custom replication and rotation scripts, satisfying the low operational overhead requirement.

Determine how ECS tasks retrieve secrets during container startup.

ECS allows injecting secrets directly into environment variables using the valueFrom parameter in the container definition.

Injecting secrets directly prevents them from being exposed in the task definition plaintext or application logs.

Identify the correct IAM role needed for secret injection.

The ECS Task Execution Role is used by the ECS container agent to pull images and retrieve secrets, while the ECS Task Role is for application code API calls.

Granting permission to the Task Execution Role ensures the ECS agent can retrieve the secret from Secrets Manager to spin up the container successfully.

Key Concept

Database credential rotation, multi-region replication, and ECS task execution role permissions for secrets injection.

Estimated Time:2m 30s

Question 31Question →

A logistics company is designing a REST API in Amazon API Gateway to allow partner clients to retrieve shipment data. Partners authenticate against an external OAuth 2.0 Identity Provider (IdP) and receive a JWT access token containing custom scopes like `shipments:read`. The developer wants to authenticate the tokens and enforce access control using these custom scopes at the API Gateway level with minimal custom code. Which two configuration steps should the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Create and configure an Amazon Cognito User Pool with the external IdP as a federated provider, then create a Cognito User Pool authorizer in API Gateway.

Associate the Cognito authorizer with the API method, and specify the required custom scopes in the OAuth Scopes field of the Method Request configuration.

Create an Amazon Cognito Identity Pool to authenticate the partners, exchange the JWT for temporary AWS credentials, and configure an IAM authorizer on the API methods.

Create a custom Lambda authorizer that calls the Cognito Identity Pool API to validate the custom scopes and return an IAM policy.

Configure the API Gateway integration type as a Lambda proxy integration to automatically forward the JWT payload, allowing the backend Lambda function to perform signature verification.

Show answer & explanation

Answer: Create and configure an Amazon Cognito User Pool with the external IdP as a federated provider, then create a Cognito User Pool authorizer in API Gateway.; Associate the Cognito authorizer with the API method, and specify the required custom scopes in the OAuth Scopes field of the Method Request configuration.

Answer

To secure the REST API with minimal custom code, the developer should create and configure an Amazon Cognito User Pool federated with the external IdP, set up a Cognito User Pool authorizer, and then specify the required custom scopes in the Method Request configuration.

The correct options involve configuring an Amazon Cognito User Pool federated with the external Identity Provider and creating a Cognito User Pool authorizer. This allows API Gateway to handle JWT signature validation natively. By configuring the method request with the required OAuth scopes, API Gateway natively verifies that the token contains the matching scope claims, preventing unauthorized traffic from reaching the backend with zero custom code.

Step-by-Step Solution

Integrate the external Identity Provider with Amazon Cognito.

Amazon Cognito User Pool is created and configured with the external IdP as a federated provider, allowing API Gateway to recognize the external tokens via a Cognito User Pool authorizer.

This establishes trust and allows API Gateway to natively validate the JWT token structure and signature without custom validation code.

Configure the Cognito User Pool authorizer in API Gateway.

A Cognito User Pool authorizer is added to the API Gateway REST API and linked to the created Cognito User Pool.

This registers the authorizer with the API Gateway deployment so it can be associated with individual methods.

Enable scope validation on the API methods.

The Cognito authorizer is associated with the target method, and custom scopes (such as 'shipments:read') are added to the OAuth Scopes field in the Method Request configuration.

This configures API Gateway to automatically inspect the incoming token for the required scopes and reject unauthorized requests before they reach the backend.

Key Concept

API Gateway integration with Amazon Cognito User Pools for federated authentication and native OAuth scope validation.

Estimated Time:1m 30s

Question 32Question →

A developer is building a high-security microservice that processes sensitive transaction payloads. The application uses client-side envelope encryption with an AWS KMS customer managed key. The developer must ensure that:

1. The encrypted transaction payloads are cryptographically bound to a specific $TransactionID$ and $VaultRegion$ to prevent decryption under any other context.
2. All cryptographic operations are logged in AWS CloudTrail with these context details for compliance auditing.

Which two actions must the developer take to implement this encryption workflow?

Select all that apply

Call the GenerateDataKey API with the EncryptionContext parameter containing the TransactionID and VaultRegion as key-value pairs.

Pass the identical EncryptionContext key-value pairs in the Decrypt API call when decrypting the encrypted data key.

Call the GenerateDataKey API without a context, and pass the TransactionID and VaultRegion only in the Decrypt API call to filter the decryption logs.

Save the TransactionID and VaultRegion as secure string parameters in AWS Systems Manager Parameter Store to automatically manage the decryption context.

Call the Encrypt API directly for the transaction payload and pass the EncryptionContext in the GrantTokens parameter to bypass policy checks.

Show answer & explanation

Answer: Call the GenerateDataKey API with the EncryptionContext parameter containing the TransactionID and VaultRegion as key-value pairs.; Pass the identical EncryptionContext key-value pairs in the Decrypt API call when decrypting the encrypted data key.

Answer

To implement this client-side envelope encryption workflow, the developer must call the GenerateDataKey API with the EncryptionContext parameter containing the TransactionID and VaultRegion as key-value pairs, and pass the identical EncryptionContext key-value pairs in the Decrypt API call when decrypting the encrypted data key.

The correct options describe the standard AWS KMS envelope encryption workflow using Encryption Context. The EncryptionContext parameter in the GenerateDataKey API call cryptographically binds the key-value pair metadata (TransactionID and VaultRegion) to the encrypted data key. During decryption, passing the identical EncryptionContext map is mandatory; otherwise, AWS KMS cannot decrypt the data key. Both calls are logged in AWS CloudTrail with the encryption context in plaintext.

Step-by-Step Solution

Generate a unique data key with context.

The application calls the GenerateDataKey API on AWS KMS, passing the Customer Managed Key ARN and an EncryptionContext map containing the TransactionID and VaultRegion.

This cryptographically binds the metadata to the encrypted version of the data key and records it in AWS CloudTrail.

Encrypt the payload locally.

The application uses the plaintext data key to encrypt the transaction payload locally, then discards the plaintext data key from memory.

This completes the client-side envelope encryption process safely without exposing the plaintext key.

Decrypt the data key using the identical context.

When decrypting the payload, the application calls the Decrypt API, passing the ciphertext data key and the identical EncryptionContext map.

AWS KMS validates the context against the cryptographic signature in the ciphertext. If they match, it returns the plaintext data key to decrypt the payload.

Key Concept

AWS KMS Encryption Context in Envelope Encryption

Question 33Question →

A developer is implementing Attribute-Based Access Control (ABAC) in an AWS account. The developer configures an IAM role named `ProjectRunnerRole` with the following trust policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/AppDeveloper"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Phoenix",
"aws:RequestTag/CostCenter": "1001"
}
}
}
]
}

An IAM user named `AppDeveloper` in the same account attempts to assume this role by calling the `sts:AssumeRole` API and passing the session tags `Project=Phoenix` and `CostCenter=1001`. The request fails with an `AccessDenied` error. Which TWO of the following configurations are required to resolve this error and successfully allow the user to assume the role?

Select all that apply

Update the Action element of the trust policy in ProjectRunnerRole to allow both sts:AssumeRole and sts:TagSession.

Attach an identity-based policy to the AppDeveloper user that grants both sts:AssumeRole and sts:TagSession permissions targeting the ARN of ProjectRunnerRole.

Modify the Principal element in the trust policy of ProjectRunnerRole to specify the service principal sts.amazonaws.com.

Change the condition keys in the trust policy from aws:RequestTag/Project and aws:RequestTag/CostCenter to aws:PrincipalTag/Project and aws:PrincipalTag/CostCenter.

Configure the application to authenticate the SDK client using hardcoded temporary access keys and session tokens belonging to ProjectRunnerRole.

Show answer & explanation

Answer: Update the Action element of the trust policy in ProjectRunnerRole to allow both sts:AssumeRole and sts:TagSession.; Attach an identity-based policy to the AppDeveloper user that grants both sts:AssumeRole and sts:TagSession permissions targeting the ARN of ProjectRunnerRole.

Answer

To allow the IAM user to assume the role with session tags, the trust policy of the role must include both the sts:AssumeRole and sts:TagSession actions, and the identity-based policy attached to the user must grant permissions for both actions targeting the role's ARN.

To successfully assume an IAM role while passing session tags, both the trust policy of the target role and the identity-based policy of the calling principal must explicitly allow the sts:TagSession action alongside sts:AssumeRole. The trust policy in the scenario only permits sts:AssumeRole, which causes the API call to fail with AccessDenied when tags are passed. Therefore, updating the trust policy to include sts:TagSession and attaching an identity-based policy to the caller with both permissions solves the issue.

Step-by-Step Solution

Analyze the error message and the trust policy structure.

The error is AccessDenied during sts:AssumeRole while trying to pass session tags, and the trust policy only permits sts:AssumeRole.

AWS STS requires explicit permission for the sts:TagSession action in the trust policy to allow callers to pass session tags.

Evaluate the caller's permissions.

The caller (AppDeveloper) must also have permissions to perform both sts:AssumeRole and sts:TagSession in their identity-based policy.

AWS security requires authorization on both the resource (the role trust policy) and the caller (identity-based policy) for session tag operations.

Differentiate between aws:RequestTag and aws:PrincipalTag.

Confirm that aws:RequestTag is the correct key because tags are passed in the request, not already attached to the user.

aws:RequestTag evaluates the tags that are passed in the API call request, whereas aws:PrincipalTag evaluates the tags attached to the calling principal.

Key Concept

IAM Session Tags and sts:TagSession Authorization

Question 34Question →

An enterprise web application requires external partner users to authenticate using their corporate SAML Identity Provider (IdP). Once authenticated, users must be able to invoke private API endpoints hosted on Amazon API Gateway and upload large log files directly to a specific folder in an Amazon S3 bucket. The S3 folder path must be isolated per partner organization based on a SAML assertion attribute named `partnerId`.

Which combination of configuration steps should a developer implement to meet these requirements with the least operational overhead? (Select TWO.)

Select all that apply

Configure an Amazon Cognito User Pool to federate with the corporate SAML IdP, mapping the SAML partnerId assertion to a custom attribute. Set up a Cognito User Pool Authorizer on the API Gateway REST API to secure the private endpoints.

Establish an Amazon Cognito Identity Pool using the User Pool as an identity provider. Use the 'Attributes for access control' feature to map the custom partnerId attribute to a principal tag, and apply an IAM policy on the authenticated role that restricts S3 access using a ${aws:PrincipalTag/partnerId} policy variable.

Configure an Amazon Cognito User Pool to federate with the corporate SAML IdP. Generate AWS temporary credentials by passing the User Pool access token directly to the S3 AssumeRoleWithWebIdentity API call, using the token's payload to construct the S3 folder prefix in the application code.

Create a Cognito Identity Pool that federates directly with the corporate SAML IdP. Configure a custom Lambda Authorizer on API Gateway that fetches the SAML assertion from the client header, validates the XML signature against the IdP's metadata endpoint, and generates an IAM policy for API Gateway.

Configure an Amazon Cognito User Pool to federate with the SAML IdP. Use a custom Lambda Authorizer on API Gateway to validate the ID token, and have the Lambda function exchange the token for temporary AWS credentials using the STS AssumeRole API before returning them to the client for S3 access.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool to federate with the corporate SAML IdP, mapping the SAML partnerId assertion to a custom attribute. Set up a Cognito User Pool Authorizer on the API Gateway REST API to secure the private endpoints.; Establish an Amazon Cognito Identity Pool using the User Pool as an identity provider. Use the 'Attributes for access control' feature to map the custom partnerId attribute to a principal tag, and apply an IAM policy on the authenticated role that restricts S3 access using a ${aws:PrincipalTag/partnerId} policy variable.

Answer

Configure an Amazon Cognito User Pool federated with the SAML IdP using a Cognito User Pool Authorizer on API Gateway, and use an Amazon Cognito Identity Pool with Attributes for access control to map the custom partnerId attribute to a principal tag for dynamic S3 path restriction using the policy variable.

The correct solution involves combining Cognito User Pools and Cognito Identity Pools. The User Pool handles SAML federation and custom attribute mapping, allowing API Gateway to natively authorize requests using a Cognito User Pool Authorizer. The Identity Pool exchanges the User Pool tokens for temporary AWS credentials, utilizing the 'Attributes for access control' (ABAC) feature to securely map custom attributes to session principal tags. This lets a single IAM policy restrict S3 bucket paths dynamically using the policy variable, eliminating custom middleware.

Step-by-Step Solution

Set up authentication federation using an Amazon Cognito User Pool mapped to the SAML Identity Provider, mapping incoming assertions like partnerId to custom attributes.

Users can authenticate via their corporate credentials, receiving Cognito ID and access JWTs containing their partnerId custom attribute.

Provides a managed directory and token-based identity mechanism without managing credentials.

Configure the API Gateway endpoints with an Amazon Cognito User Pool Authorizer that validates the incoming ID/Access token directly.

Requests containing valid tokens are permitted to invoke the backend service, while invalid requests are blocked at the API Gateway layer without invoking backend compute.

Minimizes development effort and compute costs by avoiding custom Lambda validation logic.

Create an Amazon Cognito Identity Pool, configure the User Pool as the authentication provider, and enable 'Attributes for access control' mapping the custom partnerId attribute to the principal tag.

The identity pool returns temporary AWS credentials with the principal tag attached to the IAM session.

Allows AWS IAM to evaluate permissions dynamically based on user-specific attributes.

Write an IAM policy for the authenticated role referencing the dynamic principal tag variable inside the S3 resource ARN.

A single policy permits uploads only to the folder corresponding to the user's partner ID.

Enforces fine-grained authorization to S3 dynamically with zero-code IAM policy logic.

Key Concept

Federating identities with Cognito User Pools and Identity Pools, using User Pools for API Gateway authorization and Identity Pools with attribute-based access control (ABAC) for temporary AWS credentials.

Question 35Question →

A developer is writing a backup utility that must encrypt database export files, each approximately $500\text{ MB}$ in size, before uploading them to an Amazon S3 bucket. The utility must use client-side envelope encryption with an AWS Key Management Service (AWS KMS) customer managed key.

Which two steps must the developer implement in the utility's code to encrypt the files securely and prepare them for storage?

Select all that apply

Call the AWS KMS GenerateDataKey API operation by passing the customer managed key identifier to obtain both a plaintext data key and a ciphertext data key.

Encrypt the database export file locally using the plaintext data key with a symmetric encryption algorithm, and then delete the plaintext data key from memory.

Call the AWS KMS Encrypt API operation by passing the database export file and the customer managed key identifier to obtain the encrypted ciphertext.

Call the AWS KMS GenerateDataKeyWithoutPlaintext API operation to obtain the encrypted data key, and then call the AWS KMS Decrypt API operation to retrieve the plaintext data key.

Store the plaintext data key in AWS Systems Manager Parameter Store as a SecureString parameter, and upload the encrypted database export file to the S3 bucket.

Show answer & explanation

Answer: Call the AWS KMS GenerateDataKey API operation by passing the customer managed key identifier to obtain both a plaintext data key and a ciphertext data key.; Encrypt the database export file locally using the plaintext data key with a symmetric encryption algorithm, and then delete the plaintext data key from memory.

Answer

Call the AWS KMS GenerateDataKey API operation by passing the customer managed key identifier to obtain both a plaintext data key and a ciphertext data key, and encrypt the database export file locally using the plaintext data key with a symmetric encryption algorithm, and then delete the plaintext data key from memory.

The correct answer combines calling the AWS KMS GenerateDataKey API to retrieve both key formats and performing the symmetric encryption locally before deleting the plaintext key from memory. Since the database export file is

500\text{ MB}

, direct encryption via the AWS KMS Encrypt API is impossible due to its

4\text{ KB}

payload limit. Locally encrypting with the plaintext data key and then immediately destroying it ensures maximum security.

Step-by-Step Solution

Generate a unique data key pair using AWS KMS.

Obtained a plaintext data key and a ciphertext data key via the GenerateDataKey API call.

The file size (

500\text{ MB}

) exceeds the direct encryption payload limit of

4\text{ KB}

for AWS KMS, so envelope encryption must be initiated.

Encrypt the file locally.

The file is encrypted using a symmetric cipher (such as AES-GCM) with the plaintext data key.

Envelope encryption requires the actual data to be encrypted client-side using the generated plaintext data key.

Secure the encryption keys.

The plaintext data key is discarded from memory, and the ciphertext data key is saved for future decryption.

This prevents exposure of the plaintext key and allows future decryption by sending the ciphertext data key back to AWS KMS.

Key Concept

AWS KMS client-side envelope encryption workflow and payload limits

Question 36Question →

A developer has configured an AWS Lambda function in Account A ( $111111111111$ ) to retrieve configuration files from a secured Amazon S3 bucket in the same account. The developer created an IAM role named `LambdaS3ReaderRole` with the following trust policy and permissions policy, and assigned it as the function's execution role:

Trust Policy:

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

Permissions Policy:

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

During local testing, the developer used their own IAM user access keys, which had administrative privileges. Before deploying to the Lambda environment, the developer committed the following code:

python
import boto3
import os

def lambda_handler(event, context):
# Initialize the S3 client
s3_client = boto3.client(
's3',
aws_access_key_id=os.environ.get('AWS_ACCESS_KEY_ID', 'AKIAIOSFODNN7EXAMPLE'),
aws_secret_access_key=os.environ.get('AWS_SECRET_ACCESS_KEY', 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY')
)

try:
response = s3_client.get_object(
Bucket='app-config-bucket-1111',
Key='settings.json'
)
return response['Body'].read().decode('utf-8')
except Exception as e:
print(f"Error: {str(e)}")
raise e

After deploying the Lambda function, the execution fails with an `AccessDenied` error when trying to retrieve the S3 object. The developer verifies that the environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are not set in the Lambda function's configuration.

Which of the following options explains the cause of this authorization failure, and describes the correct way to resolve it?

The SDK client is initialized with the fallback dummy credentials because the environment variables are not set. This explicit credential initialization bypasses the default credential provider chain, preventing the Lambda function from using the temporary security credentials provided by its execution role. To resolve this, initialize the client using `boto3.client('s3')` without passing explicit credentials.

The trust policy on `LambdaS3ReaderRole` is misconfigured because it designates the Lambda service principal (`lambda.amazonaws.com`) as the trusted entity instead of the Amazon S3 service principal (`s3.amazonaws.com`). To resolve this, update the trust policy's principal to trust the Amazon S3 service so that the role can access S3 buckets.

The Lambda function requires the execution role's temporary access keys to be manually passed. To resolve this, configure the Lambda function's environment variables `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` by referencing the `LambdaS3ReaderRole` credentials in the Lambda function settings.

The permissions policy attached to `LambdaS3ReaderRole` is missing the `sts:AssumeRole` action. To resolve this, add a statement to the permissions policy that explicitly allows the role to perform `sts:AssumeRole` on itself, which is required for the function to generate the temporary credentials needed for S3 access.

Show answer & explanation

Answer: The SDK client is initialized with the fallback dummy credentials because the environment variables are not set. This explicit credential initialization bypasses the default credential provider chain, preventing the Lambda function from using the temporary security credentials provided by its execution role. To resolve this, initialize the client using `boto3.client('s3')` without passing explicit credentials.

Answer

The authorization failure is caused by the explicit initialization of the boto3 client with fallback dummy credentials, which bypasses the default credential provider chain. To resolve this, initialize the client using `boto3.client('s3')` without passing explicit credentials.

The correct answer explains that explicitly initializing the SDK client with credentials (in this case, fallback dummy values because the environment variables were unset) bypasses the default credential provider chain. In a Lambda environment, the execution role's temporary credentials are automatically made available to the SDK via standard environment variables. By removing the explicit credential parameters, the SDK successfully falls back to the default provider chain and automatically retrieves the correct execution role credentials.

Step-by-Step Solution

Analyze the boto3 client initialization code.

The code uses `os.environ.get()` with fallback hardcoded dummy credentials ('AKIAIOSFODNN7EXAMPLE' and 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY') for the `aws_access_key_id` and `aws_secret_access_key` arguments.

To determine how the SDK is obtaining authentication credentials.

Evaluate the execution environment state.

The `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables are not set in the Lambda configuration, causing the SDK to use the fallback dummy strings.

To verify if the environment overrides the hardcoded fallback credentials.

Understand the default credential provider chain behavior in AWS Lambda.

Explicitly passing credentials to `boto3.client()` overrides the default provider chain. Normally, the SDK would automatically resolve the execution role's temporary credentials injected by the Lambda service.

To identify why the function is not using the assigned `LambdaS3ReaderRole` permissions.

Apply the resolution by removing the hardcoded fallback parameters.

Initializing the client as `boto3.client('s3')` allows the default credential provider chain to retrieve the role's temporary credentials, resolving the AccessDenied error.

To restore standard IAM role execution credentials usage.

Key Concept

AWS SDK Default Credential Provider Chain and Lambda Execution Roles

Estimated Time:3m 0s

Question 37Question →

A developer is implementing a custom backend service hosted on Amazon ECS that processes requests from a mobile application. The mobile application authenticates users via an Amazon Cognito User Pool and includes the obtained JSON Web Token (JWT) in the Authorization header of each API request. To minimize latency, the developer wants the backend service to validate these tokens locally rather than making network calls to Amazon Cognito for every incoming request.

Which process should the developer implement to validate the incoming JWTs?

Download and cache the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint, match the token's key ID (kid) to a key in the JWKS, verify the cryptographic signature using the corresponding public key, and validate the token's expiration, audience, and issuer claims.

Exchange the User Pool JWT for temporary AWS credentials by calling the Cognito Identity Pools API, and then check the token's validity using the AWS Security Token Service (STS).

Configure a custom API Gateway Lambda Authorizer to intercept each ECS request, forward the JWT to the Cognito User Pool GetUser endpoint, and let Cognito validate the token on behalf of the backend service.

Use an Amazon Cognito Identity Pool to obtain a symmetric AWS Key Management Service (AWS KMS) data key, decrypt the JWT payload on the backend service, and inspect the decrypted claims.

Show answer & explanation

Answer: Download and cache the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint, match the token's key ID (kid) to a key in the JWKS, verify the cryptographic signature using the corresponding public key, and validate the token's expiration, audience, and issuer claims.

Answer

The correct process is to download and cache the JSON Web Key Set (JWKS) from the Cognito User Pool endpoint, locate the matching public key using the key ID (kid) header, verify the cryptographic signature, and validate the claims locally (expiration, audience, and issuer).

The correct approach is to retrieve the public JSON Web Key Set (JWKS) from the Cognito User Pool's public URI and cache it. When a request arrives, the backend service parses the JWT header to find the key ID (kid), verifies the cryptographic signature with the matching public key, and then verifies the claims locally (expiration, audience, and issuer). This avoids any network call during request processing.

Step-by-Step Solution

Retrieve the User Pool's JSON Web Key Set (JWKS) from the well-known public URI.

A collection of public keys that Cognito uses to sign JSON Web Tokens.

The backend service needs the public keys to cryptographically verify the token's signature.

Decode the token header to locate the Key ID (kid) and match it against the JWKS.

Identifies the correct public key to use for signature verification.

Cognito rotates signing keys, so the client must match the key ID from the token with the correct public key.

Verify the signature and validate claims (expiration, audience, issuer) locally.

Confirmed authenticity and validity of the user's session without making external network calls.

Verifying the claims ensures the token is not expired, was issued by the expected User Pool, and belongs to the correct App Client.

Key Concept

Local validation of Amazon Cognito User Pool JWTs

Estimated Time:1m 30s

Question 38Question →

A developer is building a serverless web application where users sign in using their email and password. Once authenticated, the application must allow users to upload files to a private Amazon S3 bucket and make requests to a backend API hosted on Amazon API Gateway. The developer wants to leverage Amazon Cognito for authentication and authorization. Which TWO configuration steps should the developer perform to meet these requirements with the least operational overhead?

Select all that apply

Configure an Amazon Cognito User Pool to handle user registration and sign-in, and use a Cognito authorizer in Amazon API Gateway to authenticate API requests.

Configure an Amazon Cognito Identity Pool linked to the User Pool, and map Cognito user groups to IAM roles that grant the required Amazon S3 permissions.

Use the Amazon Cognito User Pool directly to issue temporary AWS credentials for the web application to perform the Amazon S3 upload.

Create a custom API Gateway Lambda authorizer to decode, verify, and validate the JSON Web Tokens (JWTs) sent from the client application.

Configure an Amazon Cognito Identity Pool to store user profiles, manage email verification, and enforce multi-factor authentication (MFA).

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool to handle user registration and sign-in, and use a Cognito authorizer in Amazon API Gateway to authenticate API requests.; Configure an Amazon Cognito Identity Pool linked to the User Pool, and map Cognito user groups to IAM roles that grant the required Amazon S3 permissions.

Answer

Configure an Amazon Cognito User Pool to handle user registration and sign-in, use a Cognito authorizer in Amazon API Gateway, and configure an Amazon Cognito Identity Pool linked to the User Pool to map user groups to IAM roles for S3 access.

The correct solution involves using a Cognito User Pool to register and authenticate users, generating JWTs. A Cognito Identity Pool is then linked to the User Pool to exchange these JWTs for temporary AWS IAM credentials, which are mapped to specific roles allowing S3 upload access. Finally, the native Cognito authorizer in API Gateway is configured to validate the User Pool's tokens directly, minimizing operational overhead.

Step-by-Step Solution

Set up authentication directory.

Created an Amazon Cognito User Pool to manage user sign-up, sign-in, and generate JWT tokens.

User Pools act as the identity provider for user credentials and session management.

Establish S3 authorization.

Created an Amazon Cognito Identity Pool, integrated it with the User Pool, and mapped user groups to IAM roles with S3 permissions.

Identity Pools are necessary to vend temporary AWS credentials required for direct S3 API interactions.

Configure API Gateway protection.

Configured a Cognito authorizer on the API Gateway REST API endpoints.

Using the built-in Cognito authorizer allows API Gateway to validate User Pool tokens natively without needing custom Lambda code.

Key Concept

Amazon Cognito Authentication and Authorization Integration

Question 39Question →

A developer is migrating a legacy desktop application to a modern cloud-native web application. The application must support federated single sign-on (SSO) using a corporate SAML identity provider. Once users log in, the web client needs to access a private Amazon S3 bucket to retrieve user-specific reports and call a secured Amazon API Gateway HTTP API. Which TWO configurations must the developer implement to meet these requirements with the least operational overhead?

Select all that apply

Configure an Amazon Cognito User Pool with a SAML identity provider integration, and configure the API Gateway HTTP API to use a JWT authorizer that validates the User Pool tokens.

Configure an Amazon Cognito Identity Pool that trusts the User Pool, and associate the authenticated IAM role with permissions to read from the target S3 bucket.

Configure the S3 bucket policy to trust the Cognito User Pool directly, allowing access based on the User Pool ID token.

Implement a custom AWS Lambda authorizer in API Gateway to validate the Cognito tokens and generate dynamic IAM policies for S3 access.

Configure the Cognito User Pool to issue temporary AWS credentials directly to the client application via the AWS SDK.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool with a SAML identity provider integration, and configure the API Gateway HTTP API to use a JWT authorizer that validates the User Pool tokens.; Configure an Amazon Cognito Identity Pool that trusts the User Pool, and associate the authenticated IAM role with permissions to read from the target S3 bucket.

Answer

Configure an Amazon Cognito User Pool with a SAML identity provider integration, configure the API Gateway HTTP API to use a JWT authorizer that validates the User Pool tokens, and configure an Amazon Cognito Identity Pool that trusts the User Pool, associating the authenticated IAM role with permissions to read from the target S3 bucket.

To meet the requirements with the least operational overhead, the developer should combine Amazon Cognito User Pools and Identity Pools. The User Pool handles authentication, integrating with the SAML identity provider to authenticate users. For API Gateway HTTP APIs, the built-in JWT authorizer validates the User Pool tokens without requiring custom code. To access Amazon S3, the developer needs an Identity Pool to exchange the authenticated User Pool token for temporary AWS credentials, allowing the web client to perform direct S3 API requests using an IAM role.

Step-by-Step Solution

Configure user authentication and identity federation.

Create an Amazon Cognito User Pool, integrate it with the corporate SAML identity provider, and configure the application to redirect users for login.

This establishes the identity directory and federated identity management with the external SAML provider.

Implement API Gateway authorization.

Configure a native JWT authorizer on the API Gateway HTTP API pointing to the Cognito User Pool issuer URL.

This secures the HTTP API endpoints by validating the JSON Web Tokens (JWT) issued by Cognito, requiring zero custom Lambda code.

Enable secure S3 access.

Create an Amazon Cognito Identity Pool, configure the User Pool as an identity provider, and attach an IAM policy to the authenticated role allowing read permissions to the S3 bucket.

This enables the web client to exchange its Cognito User Pool token for temporary AWS credentials to read reports directly from Amazon S3.

Key Concept

Combining Cognito User Pools for user authentication and API Gateway token validation with Cognito Identity Pools for temporary AWS credential authorization.

Estimated Time:2m 0s

Question 40Question →

A gaming company is developing a new multiplayer dashboard application. The application must authenticate users against an existing, on-premises legacy database containing user credentials without migrating user data to the cloud. Once authenticated, the client application must be able to query leaderboard data directly from an Amazon DynamoDB table and publish telemetry events directly to an Amazon Kinesis Data Stream. Which TWO actions should the developer take to meet these requirements?

Select all that apply

Build a backend authentication service that validates the user's legacy credentials and calls the GetOpenIdTokenForDeveloperIdentity API to return a Cognito identity ID and an OpenID Connect token to the client.

Create an Amazon Cognito User Pool with custom authentication triggers (Define Auth Challenge, Create Auth Challenge, and Verify Auth Challenge Response) to authenticate users against the legacy database, and pass the User Pool ID token directly to authorize client SDK requests to DynamoDB and Kinesis.

Create an API Gateway API with a custom Lambda Authorizer that queries the legacy database, validates credentials, and returns temporary IAM credentials by calling the AssumeRole API in STS directly to the client.

Configure an Amazon Cognito User Pool with a SAML 2.0 federation identity provider that syncs the on-premises database credentials via AWS Directory Service, and exchange the resulting SAML assertion directly for IAM credentials using an Identity Pool.

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool to support developer authenticated identities (developer provider name) and associate an IAM role for authenticated users with policies allowing access to DynamoDB and Kinesis.; Build a backend authentication service that validates the user's legacy credentials and calls the GetOpenIdTokenForDeveloperIdentity API to return a Cognito identity ID and an OpenID Connect token to the client.

Answer

Configure an Amazon Cognito Identity Pool to support developer authenticated identities (developer provider name) and associate an IAM role for authenticated users with policies allowing access to DynamoDB and Kinesis; and build a backend authentication service that validates the user's legacy credentials and calls the GetOpenIdTokenForDeveloperIdentity API to return a Cognito identity ID and an OpenID Connect token to the client.

The correct options work in tandem to implement Developer Authenticated Identities. The developer-designed backend validates user credentials against the legacy database and uses the GetOpenIdTokenForDeveloperIdentity API to obtain an OpenID Connect token and Cognito identity ID. The client application then uses these to request temporary AWS credentials from the Cognito Identity Pool, which assumes the authenticated IAM role containing the necessary DynamoDB and Kinesis permissions.

Step-by-Step Solution

Implement a custom backend service that validates credentials against the legacy database.

The user is authenticated successfully within the company's existing on-premises authentication domain.

Since the legacy credentials cannot be migrated to the cloud, the validation must happen on a secure backend system controlled by the developer.

Use the backend service to invoke the Cognito GetOpenIdTokenForDeveloperIdentity API.

Cognito registers the developer-authenticated identity and returns a unique identity ID and an OpenID Connect (OIDC) token to the backend, which forwards them to the client.

This establishes a mapping between the custom user identity and an Amazon Cognito Identity Pool identifier.

Configure the Amazon Cognito Identity Pool to trust the developer provider name, and attach an authenticated IAM role with read/write access to DynamoDB and Kinesis.

The client application can call GetCredentialsForIdentity using the OIDC token to retrieve temporary, limited-privilege AWS credentials.

This enables the client application to query DynamoDB and publish to Kinesis directly without passing through a custom API proxy.

Key Concept

Cognito Developer Authenticated Identities (Developer Provider Flow)

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