All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is deploying a containerized microservice to Amazon ECS using the AWS Fargate launch type. The application requires sensitive database credentials to be injected into the container as environment variables at startup from AWS Systems Manager Parameter Store. Additionally, the application must send its container logs to Amazon CloudWatch Logs using the awslogs log driver. Which configuration steps must the developer perform to establish the required IAM roles and permissions for this deployment? (Select TWO.)

Select all that apply

Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs.

Configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

Configure the ECS task role with permissions to retrieve the SSM parameters and write logs to CloudWatch Logs.

Configure the trust policy of the ECS task execution role to allow the ec2.amazonaws.com service principal to assume the role.

Initialize the AWS SDK client within the application code using hardcoded IAM access keys to retrieve the database credentials at runtime.

Show answer & explanation

Answer: Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs.; Configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

Answer

Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs, and configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

The correct options state that the ECS task execution role must be configured with permissions to access SSM Parameter Store, decrypt the secrets using KMS, and write logs to CloudWatch, and that the trust policy must allow ecs-tasks.amazonaws.com to assume the role. The ECS container agent runs outside the application container to set up logs and pull secrets, meaning it relies on the task execution role, which must trust the ECS service principal.

Step-by-Step Solution

Identify the agent responsible for pulling secrets and setting up logging.

The ECS container agent (not the application code) performs these pre-startup actions, which means the ECS task execution role is required instead of the ECS task role.

Correctly segregating container initialization permissions from application runtime permissions is required by ECS.

Grant specific resource access permissions to the task execution role.

The task execution role receives permissions to read SSM parameters, decrypt KMS keys, and create/write logs in CloudWatch.

This enables the ECS agent to retrieve credentials from Parameter Store and direct container logs to CloudWatch.

Configure the trust relationship for the task execution role.

The role's trust policy is updated to allow the ecs-tasks.amazonaws.com service principal to assume the role.

ECS tasks cannot assume IAM roles unless the ECS service principal is explicitly trusted.

Key Concept

Differentiating between the ECS Task Role and the ECS Task Execution Role, and configuring the correct trust relationships and policies.

Estimated Time:1m 30s

Question 682Question →

An organization is developing a web-based document portal using React. The portal must allow employees to authenticate using their existing corporate SAML identity provider (IdP). Once authenticated, the application must meet the following requirements:

1. Access a backend REST API hosted on Amazon API Gateway, validating the user's authentication token and verifying their group membership.
2. Directly download department-specific files from an Amazon S3 bucket, restricting access so that users can only retrieve objects under a prefix that matches their department attribute (e.g., /finance/* for the finance department).

Which combination of configuration steps will meet these requirements with the least operational overhead and the most secure architecture?

Configure an Amazon Cognito Identity Pool to federate directly with the SAML IdP to handle user authentication. Use an API Gateway Lambda Authorizer to validate the Identity Pool's credentials for API access. Set up an Amazon Cognito User Pool to generate temporary AWS credentials for the web application, and apply an IAM policy to the User Pool's authenticated role that grants access to the S3 bucket using the user's department attribute.

Configure an Amazon Cognito User Pool federated with the SAML IdP. Write a custom API Gateway Lambda Authorizer to manually decode, verify, and extract claims from the Cognito ID token. Configure a Cognito Identity Pool to obtain temporary AWS credentials, and write an IAM policy for the authenticated role that references the custom department attribute directly as a policy variable without setting up attribute mappings or session tags.

Configure an Amazon Cognito User Pool federated with the SAML IdP. Use a Cognito User Pool Authorizer on API Gateway to validate the ID token. Set up a Cognito Identity Pool that maps the user's department attribute to the principal tag department. Associate an IAM role with the Identity Pool, but omit the sts:TagSession action from the trust policy, and write an IAM permission policy for the role referencing the department tag in the S3 resource path.

Configure an Amazon Cognito User Pool federated with the SAML IdP. Use a Cognito User Pool Authorizer on API Gateway to validate the ID token. Set up a Cognito Identity Pool that uses the User Pool as an identity provider, and map the user's department attribute to the principal tag department. Associate an IAM role with the Identity Pool, ensuring its trust policy allows sts:AssumeRoleWithWebIdentity and sts:TagSession, and apply an S3 permission policy referencing the department tag in the resource path.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool federated with the SAML IdP. Use a Cognito User Pool Authorizer on API Gateway to validate the ID token. Set up a Cognito Identity Pool that uses the User Pool as an identity provider, and map the user's department attribute to the principal tag department. Associate an IAM role with the Identity Pool, ensuring its trust policy allows sts:AssumeRoleWithWebIdentity and sts:TagSession, and apply an S3 permission policy referencing the department tag in the resource path.

Answer

The correct option is the one that configures a Cognito User Pool federated with the SAML IdP, uses a Cognito User Pool Authorizer on API Gateway, maps the department attribute to a principal tag in the Identity Pool, and includes both sts:AssumeRoleWithWebIdentity and sts:TagSession in the IAM role's trust policy.

The correct solution uses an Amazon Cognito User Pool to handle user authentication and federation with the corporate SAML IdP. The REST API hosted on API Gateway is secured using a built-in Cognito User Pool Authorizer, which handles token verification natively without custom code. To obtain temporary AWS credentials for S3 access, a Cognito Identity Pool is utilized. By configuring 'Attributes for access control' in the Identity Pool, the custom department claim from the user's token is mapped to a principal tag named department. The trust policy of the IAM role assumed by authenticated users must allow sts:AssumeRoleWithWebIdentity and sts:TagSession to permit Cognito to apply this tag to the session. The S3 permissions policy can then dynamically restrict access to department-specific prefixes by referencing the policy variable ${aws:PrincipalTag/department}.

Step-by-Step Solution

Set up authentication by federating the corporate SAML IdP with an Amazon Cognito User Pool.

Users can authenticate and receive JWT tokens (ID, access, and refresh tokens) containing custom attributes such as their department.

Amazon Cognito User Pools act as the primary user directory and support SAML 2.0 federation natively.

Configure a Cognito User Pool Authorizer on Amazon API Gateway.

API Gateway automatically validates the signature and expiration of the User Pool tokens before forwarding requests to backend integrations.

This provides built-in token validation without writing or maintaining a custom Lambda authorizer.

Link the User Pool to a Cognito Identity Pool and configure attribute mapping.

The identity pool is configured to map the user token's custom:department claim to the session principal tag department.

This allows user attributes from the authentication token to be passed into the IAM session as principal tags (Attribute-Based Access Control).

Configure the trust policy and permissions policy of the IAM role associated with the Cognito Identity Pool.

The trust policy allows sts:AssumeRoleWithWebIdentity and sts:TagSession. The permission policy grants S3 access restricted by the policy variable ${aws:PrincipalTag/department}.

The TagSession permission is required for Cognito to attach mapped attributes as tags during assume-role operations. The S3 prefix constraint dynamically secures access based on the user's department.

Key Concept

Attribute-Based Access Control (ABAC) using Cognito User Pools and Identity Pools with session tags

Question 683Question →

A developer is implementing client-side envelope encryption for a microservice that processes sensitive payload objects larger than $128\text{ KB}$ before storing them in an Amazon DynamoDB table. The developer needs to minimize latency, avoid KMS cryptographic limits, and ensure secure key storage.

Which of the following workflows is the correct method to encrypt and store the payloads?

Call `Encrypt` using the Customer Managed Key (CMK) to encrypt each payload directly, and then call `GenerateDataKeyWithoutPlaintext` to generate a secondary local data key to encrypt the metadata before storing both payloads in DynamoDB.

Call `GenerateDataKey` using the Customer Managed Key (CMK) to obtain a plaintext data key and a ciphertext data key. Encrypt the payload locally using the plaintext data key, immediately delete the plaintext data key from memory, and store the ciphertext data key alongside the encrypted payload in DynamoDB.

Call `GenerateDataKey` to obtain a data key, encrypt the payload locally, and store the plaintext data key as a secure configuration in Systems Manager Parameter Store with automatic rotation enabled to decrypt future payloads.

Call `GenerateDataKey` using the Customer Managed Key (CMK) to get the plaintext key, encrypt the payload, and then update the IAM Trust Policy of the microservice's execution role to allow the DynamoDB service principal to decrypt the data key directly.

Show answer & explanation

Answer: Call `GenerateDataKey` using the Customer Managed Key (CMK) to obtain a plaintext data key and a ciphertext data key. Encrypt the payload locally using the plaintext data key, immediately delete the plaintext data key from memory, and store the ciphertext data key alongside the encrypted payload in DynamoDB.

Answer

Call the `GenerateDataKey` API to obtain a plaintext and ciphertext data key, encrypt the payload locally, delete the plaintext key from memory, and store the ciphertext data key with the encrypted payload in DynamoDB.

The correct workflow for client-side envelope encryption involves calling the `GenerateDataKey` API to obtain both a plaintext and a ciphertext version of a unique data key. The plaintext key is used to perform the resource-intensive encryption locally, keeping payload transit off the network and avoiding KMS API rate limits or payload size limits. The plaintext key is then deleted from memory, and the encrypted (ciphertext) data key is stored alongside the encrypted data.

Step-by-Step Solution

Request a data key from AWS KMS.

The `GenerateDataKey` API is called with the Customer Managed Key, returning both a plaintext data key and an encrypted (ciphertext) data key.

This provides a unique data key for symmetric encryption of the payload, ensuring envelope encryption constraints are met.

Encrypt the sensitive payload client-side.

The plaintext data key is used with a local cryptographic library (e.g., AES-GCM) to encrypt the payload larger than

128\text{ KB}

without sending the payload to AWS KMS.

AWS KMS direct encryption APIs (`Encrypt`) have a limit of

4\text{ KB}

, so client-side encryption is required for larger payloads to prevent payload limit failures.

Persist the encrypted data and data key, cleaning up memory.

The plaintext data key is wiped from memory, and the encrypted payload along with the ciphertext data key are saved into DynamoDB.

This ensures the plaintext key is not exposed and that future decryption is possible by calling `Decrypt` with the ciphertext data key.

Key Concept

AWS KMS Envelope Encryption

Estimated Time:2m 30s

Question 684Question →

A developer is deploying a serverless application using a local AWS Serverless Application Model (SAM) template file named `template.yaml`. The template contains the following definition:

yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
GetProductFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs20.x
CodeUri: ./src
Events:
GetProduct:
Type: Api
Properties:
Path: /products/{id}
Method: get

The developer attempts to deploy the application directly by executing the following AWS CLI command:

`aws cloudformation deploy --template-file template.yaml --stack-name product-service-dev --capabilities CAPABILITY_IAM`

However, the command fails, indicating that the `CodeUri` property of the `AWS::Serverless::Function` resource must point to an Amazon S3 location.

Which of the following statements identifies the root cause of this error and the correct action to resolve it?

The template has the `Transform: AWS::Serverless-2016-10-31` declaration defined at the root level, but this declaration must be moved under the `Metadata` section of the template so that the CloudFormation service can parse and auto-upload local paths.

CloudFormation cannot natively resolve local directory paths like `./src`. The developer must use `sam deploy` (or execute `aws cloudformation package` followed by `aws cloudformation deploy` using the generated packaged template) to zip and upload the local directory to Amazon S3, replacing the local path with an S3 URI.

The execution role associated with the CloudFormation stack deployment is missing a trust policy allowing the `apigateway.amazonaws.com` service principal to assume the role, preventing CloudFormation from reading from the local path.

The API Gateway integration is configured as a proxy integration, which requires the backend Lambda function to return a structured JSON response containing headers, statusCode, and body to authorize local file access.

Show answer & explanation

Answer: CloudFormation cannot natively resolve local directory paths like `./src`. The developer must use `sam deploy` (or execute `aws cloudformation package` followed by `aws cloudformation deploy` using the generated packaged template) to zip and upload the local directory to Amazon S3, replacing the local path with an S3 URI.

Answer

The correct response explains that CloudFormation cannot directly resolve local file paths. Standard CloudFormation deployments require that all Lambda code references (`CodeUri`) point to an S3 object. To resolve this, the developer must package the application using the AWS SAM CLI (`sam deploy`) or the AWS CLI package command (`aws cloudformation package`), which uploads the local zip file to S3 and returns a template with the updated S3 URLs before deploying.

Step-by-Step Solution

Analyze the failed deployment command and the error message.

The developer ran `aws cloudformation deploy` directly on a raw template containing `CodeUri: ./src`, and CloudFormation rejected it because it expects an S3 URL.

CloudFormation runs on AWS servers and has no direct access to the developer's local hard drive to retrieve `./src` during deployment.

Determine how local artifacts are prepared for AWS SAM deployments.

Local code directories must be compressed into a ZIP file, uploaded to an S3 bucket, and the template reference must be replaced with the S3 URI.

This artifact packaging step must occur prior to sending the template to the CloudFormation API.

Select the correct tool or sequence of commands to perform this preparation.

Using the AWS SAM CLI (`sam deploy` or `sam package`) or AWS CLI (`aws cloudformation package`) compiles and uploads local files, producing a deployable template.

These tools automate the packaging workflow and correctly rewrite local paths to S3 references before invoking CloudFormation deploy.

Key Concept

Local Artifact Packaging in AWS Serverless Application Model (SAM) Deployments

Estimated Time:3m 0s

Question 685Question →

A developer is designing a serverless architecture for a report distribution application. The frontend is a Single Page Application (SPA) hosted on Amazon S3. The backend APIs are deployed using Amazon API Gateway. The developer needs to implement sign-up and sign-in functionality for users, secure the API Gateway endpoints, and allow the SPA to download reports directly from a private S3 bucket after authentication.

Which combination of actions should the developer take to meet these requirements securely? (Select TWO.)

Select all that apply

Create an Amazon Cognito User Pool to manage user registration and authentication, and configure a Cognito User Pool Authorizer on the API Gateway REST API.

Create an Amazon Cognito Identity Pool, link it to the User Pool, and map users to an authenticated IAM role that allows reading from the private S3 bucket.

Create an Amazon Cognito Identity Pool to manage user registration and directory services, and configure a built-in Cognito Authorizer on the API Gateway REST API.

Configure a custom Lambda Authorizer in API Gateway to generate and return temporary AWS credentials from the Cognito Identity Pool directly in the authorization response.

Create an IAM role with permissions to read from the private S3 bucket, and configure its trust policy to allow the API Gateway service principal to assume the role.

Show answer & explanation

Answer: Create an Amazon Cognito User Pool to manage user registration and authentication, and configure a Cognito User Pool Authorizer on the API Gateway REST API.; Create an Amazon Cognito Identity Pool, link it to the User Pool, and map users to an authenticated IAM role that allows reading from the private S3 bucket.

Answer

Create an Amazon Cognito User Pool to manage user registration and authentication, and configure a Cognito User Pool Authorizer on the API Gateway REST API. Also, create an Amazon Cognito Identity Pool, link it to the User Pool, and map users to an authenticated IAM role that allows reading from the private S3 bucket.

To implement these requirements securely, the developer must use a Cognito User Pool to handle user authentication and registration. API Gateway integrates natively with Cognito User Pools using a built-in authorizer to validate the JWT tokens generated during login. For direct S3 access from the browser, Cognito Identity Pools (federated identities) should be used. The Identity Pool integrates with the User Pool as an identity provider and exchanges the User Pool tokens for temporary AWS credentials, which are mapped to an authenticated IAM role that grants permissions to the private S3 bucket.

Step-by-Step Solution

Identify the service required for user sign-up, sign-in, and directory management.

Amazon Cognito User Pools is chosen as the user directory.

Cognito User Pools handle authentication, user registration, and token generation.

Secure the Amazon API Gateway endpoints using the authenticated user identity.

Configure a Cognito User Pool Authorizer on API Gateway.

API Gateway can natively validate Cognito User Pool JWT tokens without custom Lambda code.

Determine the mechanism to allow the frontend SPA to download files directly from a private S3 bucket.

Use Amazon Cognito Identity Pools to exchange User Pool tokens for temporary AWS credentials associated with an IAM role.

Cognito Identity Pools provide temporary AWS credentials to federated or authenticated users for direct access to AWS resources like S3.

Key Concept

Using Cognito User Pools for authentication and API Gateway protection, combined with Cognito Identity Pools for temporary AWS credentials to access S3.

Question 686Question →

A developer attempts to create a new AWS CloudFormation stack to deploy a web application. The stack creation fails because of an invalid AMI ID parameter, and the stack enters the ROLLBACK_COMPLETE status. The developer updates the template with the correct AMI ID.

Which action should the developer take to deploy the resources successfully?

Delete the stack in the ROLLBACK_COMPLETE status, and then create a new stack using the updated template.

Update the existing stack directly in the ROLLBACK_COMPLETE status by uploading the updated template.

Manually launch the EC2 instance with the correct AMI ID in the Amazon EC2 Console, and then perform a drift detection sync on the stack.

Use AWS Secrets Manager to store the correct AMI ID and force a dynamic reference update on the existing stack.

Show answer & explanation

Answer: Delete the stack in the ROLLBACK_COMPLETE status, and then create a new stack using the updated template.

Answer

Delete the stack in the ROLLBACK_COMPLETE status, and then create a new stack using the updated template.

When a CloudFormation stack fails to create on its very first attempt, it rolls back all created resources and enters the ROLLBACK_COMPLETE status. Stacks in the ROLLBACK_COMPLETE status cannot be updated; they must be deleted before a new stack can be created with the same name and the corrected template.

Step-by-Step Solution

Identify the stack's current state and origin of failure.

The stack failed during initial creation and rolled back successfully to the ROLLBACK_COMPLETE state.

Before deciding on a recovery action, the developer must determine if the stack was previously successful or if it failed on its first creation attempt.

Evaluate the update capability of the stack in the current state.

AWS CloudFormation does not allow update operations on stacks that fail initial creation (ROLLBACK_COMPLETE). Updates are only allowed on successfully created stacks or stacks that fail during a subsequent update (UPDATE_ROLLBACK_COMPLETE).

This determines whether the existing stack can be updated or must be recreated.

Perform stack cleanup and recreation.

Delete the failed stack and create a new one using the corrected template.

This removes the failed stack metadata from the account and allows the deployment to start fresh with the corrected parameters.

Key Concept

CloudFormation Stack Lifecycle and Rollback States

Question 687Question →

A developer is creating a web application and needs to provide a secure sign-up, sign-in, and password reset workflow for the application's users. The developer must also maintain a user directory to store user profile data. Which feature or service should the developer implement to meet these requirements?

Amazon Cognito User Pools

Amazon Cognito Identity Pools

Amazon API Gateway Lambda Authorizer

IAM role trust policies configured for the client application

Show answer & explanation

Answer: Amazon Cognito User Pools

Answer

Amazon Cognito User Pools

Amazon Cognito User Pools act as a user directory that provides sign-up, sign-in, and password recovery out of the box, fulfilling the authentication and profile management requirements.

Step-by-Step Solution

Identify the primary requirement, which is to implement user authentication (sign-up, sign-in, password reset) and manage a user directory containing profile data.

The requirement is centered on user authentication and user profile management (identity provider functionality).

This helps distinguish between authentication/directories and authorization/AWS resource access.

Evaluate the AWS features that manage user directories and handle standard OIDC/OAuth2 user flows.

Amazon Cognito User Pools serves as a user directory and provides out-of-the-box flows for user registration, authentication, and password recovery.

Choosing Cognito User Pools directly solves the business requirement with minimal custom code.

Key Concept

Amazon Cognito User Pools are designed to manage user directories, authentication, and sign-up/sign-in workflows.

Question 688Question →

A developer is building a mobile application that allows external users to authenticate using an external OpenID Connect (OIDC) identity provider. Once authenticated, users must be able to upload log files directly to a private Amazon S3 bucket. Each user's uploads must be restricted to an S3 folder named after their unique OIDC user identifier (the `sub` claim). The application also needs to write metadata for each upload to an Amazon DynamoDB table, using the same OIDC `sub` value as the partition key. Which solution meets these requirements with the least development effort and adheres to the principle of least privilege?

Configure an Amazon Cognito User Pool with the OIDC provider. Configure an Amazon Cognito Identity Pool using the User Pool as an authentication provider. In the authenticated IAM role, define the S3 prefix and DynamoDB partition key using the policy variable `${cognito-identity.amazonaws.com:sub}`.

Create an Amazon API Gateway endpoint with a custom Lambda Authorizer. Have the Lambda Authorizer validate the OIDC token, retrieve the `sub` claim, and call `sts:AssumeRole` to generate temporary AWS credentials with an inline IAM policy scoped to the user's OIDC `sub` prefix. Pass these credentials back to the client to perform S3 and DynamoDB operations.

Configure an Amazon Cognito User Pool with the OIDC provider as an identity provider, mapping the OIDC `sub` claim to a custom attribute. Configure an Amazon Cognito Identity Pool with the User Pool as an authentication provider, enabling 'Attributes for access control' to map the custom attribute to a principal tag. Reference the mapped tag using `${aws:PrincipalTag/...}` in the IAM policy for the authenticated role to authorize S3 and DynamoDB actions.

Federate the OIDC provider directly with an Amazon Cognito Identity Pool. Associate an IAM role with the Identity Pool, and reference `${amazon.cognito.auth.externalIdp:sub}` in the IAM policy to restrict S3 bucket and DynamoDB access.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool with the OIDC provider as an identity provider, mapping the OIDC `sub` claim to a custom attribute. Configure an Amazon Cognito Identity Pool with the User Pool as an authentication provider, enabling 'Attributes for access control' to map the custom attribute to a principal tag. Reference the mapped tag using `${aws:PrincipalTag/...}` in the IAM policy for the authenticated role to authorize S3 and DynamoDB actions.

Answer

The correct solution is to configure the Amazon Cognito User Pool to map the OIDC `sub` claim to a custom attribute, map that attribute to a principal tag in the Identity Pool using 'Attributes for access control', and reference the tag via the policy variable in the IAM policy.

Mapping the OIDC `sub` claim to a Cognito User Pool custom attribute, exposing it as a Principal Tag via the Identity Pool's 'Attributes for access control', and utilizing the principal tag policy variable in the IAM policy is the most secure and operationally efficient way to implement attribute-based access control (ABAC) for federated users.

Step-by-Step Solution

Map the OIDC provider's unique `sub` claim to a custom attribute (e.g., `custom:oidc_sub`) in the Amazon Cognito User Pool during authentication setup.

The external provider's unique user identifier is captured and persisted in the Cognito user directory.

This makes the claim available for downstream mapping within AWS credentials session generation.

Enable 'Attributes for access control' in the Amazon Cognito Identity Pool and configure a mapping from the custom User Pool attribute `custom:oidc_sub` to a principal tag (e.g., `user_id`).

The identity provider claim is converted into a session tag (`aws:PrincipalTag/user_id`) attached to the temporary credentials issued by AWS STS.

This enables Attribute-Based Access Control (ABAC) dynamically on AWS services using IAM policy variables.

Create an IAM policy for the Cognito authenticated role that restricts S3 access to `arn:aws:s3:::my-bucket/

{aws:PrincipalTag/user_id}/*` and DynamoDB access based on the leading key matching `

{aws:PrincipalTag/user_id}`.

Dynamic, fine-grained access control is enforced automatically for each unique user based on their federated OIDC session identifier.

This adheres to the principle of least privilege without creating separate IAM roles per user or writing token exchange logic.

Key Concept

Attribute-Based Access Control (ABAC) with Amazon Cognito Identity Pools and federated OIDC providers.

Question 689Question →

A developer is building a serverless web application that allows authenticated users to read and write items in a shared Amazon DynamoDB table. The application needs to support self-service user registration and login, as well as authenticate users via a secure directory. The client application runs in the browser and must interact directly with the DynamoDB table using temporary AWS credentials, ensuring that each user can only access items where the partition key matches their unique user identifier. Which combination of steps should the developer perform to configure the authentication and authorization mechanism? (Select TWO.)

Select all that apply

Create an Amazon Cognito User Pool to serve as the user directory and handle user registration, authentication, and token generation.

Create an Amazon Cognito Identity Pool to manage the user directory and handle user registration, and use a custom API Gateway Lambda authorizer to validate users.

Create an Amazon Cognito Identity Pool, configure the User Pool as an identity provider, and associate the authenticated IAM role with a policy that restricts DynamoDB access using the `${cognito-identity.amazonaws.com:sub}` policy variable.

Configure an API Gateway Cognito authorizer that validates the user's ID token and directly modifies the trust policy of the DynamoDB table's IAM role to allow direct client access.

Create an Amazon Cognito User Pool and modify the associated IAM trust policy to allow the User Pool to directly execute the `sts:AssumeRole` API call to retrieve credentials for the client application.

Show answer & explanation

Answer: Create an Amazon Cognito User Pool to serve as the user directory and handle user registration, authentication, and token generation.; Create an Amazon Cognito Identity Pool, configure the User Pool as an identity provider, and associate the authenticated IAM role with a policy that restricts DynamoDB access using the `${cognito-identity.amazonaws.com:sub}` policy variable.

Answer

Create an Amazon Cognito User Pool to serve as the user directory and handle user registration, authentication, and token generation; and create an Amazon Cognito Identity Pool, configure the User Pool as an identity provider, and associate the authenticated IAM role with a policy that restricts DynamoDB access using the `${cognito-identity.amazonaws.com:sub}` policy variable.

The correct architecture requires Cognito User Pools to manage the user identity directory and authentication. It then requires Cognito Identity Pools to authenticate those users against AWS services by exchanging user pool tokens for temporary AWS credentials. Fine-grained access control in DynamoDB is enforced by applying an IAM policy to the authenticated role using the `${cognito-identity.amazonaws.com:sub}` policy variable as a condition matching the partition key.

Step-by-Step Solution

Configure a Cognito User Pool to act as the identity provider.

Users can sign up, log in, and retrieve JSON Web Tokens (JWT) containing their identity information.

User Pools are used to manage authentication and user directories.

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

The identity pool receives the JWT from the user pool and exchanges it for temporary AWS credentials.

Identity Pools are designed for authorization, exchanging third-party or user pool tokens for temporary AWS credentials.

Attach a fine-grained access control policy to the IAM role assumed by authenticated users.

The user is allowed to read and write only their own items in the DynamoDB table, restricted by the user's Cognito identity ID.

Using the `${cognito-identity.amazonaws.com:sub}` variable in the IAM policy condition limits DynamoDB table actions (like PutItem, GetItem) to items where the partition key matches the user's specific identity ID.

Key Concept

The separation of concerns between Amazon Cognito User Pools (authentication/directory) and Identity Pools (authorization/temporary credentials), and using fine-grained access control policies.

Question 690Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to automate the release of a containerized web application. The pipeline needs to retrieve source code, build a Docker image, deploy the application to Amazon ECS, and verify its status. Arrange the pipeline actions in the correct chronological sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence of pipeline actions is: retrieve source code using AWS CodeCommit, build the Docker image using AWS CodeBuild, deploy the application using AWS CodeDeploy, and run integration tests using AWS Lambda.

The correct order follows the standard pipeline design: first obtaining source code (Source), compiling and producing the artifact (Build), deploying the artifact to the target platform (Deploy), and finally validating the live deployment (Test/Invoke).

Step-by-Step Solution

Trigger the pipeline by obtaining source files.

Source code is packaged as a source artifact and stored in the CodePipeline artifact bucket.

Subsequent compilation and packaging require access to the raw source code.

Pass the source artifact to CodeBuild to construct the build output.

A Docker image is built, pushed to Amazon ECR, and a build artifact containing the task definition template is created.

Deployment actions require a built container image and configuration templates to proceed.

Pass the build artifact to CodeDeploy to update Amazon ECS.

The target ECS service initiates a rolling update or green/blue deployment using the new task definition.

The application must be deployed to the runtime environment before it can be verified or accessed by clients.

Invoke AWS Lambda to run post-deployment validation tests.

Integration tests run against the live endpoint, and CodePipeline receives a success or failure status signal.

Post-deployment checks verify that the live system behaves correctly after changes are applied.

Key Concept

AWS CodePipeline Stage and Action Sequencing

Question 691Question →

A company is developing a REST API in Amazon API Gateway that will serve a partner dashboard. The dashboard authenticates users through a third-party OpenID Connect (OIDC) identity provider. The developer needs to secure the API Gateway endpoints so that only users containing the PartnerAdmin role within their OIDC token can access the /partner/settings resource. To optimize performance and reduce backend overhead, the system must cache the authorization decisions for up to 10 minutes. Which two configuration steps should the developer perform to meet these requirements?

Select all that apply

Create an API Gateway Lambda authorizer that validates the OIDC JSON Web Token (JWT), verifies the presence of the PartnerAdmin role within the claims, and returns an IAM policy allowing execute-api:Invoke on the resource ARN.

Enable authorizer caching in the API Gateway authorizer configuration, set the TTL to 600 seconds, and specify the client's identity source header as the cache key.

Create an Amazon Cognito User Pool authorizer in API Gateway, configure the Issuer URI to match the third-party OIDC provider, and filter incoming requests using a custom gateway policy mapping.

Configure the API Gateway resource to use standard IAM authorization, and implement token validation and role-checking logic directly within the backend Lambda proxy integration function.

Create an Amazon Cognito Identity Pool authorizer in API Gateway, link the third-party OIDC identity provider, and configure the authorizer to validate the JWT.

Show answer & explanation

Answer: Create an API Gateway Lambda authorizer that validates the OIDC JSON Web Token (JWT), verifies the presence of the PartnerAdmin role within the claims, and returns an IAM policy allowing execute-api:Invoke on the resource ARN.; Enable authorizer caching in the API Gateway authorizer configuration, set the TTL to 600 seconds, and specify the client's identity source header as the cache key.

Answer

Create an API Gateway Lambda authorizer that validates the OIDC JWT token and returns an IAM policy allowing access to the resource, and enable authorizer caching with a TTL of 600 seconds utilizing the identity source header as the cache key.

The correct configurations involve creating a Lambda authorizer to decode and validate the third-party OIDC JWT token, verify the custom claims, and return an IAM policy allowing access. To meet the performance requirement, authorizer caching must be configured on the authorizer with a 600-second TTL using the identity source header (such as the Authorization header) as the cache key.

Step-by-Step Solution

Determine the token issuer and auth type

Identify that the token is issued by a third-party OIDC provider, which rules out Amazon Cognito User Pool authorizers since they only natively support Cognito User Pools.

Choosing the correct authorizer type is the first step to securing custom integrations.

Configure a Lambda authorizer

Create a Lambda authorizer that parses the JWT token, extracts the claims (specifically looking for the PartnerAdmin role), and returns an IAM policy allowing execute-api:Invoke on the target resource.

A Lambda authorizer is required to evaluate custom JWT claims and generate policy documents dynamically.

Configure caching in API Gateway

Enable authorizer caching with a TTL of 600 seconds, setting the identity source to the HTTP header containing the token (e.g., Authorization).

Caching avoids calling the Lambda authorizer on every incoming request, which minimizes overhead and latency.

Key Concept

API Gateway custom Lambda authorizers are used for validating third-party JWT tokens and dynamic policy generation, and authorization caching is used to decrease cost and latency.

Question 692Question →

An application needs to decrypt locally stored database backups that were encrypted using client-side envelope encryption with an AWS Key Management Service (AWS KMS) Customer Managed Key (CMK). The application has access to the encrypted database backups and the encrypted data key that was packaged with the backup. Which two actions must the developer perform in the application code to decrypt the database backups?

Select all that apply

Call the KMS Decrypt API passing the encrypted data key to retrieve the plaintext data key.

Decrypt the database backup locally using the retrieved plaintext data key and a symmetric encryption algorithm.

Call the KMS GenerateDataKey API to recreate the original plaintext data key.

Call the KMS Decrypt API passing the entire database backup payload directly to KMS to decrypt it.

Retrieve the plaintext data key from Systems Manager Parameter Store where it was automatically stored during the encryption process.

Show answer & explanation

Answer: Call the KMS Decrypt API passing the encrypted data key to retrieve the plaintext data key.; Decrypt the database backup locally using the retrieved plaintext data key and a symmetric encryption algorithm.

Answer

Call the KMS Decrypt API passing the encrypted data key to retrieve the plaintext data key, and decrypt the database backup locally using the retrieved plaintext data key and a symmetric encryption algorithm.

In envelope encryption, data is encrypted locally using a unique symmetric data key, and the data key itself is encrypted using a KMS Customer Managed Key. To decrypt the data, the application must send the encrypted data key to the KMS Decrypt API to obtain the plaintext data key. After receiving the plaintext key, the application uses it locally to decrypt the large backup file using a symmetric algorithm such as AES.

Step-by-Step Solution

Pass the encrypted data key to the KMS Decrypt API.

The API returns the decrypted plaintext version of the data key.

The data key is encrypted under a KMS key and must be decrypted by KMS before it can be used for decryption.

Use the plaintext data key with a local encryption library.

The database backup ciphertext is decrypted back into its original plaintext format.

Large data is decrypted client-side using symmetric cryptography (envelope encryption) to avoid sending large files over the network to KMS.

Key Concept

AWS KMS Envelope Decryption Workflow

Question 693Question →

A logistics company is developing a cargo tracking application. The mobile client authenticates users via an Amazon Cognito User Pool. The client application needs to invoke a REST API hosted on Amazon API Gateway to fetch real-time tracking data. The developer wants to restrict access to this API endpoint to ensure that only users authenticated by the user pool can access it. Which approach should the developer use to meet these requirements with the lowest latency and minimal operational overhead?

Configure an Amazon Cognito User Pool authorizer on the API Gateway method, and specify the client's identity or access token in the authorization header.

Configure an Amazon Cognito Identity Pool authorizer on the API Gateway method, and specify the identity pool ID in the HTTP headers of the request.

Create a custom AWS Lambda authorizer that validates the token signature using the Cognito User Pool public keys and generates an IAM policy for the request.

Configure a Lambda proxy integration on the API Gateway method to pass the raw request to the backend function, then validate the token within the function's application code.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool authorizer on the API Gateway method, and specify the client's identity or access token in the authorization header.

Answer

Configure an Amazon Cognito User Pool authorizer on the API Gateway method, and specify the client's identity or access token in the authorization header.

Integrating Amazon API Gateway with an Amazon Cognito User Pool using a built-in Cognito User Pool authorizer allows API Gateway to natively validate the JSON Web Tokens (JWTs) sent by the client. This approach does not require writing or maintaining custom code, runs with minimal latency, and incurs no additional cost or execution time associated with Lambda custom authorizers.

Step-by-Step Solution

Identify the authentication provider and the required integration.

The authentication provider is an Amazon Cognito User Pool which issues JSON Web Tokens (JWTs).

Understanding the source of the user identity is key to selecting the correct authorizer type.

Evaluate the native API Gateway features for JWT validation.

API Gateway offers a built-in Cognito User Pool authorizer that validates JWTs automatically.

Using native features minimizes operational overhead (no code to write) and provides lower latency than custom code execution.

Compare alternatives against the latency and overhead constraints.

Custom Lambda authorizers add latency/cost, Cognito Identity Pools are for resource authorization rather than API authentication, and backend validation runs billing charges for rejected requests.

Verifying constraints ensures the selected native authorizer is the optimal path.

Key Concept

Amazon API Gateway Cognito User Pool Authorizer

Estimated Time:1m 30s

Question 694Question →

A developer is updating a critical, high-traffic API application deployed on AWS Elastic Beanstalk. The application must maintain full serving capacity during the deployment process. If any instance running the new version fails, the system must trigger an automatic rollback to the previous version with the absolute minimum time to restore the original state. The developer wants to avoid the overhead of managing a separate environment for Blue/Green deployments. Which deployment policy best satisfies these requirements?

Immutable

Rolling with additional batch

Rolling

All at once

Show answer & explanation

Answer: Immutable

Answer

The Immutable deployment policy satisfies these requirements by maintaining full capacity and allowing rapid, clean rollbacks.

The Immutable deployment policy creates a temporary Auto Scaling group and launches a new set of instances running the updated version alongside the original instances. This ensures 100% of the active serving capacity is maintained. If the new instances fail health checks, AWS Elastic Beanstalk immediately terminates the temporary Auto Scaling group. This results in an extremely fast rollback with zero impact on the original instances and requires no manual intervention or secondary environment management.

Step-by-Step Solution

Analyze the capacity requirement during deployment.

The application must maintain 100% serving capacity, which rules out 'Rolling' (which reduces capacity during deployment) and 'All at once' (which takes all instances out of service).

Eliminating deployment policies that reduce or eliminate service capacity.

Evaluate the rollback speed and complexity requirement.

The rollback must be automatic and extremely fast. 'Rolling with additional batch' requires updating instances in batches back to the original version, which takes time. 'Immutable' deployments can be rolled back immediately by terminating the temporary Auto Scaling group.

Determining the policy that provides the fastest recovery from a deployment failure.

Check the infrastructure overhead constraint.

The developer wants to avoid managing a separate environment, which is required for Blue/Green deployments but not for Immutable deployments.

Selecting the policy that performs the update within the existing environment without external management overhead.

Key Concept

AWS Elastic Beanstalk Immutable Deployment Policy

Estimated Time:1m 30s

Question 695Question →

A developer is implementing a cross-account ingestion pipeline where an AWS Lambda function running in Account A ( $111111111111$ ) needs to write files to an Amazon S3 bucket in Account B ( $222222222222$ ). The Lambda function is configured with the execution role `arn:aws:iam::111111111111:role/LambdaExecutionRole`.

To write files, the Lambda function code uses the AWS SDK to assume an IAM role in Account B named `S3WriteRole` (`arn:aws:iam::222222222222:role/S3WriteRole`).

The IAM policy attached to `LambdaExecutionRole` in Account A is:

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

When the Lambda function executes, the `sts:AssumeRole` API call fails with an `AccessDenied` error. The developer inspects the trust policy of `S3WriteRole` in Account B, which is currently configured as follows:

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

Which of the following modifications to Account B's `S3WriteRole` trust policy will resolve this authorization error?

Keep the Service principal as lambda.amazonaws.com and add a Condition block matching the aws:PrincipalArn to arn:aws:iam::111111111111:role/LambdaExecutionRole.

Update the Action element in the trust policy to include both sts:AssumeRole and s3:PutObject, and set the Resource to the S3 bucket ARN.

Change the Principal element in the trust policy to trust the AWS resource ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

Hardcode the access keys of an IAM user in Account B who has write access to the S3 bucket directly into the Lambda function code, bypassing the STS call.

Show answer & explanation

Answer: Change the Principal element in the trust policy to trust the AWS resource ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

Answer

Change the Principal element in the trust policy to trust the AWS resource ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

The correct answer changes the trust policy's principal to trust the AWS principal of the execution role. This is correct because when the Lambda function runs and makes an SDK call to assume the role, it uses the credentials of its execution role. The target role's trust policy in Account B must explicitly trust this execution role ARN.

Step-by-Step Solution

Analyze the IAM caller context of the Lambda execution environment.

The AWS SDK inside the Lambda function uses the function's execution role (`LambdaExecutionRole`) to sign the request to assume the target role.

Understanding which principal initiates the API request is key to setting up the trust relationship.

Determine the required trust policy principal type.

Since the request is made by an IAM role (an AWS principal) and not by the Lambda service itself, the trust policy must use the "AWS" principal type pointing to the role's ARN.

Service principals are only used when AWS services (like Lambda or EC2) directly assume a role to bootstrap an execution environment, not for programmatic calls.

Validate the cross-account role assumption handshake.

Account A's role has permission to perform `sts:AssumeRole` on Account B's role, and Account B's role trusts Account A's role. This completes the trust chain.

Both sides of the cross-account relationship must be explicitly configured for the action to succeed.

Key Concept

AWS IAM trust relationships require configuring the correct principal type (AWS principal vs Service principal) depending on who is performing the role assumption.

Estimated Time:3m 0s

Question 696Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to deploy a serverless web application. The pipeline needs to pause automatically after the test stage and wait for a QA manager to review the test results before deploying to the production stage. Which of the following is the correct configuration to implement this manual approval step?

Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

Store the approval state as a SecureString parameter in Systems Manager Parameter Store, and write a script in the build stage to poll for its value.

Modify the trust policy of the IAM service role for CodePipeline to allow the QA manager's IAM user to assume the role and resume the pipeline.

Place a build spec file in a subdirectory of the source repository with instructions to pause the CodeBuild container execution until an approval webhook is called.

Show answer & explanation

Answer: Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

Answer

Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

The correct answer provides the standard, native method for introducing a human review step in AWS CodePipeline. The Manual Approval action type natively pauses the pipeline execution without consuming compute resources, and integrates with Amazon SNS to notify the reviewers.

Step-by-Step Solution

Identify the pipeline requirement for pausing execution for a human reviewer.

The requirement is a manual approval gate before production deployment.

Understanding the design requirements helps select the native AWS CodePipeline feature meant for this purpose.

Evaluate native CodePipeline features for approvals versus custom scripting.

CodePipeline provides a built-in 'Manual Approval' action type that halts transition natively.

Using native actions is more cost-effective, secure, and easier to maintain than custom polling mechanisms.

Verify correct configuration details for the Manual Approval action.

A manual approval action is added to a pipeline stage, with an optional SNS topic to notify the QA team.

Configuring SNS ensures the team is proactively alerted when an approval is pending.

Key Concept

AWS CodePipeline manual approval actions allow a pipeline execution to be paused at a specific stage until approval is received.

Question 697Question →

A developer is designing a web application and wants to store user session states externally to make the application tier completely stateless. The session store must support high availability, scale horizontally, and allow fast key-value lookups. Which TWO of the following configurations should the developer implement? (Select TWO.)

Select all that apply

Store session states in Amazon DynamoDB using the user ID as the partition key, and retrieve sessions using Query operations.

Store session states in Amazon ElastiCache for Redis configured with multi-AZ replication.

Store session states in AWS Secrets Manager and enable automatic rotation to manage session expiration.

Store session states in Amazon DynamoDB and use periodic Scan operations to retrieve specific session records.

Store session states in local Lambda execution context variables to persist data across all concurrent users.

Show answer & explanation

Answer: Store session states in Amazon DynamoDB using the user ID as the partition key, and retrieve sessions using Query operations.; Store session states in Amazon ElastiCache for Redis configured with multi-AZ replication.

Answer

Store session states in Amazon DynamoDB using the user ID as the partition key, and retrieve sessions using Query operations; and store session states in Amazon ElastiCache for Redis configured with multi-AZ replication.

The correct configurations involve using Amazon DynamoDB with a partition key Query lookup, which scales horizontally and provides low-latency key-value access, and Amazon ElastiCache for Redis with multi-AZ replication, which provides sub-millisecond latency and automatic failover for high availability.

Step-by-Step Solution

Identify the architectural requirements: externalized session state, high availability, horizontal scalability, and low-latency key-value lookups.

The target storage must be a distributed cache or a highly scalable NoSQL database optimized for key-value lookups.

This rules out local storage, relational databases (not optimized for rapid key-value session throughput), or secrets management services.

Evaluate Amazon DynamoDB and Amazon ElastiCache for Redis against the requirements.

Amazon DynamoDB with partition key Query operations and Amazon ElastiCache for Redis with multi-AZ replication meet all high-availability, scalability, and latency requirements.

DynamoDB scales horizontally and provides single-digit millisecond latency. Redis provides sub-millisecond latency and replication ensures high availability.

Eliminate incorrect options based on anti-patterns and misconfigured query structures.

Secrets Manager, DynamoDB Scan operations, and local Lambda execution contexts are eliminated due to inefficiency, wrong service use case, or incorrect scope of variable reuse.

Secrets Manager is for sensitive secrets, Scan is inefficient for point lookups, and Lambda local context does not share state across concurrent execution environments.

Key Concept

Decoupling application state using highly available, low-latency external data stores such as Amazon DynamoDB or Amazon ElastiCache.

Question 698Question →

An enterprise has a backend service running on Amazon EC2 that needs to securely communicate with a protected REST API hosted on Amazon API Gateway. There is no user interaction involved in this communication. The developer wants to implement a secure, scalable authentication and authorization mechanism using Amazon Cognito to protect the API. How should the developer configure Amazon Cognito and API Gateway to meet these requirements with the least operational overhead?

Configure an Identity Pool to authenticate the backend service, retrieve temporary AWS credentials, and use these credentials to sign the requests using Signature Version 4 while using IAM authorization on the API Gateway.

Create a User Pool with client credentials grant enabled, and configure a custom Lambda authorizer on the API Gateway to verify, decode, and parse the signature of the Cognito JSON Web Token (JWT).

Create a User Pool and configure a resource server with custom scopes. Enable the client credentials flow for the service's app client, and use the built-in Cognito authorizer on the API Gateway to validate the incoming access token.

Create a User Pool and an IAM role with a trust policy allowing API Gateway to assume it. Have the backend service exchange its user pool credentials for the IAM role using the AWS Security Token Service (STS) prior to each request.

Show answer & explanation

Answer: Create a User Pool and configure a resource server with custom scopes. Enable the client credentials flow for the service's app client, and use the built-in Cognito authorizer on the API Gateway to validate the incoming access token.

Answer

The correct option is the one that suggests creating a User Pool and configuring a resource server with custom scopes, enabling the client credentials flow, and utilizing the built-in Cognito authorizer on API Gateway. For machine-to-machine (M2M) communication without user intervention, the OAuth 2.0 client credentials grant is the industry standard. Amazon Cognito User Pools natively support this flow through resource servers. Additionally, API Gateway provides a built-in Cognito User Pool authorizer that automatically validates the signature and expiration of the access token, as well as checking custom scopes, minimizing custom code and operational overhead.

Step-by-Step Solution

Identify the client context and authentication flow.

The client is a backend machine-to-machine (M2M) service, which requires the OAuth 2.0 client credentials grant.

There is no user interaction, making standard user flows (like authorization code or implicit flows) unsuitable.

Select the appropriate Amazon Cognito resource type.

A Cognito User Pool is used, defining a resource server with custom scopes.

Cognito User Pools manage authentication and directories, and custom scopes allow application-level authorization. Cognito Identity Pools are meant for temporary AWS credential vending.

Configure the API Gateway authorization mechanism.

Utilize the built-in Amazon Cognito User Pool authorizer.

The built-in authorizer validates JWT access tokens automatically without the operational overhead of writing and maintaining a custom Lambda authorizer.

Key Concept

Machine-to-machine authentication using Cognito User Pools and API Gateway Cognito Authorizers

Estimated Time:1m 30s

Question 699Question →

A company needs to integrate an on-premises backend daemon service with a REST API hosted on AWS behind Amazon API Gateway. The daemon service must perform automated, non-interactive batch uploads to the API. Security requirements state that authentication must be handled via Amazon Cognito, leveraging OAuth 2.0 flows, and the service must be granted only the specific scope required for writing data (api/write). How should the developer configure Cognito and the daemon service to implement this authentication flow?

Create a Cognito Identity Pool that permits unauthenticated access. Have the daemon service exchange its client credentials for temporary AWS credentials using the Cognito Identity Pool API, and sign the HTTP requests to API Gateway using AWS Signature Version 4.

Configure a Cognito User Pool App Client with the Authorization Code grant. Implement a custom Lambda Authorizer on the API Gateway REST API to perform the OAuth 2.0 token exchange with Cognito, validate the returned ID token, and cache the authorization decision.

Configure a Cognito User Pool with an App Client that has a client secret, enabling the Client Credentials grant flow and defining a custom scope of 'api/write'. Have the daemon service request an access token from the Cognito token endpoint, and use a Cognito User Pool authorizer on API Gateway to validate the token.

Configure an IAM Role with a trust policy that allows the Cognito User Pool to assume the role. Instruct the daemon service to call the Cognito authentication endpoint to assume this IAM Role, and then use the returned temporary credentials to sign requests to API Gateway.

Show answer & explanation

Answer: Configure a Cognito User Pool with an App Client that has a client secret, enabling the Client Credentials grant flow and defining a custom scope of 'api/write'. Have the daemon service request an access token from the Cognito token endpoint, and use a Cognito User Pool authorizer on API Gateway to validate the token.

Answer

The Client Credentials grant flow is the standard OAuth 2.0 flow for machine-to-machine (M2M) or server-to-server authentication where no interactive user is present. By configuring a Cognito User Pool App Client with a client secret, enabling the Client Credentials flow, and defining custom resource scopes (like 'api/write'), the backend daemon service can securely request a JWT access token directly from the Cognito OAuth 2.0 token endpoint. API Gateway can then validate this access token natively using a Cognito User Pool Authorizer without requiring custom code.

Step-by-Step Solution

Create a Cognito User Pool and configure a Resource Server with the custom scope 'api/write'.

A user pool capable of scoping API access permissions for machine clients.

To define the access permissions required by the daemon service as an OAuth 2.0 scope.

Create an App Client within the User Pool, generate a client secret, and enable the 'Client Credentials' OAuth 2.0 grant.

An App Client with credentials suitable for non-interactive backend authentication.

To allow the daemon service to authenticate using its client ID and client secret directly.

Configure the API Gateway REST API with a Cognito User Pool Authorizer pointing to the created User Pool, and specify the required OAuth scope.

API Gateway will validate incoming access tokens and verify they contain the 'api/write' scope.

To secure the API endpoints and ensure only authorized clients can access the writing operations.

Program the daemon service to send a POST request to the Cognito domain's token endpoint (/oauth2/token) with its credentials, then attach the returned access token as a Bearer token in the API request headers.

The daemon service successfully authenticates and authorizes its requests to API Gateway.

To implement the standard client request and authentication flow for the daemon service.

Key Concept

Implementing machine-to-machine authentication using the Cognito User Pool Client Credentials grant flow and validating access tokens using an API Gateway Cognito User Pool Authorizer.

Estimated Time:2m 30s

Question 700Question →

A developer is implementing a security feature for a web application to encrypt sensitive transaction records using an AWS KMS customer managed key (CMK). During the `Encrypt` API call, the developer passes the transaction ID as part of the encryption context: `{"TransactionID": "TX-98765"}`. During a scheduled audit, an offline compliance service attempts to decrypt the transaction records using the AWS SDK. The service's IAM role has full permissions to call `kms:Decrypt` on the CMK, but the decryption requests fail with an `InvalidCiphertextException`. How should the developer resolve this issue?

Ensure that the compliance service includes the exact encryption context `{"TransactionID": "TX-98765"}` in its `Decrypt` API request.

Update the KMS key policy of the customer managed key to permit the compliance service to bypass the encryption context verification.

Store the encryption context value in AWS Systems Manager Parameter Store as a secure string and reference it in the service's IAM policy.

Call the `ReEncrypt` API to move the ciphertext to a different customer managed key that does not require an encryption context.

Show answer & explanation

Answer: Ensure that the compliance service includes the exact encryption context `{"TransactionID": "TX-98765"}` in its `Decrypt` API request.

Answer

Ensure that the compliance service includes the exact encryption context `{"TransactionID": "TX-98765"}` in its `Decrypt` API request.

The encryption context in AWS KMS acts as additional authenticated data (AAD) and is cryptographically bound to the ciphertext. To decrypt the data, the exact same encryption context (key-value pair) must be provided in the Decrypt API request. Without it, KMS cannot verify the integrity of the ciphertext and returns an InvalidCiphertextException.

Step-by-Step Solution

Analyze the error: `InvalidCiphertextException` when attempting to decrypt.

Identify that the key-value pair `{"TransactionID": "TX-98765"}` was provided as an encryption context during the `Encrypt` operation.

Any data encrypted with an encryption context requires the same context to be passed during decryption.

Review the API documentation for AWS KMS `Decrypt` operation.

Confirm that the `EncryptionContext` parameter must be supplied and match the one used during encryption.

The encryption context is bound as Additional Authenticated Data (AAD) to the ciphertext.

Configure the compliance service's decryption request to pass the `EncryptionContext` parameter.

The KMS `Decrypt` call succeeds, returning the plaintext record.

Matching the encryption context allows KMS to cryptographically authenticate and decrypt the payload.

Key Concept

AWS KMS Encryption Context behaves as Additional Authenticated Data (AAD) that must match exactly during decryption operations.

PreviousPage 35 / 78Next

All practice questions

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