Examkin

Security

390 questions

All types390Multiple choice195Multiple select195
Question 321Question →

A developer is implementing a serverless payment microservice using AWS Lambda. The microservice needs to securely access a third-party API key that must be rotated every 90 days. Which solution should the developer implement to manage and rotate this API key with the lowest operational overhead?

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager. Configure automatic rotation for the secret, and associate a custom AWS Lambda function to execute the rotation steps with the payment provider.

Answer

Store the API key in AWS Secrets Manager, configure automatic rotation, and associate a custom AWS Lambda function to handle the rotation lifecycle events with the third-party payment provider.
AWS Secrets Manager is designed to store, manage, and rotate secrets. For third-party APIs that do not have built-in rotation integration in AWS, Secrets Manager allows you to configure automatic rotation by invoking a custom AWS Lambda function. This custom function implements the rotation logic (e.g., creating a new key with the provider and updating the secret value) automatically on the set schedule, minimizing operational overhead.

Step-by-Step Solution

1
Identify the requirement for secure credential storage with automatic rotation for a third-party API key.
Determine that AWS Secrets Manager is the primary AWS service designed for secrets management and automated rotation of credentials.
AWS Systems Manager Parameter Store does not support native rotation, and embedding secrets in code or deployment packages violates security best practices.
2
Configure the rotation schedule in AWS Secrets Manager.
Enable automatic rotation for the secret and specify a rotation schedule of 90 days.
Secrets Manager requires an orchestration schedule to run the rotation process periodically.
3
Develop and associate a custom AWS Lambda function with the Secrets Manager secret.
The custom Lambda function handles the rotation steps: creating a new version of the secret, testing it against the third-party provider, and finalizing the rotation.
Standard automatic rotation templates exist for AWS databases, but custom APIs require a custom rotation Lambda function to communicate with the external service.

Key Concept

Secrets Management and Parameter Store
Question 322Question →

A developer is implementing a smart home mobile application. The mobile client needs to authenticate users and obtain temporary, limited-privilege AWS credentials to publish telemetry data directly to Amazon IoT Core MQTT topics.

Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Authenticate users using an Amazon Cognito User Pool. Configure an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials associated with an IAM role that permits publishing to AWS IoT Core.

Answer

Authenticate users using an Amazon Cognito User Pool. Configure an Amazon Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials associated with an IAM role that permits publishing to AWS IoT Core.
Using an Amazon Cognito User Pool for user authentication combined with an Amazon Cognito Identity Pool to exchange tokens for temporary AWS credentials is the standard, built-in AWS pattern. The Identity Pool handles the generation of temporary credentials via an IAM role with minimum operational overhead.

Step-by-Step Solution

1
Use Amazon Cognito User Pools for user sign-up and sign-in management.
Users are authenticated, and the mobile client receives JSON Web Tokens (JWTs).
Cognito User Pools serve as the identity provider to verify user identities.
2
Configure an Amazon Cognito Identity Pool and associate it with the Cognito User Pool as an authentication provider.
The client application can present the User Pool tokens to the Identity Pool in exchange for temporary AWS credentials.
Cognito Identity Pools provide authorization to AWS resources by vending temporary AWS credentials.
3
Assign an IAM role with permissions to publish to AWS IoT Core MQTT topics to the authenticated user role in the Identity Pool.
The mobile client uses the obtained temporary credentials to interact securely and directly with AWS IoT Core.
This implements the principle of least privilege using short-lived credentials, minimizing security risks and administrative overhead.

Key Concept

Amazon Cognito User Pools handle authentication (user directory and tokens), whereas Cognito Identity Pools handle authorization by exchanging those tokens for temporary AWS credentials.
Estimated Time:1m 30s
Question 323Question →

A developer is building a serverless web application that allows users to access corporate resources through a backend REST API hosted on Amazon API Gateway and powered by AWS Lambda. The developer has configured an Amazon Cognito User Pool to handle user authentication. The developer needs to secure the API Gateway endpoints so that only authenticated users can access them, and the backend Lambda function must retrieve the authenticated user's email address to record audit logs. The solution must minimize custom code and operational overhead.

Which two actions should the developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure an API Gateway Cognito User Pools authorizer on the API methods, specifying the Cognito User Pool as the identity source.; Use a Lambda proxy integration and access the user's email address from the requestContext.authorizer.claims.email field in the input event.

Answer

Configure an API Gateway Cognito User Pools authorizer on the API methods, specifying the Cognito User Pool as the identity source, and use a Lambda proxy integration to access the user's email address from the requestContext.authorizer.claims.email field in the input event.
The correct options implement the most efficient serverless pattern: using API Gateway's native Cognito User Pools authorizer to authenticate users and validate tokens at the API gateway layer, and then passing the identity claims to the backend Lambda function via the Lambda proxy integration's requestContext. This requires zero custom authorizer code and minimal backend logic to extract the user's email.

Step-by-Step Solution

1
Select Cognito User Pools as the authentication mechanism for API Gateway.
API Gateway validates tokens natively using the built-in Cognito authorizer.
This minimizes operational overhead by avoiding the need to write custom authorization logic.
2
Enable Lambda proxy integration for the API Gateway integration.
The entire HTTP request context, including authorizer metadata, is passed to the backend Lambda function.
API Gateway automatically populates the authorizer claims in the request event context, enabling the Lambda function to read the user's email.

Key Concept

API Gateway Cognito User Pool Authorizer integration with Lambda Proxy
Estimated Time:2m 0s
Question 324Question →

An organization requires a developer to build a secure configuration strategy for an application running on AWS Lambda. The application must connect to an Amazon RDS PostgreSQL database, which requires credentials to be rotated every 30 days. The application also needs to access non-sensitive service configuration parameters that change frequently. To minimize costs and management overhead, which of the following actions should the developer take? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation.; Store the non-sensitive service configuration parameters as standard parameters in AWS Systems Manager Parameter Store.

Answer

Store the database credentials in AWS Secrets Manager with automatic rotation configured, and store the non-sensitive service configuration parameters as standard parameters in AWS Systems Manager Parameter Store.
Storing database credentials in AWS Secrets Manager with automatic rotation configured satisfies the security requirement natively. Storing non-sensitive configuration parameters in AWS Systems Manager Parameter Store standard parameters satisfies the cost-effectiveness requirement, as standard parameters in Parameter Store do not incur any additional charges.

Step-by-Step Solution

1
Identify the storage requirements for the database credentials, which include secure storage and automatic rotation every 30 days.
Determine that AWS Secrets Manager is the appropriate service because it natively supports secret rotation for databases.
Systems Manager Parameter Store does not offer built-in automatic rotation.
2
Identify the storage requirements for the non-sensitive configuration parameters, which need to be updated frequently and stored cost-effectively.
Determine that Systems Manager Parameter Store standard parameters are the best choice since they are free.
Storing non-sensitive values in Secrets Manager incurs unnecessary costs.
3
Ensure secure SDK initialization inside the Lambda function without hardcoding credentials.
Determine that IAM roles should be used for authentication instead of passing hardcoded access keys in the code.
Hardcoding credentials in the SDK initialization violates security best practices.

Key Concept

Selecting the appropriate AWS service (Secrets Manager vs. Parameter Store) based on rotation requirements and cost-effectiveness, while adhering to secure credential management practices.
Question 325Question →

A company is creating a customer portal where registered users can log in and view their monthly account statements. These statements are stored in a private Amazon S3 bucket. The developer needs to implement a solution that authenticates users, manages their accounts, and provides them with temporary, limited-privilege AWS credentials to download their statements directly from S3.

Which Amazon Cognito configuration should the developer use to meet these requirements?

Show answer & explanation

Answer: Configure a Cognito User Pool to handle user registration and login, and associate it with a Cognito Identity Pool to exchange the identity token for temporary AWS credentials that allow S3 access.

Answer

Configure a Cognito User Pool to handle user registration and login, and associate it with a Cognito Identity Pool to exchange the identity token for temporary AWS credentials that allow S3 access.
The correct solution uses a Cognito User Pool to handle registration and authentication (acting as the user directory and producing identity tokens) and exchanges these tokens via a Cognito Identity Pool to obtain temporary AWS credentials with permissions to retrieve files from the Amazon S3 bucket.

Step-by-Step Solution

1
Identify the authentication and user management component.
Amazon Cognito User Pool is selected to act as the user directory and handle user registration, login, and token generation.
User Pools are designed to manage user identities, profiles, and authentication flows.
2
Identify the authorization component for accessing AWS services.
Amazon Cognito Identity Pool is selected to act as the credential broker.
Identity Pools exchange identity tokens (JWTs) from a User Pool (or other identity providers) for temporary, limited-privilege AWS credentials.
3
Define IAM permissions for the authenticated role.
Associate the authenticated IAM role in the Identity Pool with an IAM policy that allows read access to the specific S3 bucket.
This grants the temporary credentials the necessary permission to access the private S3 objects.

Key Concept

Cognito User Pools handle authentication (user directory), while Cognito Identity Pools handle authorization (temporary AWS credentials for AWS services).
Question 326Question →

A developer is implementing a custom Lambda authorizer for Amazon API Gateway. The authorizer must validate incoming JSON Web Tokens (JWT) using a secret client key that is updated manually every six months. The API receives millions of requests daily, and the developer wants to minimize AWS service costs associated with secret retrieval while maintaining security. Which strategy should the developer use?

Show answer & explanation

Answer: Store the secret client key as a SecureString parameter in AWS Systems Manager Parameter Store. Retrieve the parameter outside the Lambda handler function to cache it, and enable caching on the API Gateway authorizer.

Answer

Store the secret client key as a SecureString parameter in AWS Systems Manager Parameter Store, retrieve it outside the Lambda handler for caching, and enable authorizer caching in API Gateway.
Storing the key as a SecureString in Systems Manager Parameter Store satisfies the security requirement by encrypting the secret at rest with AWS KMS. Since the key is rotated manually every six months, the automatic rotation features of Secrets Manager are not needed. Choosing Parameter Store is highly cost-effective because standard parameters do not incur API request fees. Furthermore, caching the secret outside the Lambda handler ensures it is reused across warm container invocations, and enabling authorizer caching in API Gateway prevents invoking the Lambda function for every incoming client request.

Step-by-Step Solution

1
Evaluate the encryption and rotation requirements for the secret client key.
The key must be stored securely with encryption, but it is rotated manually every six months rather than requiring automatic rotation.
This determines whether the advanced automatic rotation features of AWS Secrets Manager are required.
2
Evaluate the scale and cost implications of the AWS services under a high-volume request load.
Secrets Manager charges per API call, which is expensive at millions of requests per day. Systems Manager Parameter Store standard parameters provide SecureString encryption using AWS KMS keys without per-request charges.
This identifies Parameter Store as the most cost-effective option for manually rotated secrets at scale.
3
Optimize key retrieval performance and rate limiting.
Retrieve the Parameter Store value outside the Lambda handler to cache the value across execution contexts, and enable caching on the API Gateway authorizer.
This reduces latency, prevents API rate-limiting issues on Parameter Store, and minimizes Lambda executions.

Key Concept

Parameter Store vs Secrets Manager cost and features trade-offs
Estimated Time:1m 30s
Question 327Question →

A developer is building an enterprise web application. The application must authenticate corporate users using an external SAML 2.0 Identity Provider (IdP) and provide them with access to two resources: a secure REST API hosted on Amazon API Gateway, and a private Amazon S3 bucket for uploading reports directly from the client.

Which TWO configurations are required to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool with the external SAML Identity Provider (IdP) to handle user authentication, and set up an API Gateway Cognito Authorizer using the User Pool's tokens.; Configure an Amazon Cognito Identity Pool that uses the User Pool as an identity provider, and assign an authenticated IAM role with write permissions to the Amazon S3 bucket.

Answer

Configure an Amazon Cognito User Pool with the external SAML Identity Provider (IdP) to handle user authentication, and set up an API Gateway Cognito Authorizer using the User Pool's tokens. In addition, configure an Amazon Cognito Identity Pool that uses the User Pool as an identity provider, and assign an authenticated IAM role with write permissions to the Amazon S3 bucket.
The correct architecture uses an Amazon Cognito User Pool to federate authentication with the SAML Identity Provider (IdP) and secures the API Gateway using a Cognito Authorizer with the generated JWT. It also uses an Amazon Cognito Identity Pool (Federated Identities) to exchange the User Pool JWT for temporary AWS credentials defined by an authenticated IAM role, enabling the client application to upload reports directly to Amazon S3.

Step-by-Step Solution

1
Federate SAML 2.0 IdP with Cognito User Pool
Users can authenticate against the corporate directory, and Cognito User Pool issues ID and access JWT tokens to the client.
This establishes user identity and generates tokens to verify the user's session.
2
Secure the API Gateway REST API with a Cognito User Pool Authorizer
API Gateway automatically validates the Cognito JWT token on incoming requests.
This verifies that the caller has been authenticated by the User Pool before forwarding the request to downstream services.
3
Configure a Cognito Identity Pool linked to the User Pool
The Identity Pool validates the User Pool ID token and maps the authenticated user to an IAM role.
This enables the exchange of the Cognito JWT for temporary, limited-privilege AWS credentials (access key, secret key, session token) which are required to write objects directly to the Amazon S3 bucket.

Key Concept

Integration of Cognito User Pools for user directory/federation and Cognito Identity Pools for temporary AWS credential delegation.
Question 328Question →

A developer is building a web application where users sign in via social identity providers. The application needs to call a backend REST API on Amazon API Gateway, and also allow users to upload user profile photos directly to a private Amazon S3 bucket.

Which Cognito configuration meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Configure a Cognito User Pool to handle user sign-in and social provider federation. Secure the REST API using an API Gateway Cognito user pool authorizer. Use a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials to authorize direct S3 uploads.

Answer

Configure a Cognito User Pool to handle user sign-in and social provider federation. Secure the REST API using an API Gateway Cognito user pool authorizer. Use a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS credentials to authorize direct S3 uploads.
The correct configuration uses a Cognito User Pool for user sign-in and identity federation, securing API Gateway endpoints using a built-in Cognito authorizer which natively validates the JSON Web Tokens (JWTs). It then uses a Cognito Identity Pool to trade the authenticated User Pool token for temporary AWS IAM credentials, allowing the application client to perform direct uploads to S3 with minimal operational overhead.

Step-by-Step Solution

1
Identify the authentication and user management component.
A Cognito User Pool is selected to manage user profiles, sign-ins, and social identity provider federation.
User Pools act as the primary user directory and issue identity tokens.
2
Select the API authorization mechanism.
Use the built-in API Gateway Cognito user pool authorizer to validate the JWTs sent by the client.
This integration handles token validation automatically with zero custom code or Lambda overhead.
3
Determine how the client obtains credentials for direct S3 access.
Configure a Cognito Identity Pool that trusts the Cognito User Pool, allowing the client to exchange its user token for temporary AWS IAM credentials.
Amazon S3 requires AWS IAM credentials for secure client-side uploads, which is the primary purpose of Identity Pools.

Key Concept

Federating user sign-in with Cognito User Pools and obtaining temporary AWS credentials via Cognito Identity Pools for S3 access.
Question 329Question →

A developer is designing a collaborative document editing web application. The application authenticates users using an Amazon Cognito User Pool. The backend APIs are hosted on Amazon API Gateway. The developer wants to restrict access to a specific API Gateway resource method (POST /documents) so that only users belonging to the 'Editors' Cognito User Pool group can invoke it.

Which TWO configurations would allow the developer to implement this group-based authorization?

Select all that apply

Show answer & explanation

Answer: Configure the API Gateway resource method to use AWS_IAM authorization. Configure an Amazon Cognito Identity Pool to map Cognito User Pool groups to distinct IAM roles, and configure the application to sign the API requests with the temporary credentials obtained from the Identity Pool.; Create an API Gateway Lambda Authorizer. Program the Lambda function to validate the User Pool JWT token, extract the cognito:groups claim, and dynamically generate an IAM policy that grants or denies execution permissions for the method based on the group membership.

Answer

The developer can implement group-based authorization by configuring the API Gateway method to use AWS_IAM authorization combined with a Cognito Identity Pool mapping groups to IAM roles, or by implementing an API Gateway Lambda Authorizer that inspects the cognito:groups claim inside the JWT token to generate a dynamic IAM policy.
Group-based authorization in Amazon API Gateway cannot be natively enforced using only the built-in Cognito User Pool authorizer. To restrict resource access to specific Cognito groups, two approaches are valid. The first is to set up a Cognito Identity Pool that maps User Pool groups to distinct IAM roles, secure the API Gateway methods with AWS_IAM, and have the client sign requests using temporary credentials. The second is to implement an API Gateway Lambda Authorizer. This custom authorizer validates the token, extracts the group claims from the token's claims, and outputs an IAM policy that allows or denies the execution of the requested method.

Step-by-Step Solution

1
Determine where the authorization check should occur.
Authorization should occur at the API Gateway layer before invoking backend resources to avoid unnecessary invocation costs and latency.
This rules out executing database checks or calling identity administration APIs inside the backend integration.
2
Evaluate Cognito Identity Pools role-mapping.
Cognito Identity Pools allow mapping Cognito User Pool groups directly to IAM roles. These roles contain policies that permit or deny actions on API Gateway resource methods (execute-api:Invoke).
The client uses these mapped roles to obtain temporary AWS credentials and signs the HTTP request to API Gateway.
3
Evaluate custom Lambda Authorizers.
A Lambda Authorizer intercepts API requests, decodes the JWT token sent by the client, reads the groups from the token payload, and constructs a standard IAM policy dynamically.
This provides fine-grained control directly in code without requiring clients to obtain temporary AWS credentials.

Key Concept

Amazon Cognito Group-Based API Authorization
Estimated Time:1m 30s
Question 330Question →

A developer has configured an AWS Lambda function in Account A (123456789012) to access resources in Account B (987654321098) by assuming an IAM role named CrossAccountAccessRole in Account B. The developer attached an IAM policy to the Lambda execution role in Account A that permits the sts:AssumeRole action. However, when the Lambda function runs and attempts to assume the role, the API call fails with an AccessDenied error.

The trust policy for CrossAccountAccessRole in Account B is configured as follows:

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

Which modification must the developer make to resolve this error?

Show answer & explanation

Answer: Modify the trust policy of CrossAccountAccessRole in Account B to specify the ARN of the Lambda function's execution role from Account A as the principal.

Answer

Modify the trust policy of CrossAccountAccessRole in Account B to specify the ARN of the Lambda function's execution role from Account A as the principal.
The correct action is to modify the trust policy of the role in Account B to trust the ARN of the Lambda execution role in Account A. When a Lambda function runs, it uses its execution role's credentials to call other AWS services. In this case, the SDK call to assume the cross-account role comes from the Lambda execution role, not the Lambda service principal. Therefore, the trust policy of the target role in Account B must list the execution role's ARN as the trusted principal.

Step-by-Step Solution

1
Determine the identity calling the sts:AssumeRole API.
The AWS SDK call within the running Lambda function uses the credentials of the Lambda function's execution role from Account A.
When code runs inside Lambda, it adopts the execution role's permissions, so any outgoing API calls are signed by that role.
2
Analyze the trust policy of the target role in Account B.
The current trust policy only trusts the service principal 'lambda.amazonaws.com'.
This allows the Lambda service itself to assume the role, but not the specific execution role of a function.
3
Update the trust policy in Account B to allow the cross-account assumption.
Change the principal from 'lambda.amazonaws.com' to the ARN of the Lambda execution role from Account A.
This establishes trust between the target role in Account B and the calling role in Account A, resolving the AccessDenied error.

Key Concept

IAM Role Trust Policies vs. Permissions Policies
Question 331Question →

A developer is configuring an AWS Lambda function in Account A (111122223333) to send logs and processing data directly to an Amazon SQS queue located in Account B (444455556666). The Lambda function is associated with an IAM execution role named LambdaSQSSenderRole. When the Lambda function attempts to call the SQS SendMessage API, it receives an AccessDeniedException. Which two actions are required to resolve this authorization issue and allow the Lambda function to send messages to the queue? (Select two.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the LambdaSQSSenderRole in Account A that allows the sqs:SendMessage action on the ARN of the SQS queue in Account B.; Configure the queue policy on the SQS queue in Account B to allow the sqs:SendMessage action with the Principal set to the LambdaSQSSenderRole ARN.

Answer

Attach an IAM policy to the LambdaSQSSenderRole in Account A that allows the sqs:SendMessage action on the ARN of the SQS queue in Account B, and configure the queue policy on the SQS queue in Account B to allow the sqs:SendMessage action with the Principal set to the LambdaSQSSenderRole ARN.
For cross-account access to resource-based services like SQS, permissions must be granted on both sides. The caller in Account A (the Lambda execution role) must be allowed by its identity policy to send messages to the external queue. Simultaneously, the resource policy in Account B (the SQS queue policy) must allow the execution role from Account A to write to the queue.

Step-by-Step Solution

1
Configure identity-based policy in Account A
The Lambda function's execution role has outbound permissions to send messages to the external SQS queue.
By default, IAM execution roles do not have permission to write to resources in other accounts. An identity-based policy must explicitly grant the sqs:SendMessage action on the destination SQS queue ARN.
2
Configure resource-based policy in Account B
The SQS queue allows incoming messages from the execution role in Account A.
For cross-account access, both the identity-based policy in the source account and the resource-based policy in the target account must permit the access. The SQS queue policy must specify the IAM role ARN as the principal.

Key Concept

Cross-account resource access requires authorization in both the source account's identity-based policy and the target account's resource-based policy.
Question 332Question →

An application deployed on AWS Batch needs to retrieve two types of configuration values: database credentials that must be automatically rotated every 30 days, and non-sensitive application settings (such as logging levels and API endpoints) that do not require rotation. Which combination of actions should the developer take to retrieve these values securely, cost-effectively, and with minimal operational overhead? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in rotation templates.; Store the logging level and API endpoints in AWS Systems Manager Parameter Store.

Answer

Store the database credentials in AWS Secrets Manager with automatic rotation configured, and store the non-sensitive parameters (logging level and API endpoints) in AWS Systems Manager Parameter Store.
The correct strategy combines AWS Secrets Manager and AWS Systems Manager Parameter Store. Storing database credentials in AWS Secrets Manager allows utilizing its native automatic rotation feature to change passwords every 30 days without custom scripts. Storing non-sensitive configuration data, such as logging levels and API endpoints, in Parameter Store is highly cost-effective and avoids the monthly per-secret cost of Secrets Manager.

Step-by-Step Solution

1
Analyze rotation and security requirements.
Database credentials require secure storage and automatic rotation, while logging levels and API endpoints are non-sensitive and do not require rotation.
This determines which AWS service provides the best combination of security, features, and cost efficiency.
2
Select the service for credentials.
AWS Secrets Manager is chosen for the database credentials.
Secrets Manager has built-in integration to rotate credentials automatically and securely.
3
Select the service for non-sensitive configurations.
AWS Systems Manager Parameter Store is chosen for logging levels and API endpoints.
Parameter Store is more cost-effective for configuration data that does not require rotation or advanced secrets management features.

Key Concept

Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on security, rotation requirements, and cost optimization.
Estimated Time:1m 30s
Question 333Question →

A developer is implementing an AWS Lambda function in Account A (123456789012123456789012) that needs to assume a specific IAM role named `TargetTaskRole` within the same account to perform administrative tasks. The Lambda function is configured with an execution role named `LambdaExecutionRole`.

The current trust policy of `TargetTaskRole` is configured as follows:

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

During execution, the function code calls `sts:AssumeRole` for `TargetTaskRole` and fails with the following error:
`An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::123456789012:assumed-role/LambdaExecutionRole/my-function is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::123456789012:role/TargetTaskRole`

Which of the following configurations are required to resolve this error? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a permissions policy to the execution role `LambdaExecutionRole` that allows the `sts:AssumeRole` action on `arn:aws:iam::123456789012:role/TargetTaskRole`.; Update the trust policy of `TargetTaskRole` to add the execution role ARN `arn:aws:iam::123456789012:role/LambdaExecutionRole` as a trusted principal.

Answer

To resolve the AccessDenied error, the developer must grant the Lambda execution role permissions to assume the target role by adding an identity-based permissions policy, and configure the target role's trust policy to trust the Lambda execution role's ARN.
To assume an IAM role, permissions must be granted on both sides: the caller's permission policy must allow calling `sts:AssumeRole` on the target role, and the target role's trust policy must specify the caller's ARN as a trusted principal.

Step-by-Step Solution

1
Add an identity-based permissions policy to the execution role.
The Lambda execution role has permission to invoke the `sts:AssumeRole` API on the target role resource.
By default, IAM roles do not have permissions to assume other roles.
2
Modify the target role's trust policy.
The target role trusts the execution role's ARN as a principal.
An IAM role can only be assumed by identities that are explicitly listed in its trust relationship policy.

Key Concept

IAM trust relationships and permission boundaries when assuming roles.
Question 334Question →

A developer is building a command-line interface (CLI) tool that internal engineers will use to upload software builds directly to a private Amazon S3 bucket. The engineers authenticate with the company's external OpenID Connect (OIDC) identity provider. The CLI tool needs to obtain temporary AWS credentials to write to the S3 bucket directly.

Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Configure an Amazon Cognito Identity Pool, register the OIDC identity provider, and link it to an IAM role that grants write access to the S3 bucket.

Answer

Configure an Amazon Cognito Identity Pool, register the OIDC identity provider, and link it to an IAM role that grants write access to the S3 bucket.
The correct configuration uses an Amazon Cognito Identity Pool to federate with the OIDC identity provider. This pool directly exchanges OIDC tokens for temporary AWS IAM credentials, allowing the CLI tool to call the Amazon S3 PutObject API directly using an associated IAM role with minimum operational overhead and no custom code.

Step-by-Step Solution

1
Determine the authentication source and the authorization target.
The CLI authentication is managed by an external OpenID Connect (OIDC) identity provider, and the target is Amazon S3, which requires AWS IAM credentials.
Establishing the input and output requirements helps choose the right Cognito resource.
2
Differentiate between Cognito User Pools and Identity Pools for AWS resource authorization.
Cognito User Pools manage user directory and authentication tokens (JWTs), while Cognito Identity Pools exchange external identity tokens for temporary AWS credentials.
Since the CLI tool must authenticate directly to Amazon S3 using AWS credentials, an Identity Pool is the required service.
3
Select the configuration that minimizes custom integration and operational overhead.
Configuring a Cognito Identity Pool to map OIDC users to an IAM role is a native, serverless configuration requiring zero custom code.
This meets the objective of minimizing operational overhead and avoiding unnecessary intermediate proxies.

Key Concept

Amazon Cognito Identity Pools (Federated Identities) are used to exchange credentials from external identity providers (such as OIDC, SAML, or social IdPs) for temporary, limited-privilege AWS credentials to directly access AWS resources like Amazon S3.
Question 335Question →

A developer is building a serverless mobile application for fitness tracking. The application needs to authenticate users using an external OpenID Connect (OIDC) identity provider. Once authenticated, the application must allow users to call an Amazon API Gateway REST API and upload workout logs directly to their own private folders in an Amazon S3 bucket. Which TWO configurations should the developer implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Set up an Amazon Cognito User Pool and federate it with the OIDC identity provider. Configure the API Gateway REST API to use a Cognito authorizer linked to the User Pool.; Set up an Amazon Cognito Identity Pool and configure the Cognito User Pool as an identity provider. Associate an authenticated IAM role with the Identity Pool that allows s3:PutObject for the uploads/\${cognito-identity.amazonaws.com:sub}/ prefix.

Answer

To meet the requirements, the developer must configure an Amazon Cognito User Pool federated with the OIDC provider to authenticate users and secure the API Gateway REST API with a Cognito authorizer. Additionally, the developer must configure an Amazon Cognito Identity Pool with the User Pool as an identity provider, associating an IAM role that grants permissions to the user's S3 folder using the cognito-identity.amazonaws.com:sub variable.
The correct approach integrates both Cognito User Pools and Identity Pools. The User Pool handles OIDC authentication and issues JWT tokens, which the API Gateway Cognito Authorizer verifies. The Identity Pool then takes the User Pool ID token and exchanges it for temporary IAM credentials. The attached IAM policy uses the dynamic variable to restrict S3 uploads to the authenticated user's prefix.

Step-by-Step Solution

1
Federate the OIDC provider with a Cognito User Pool and configure the API Gateway Cognito Authorizer.
Users can log in using their OIDC identity, and the User Pool will issue JWT tokens that API Gateway validates natively.
This establishes user authentication and secures the API Gateway backend without custom authorization code.
2
Configure a Cognito Identity Pool using the User Pool as an authentication provider.
The client app can exchange the User Pool tokens for temporary AWS IAM credentials.
This bridges user authentication with AWS resource authorization.
3
Attach a fine-grained IAM policy to the authenticated role of the Cognito Identity Pool.
The IAM policy allows s3:PutObject only to the prefix uploads/\${cognito-identity.amazonaws.com:sub}/.
This restricts users so they can only write files to their own individual S3 folders using secure temporary credentials.

Key Concept

Integrating Amazon Cognito User Pools for user authentication/federation and Cognito Identity Pools for authorizing direct access to AWS resources like Amazon S3 using temporary AWS credentials.
Question 336Question →

A company is deploying a microservices-based application on Amazon Elastic Container Service (Amazon ECS). The application requires access to two types of data: database credentials for an Amazon RDS database that must be rotated automatically every 14 days, and a non-sensitive configuration setting indicating the application's logging level. The developer wants to implement a secure solution that minimizes both management overhead and overall cost. Which of the following actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in integration for Amazon RDS.; Store the logging level configuration in Systems Manager Parameter Store as a Standard parameter to optimize costs.

Answer

Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in integration for Amazon RDS, and store the logging level configuration in Systems Manager Parameter Store as a Standard parameter to optimize costs.
The correct options involve storing the database credentials in AWS Secrets Manager and the logging level in Systems Manager Parameter Store. AWS Secrets Manager natively integrates with Amazon RDS to provide automatic credential rotation without manual overhead, which satisfies the 14-day rotation requirement. Systems Manager Parameter Store Standard parameters are free of charge, making them the most cost-effective choice for storing non-sensitive configuration settings like application logging levels.

Step-by-Step Solution

1
Evaluate the database credential requirements for automatic rotation.
AWS Secrets Manager is selected because it has built-in integration with Amazon RDS to rotate credentials automatically without manual coding.
This satisfies the security requirement for rotating credentials every 14 days with minimal administrative overhead.
2
Evaluate the configuration setting requirement for cost-effectiveness.
Systems Manager Parameter Store is selected because Standard parameters are free of charge and suitable for non-sensitive data.
This minimizes overall costs by avoiding the hosting fees associated with AWS Secrets Manager for non-sensitive configuration data.

Key Concept

Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on rotation capabilities and cost optimization.
Estimated Time:1m 30s
Question 337Question →

An application running on an Amazon EC2 instance is designed to fetch daily configuration files from a private Amazon S3 bucket. During deployment, the application throws an Access Denied exception when attempting to call the `s3:GetObject` API operation. The developer has attached a policy with the required S3 permissions to an IAM role called `S3ReaderRole`, which is associated with the instance profile. Upon inspecting the role's trust policy, the developer finds the following configuration:

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

Which of the following modifications should the developer make to resolve this access issue?

Show answer & explanation

Answer: Modify the trust policy of the S3ReaderRole to change the service principal in the Principal block to ec2.amazonaws.com.

Answer

Modify the trust policy of the S3ReaderRole to change the service principal in the Principal block to ec2.amazonaws.com.
Modifying the trust policy of the IAM role to change the service principal to ec2.amazonaws.com is correct because it grants the EC2 service permission to assume the role. The trust policy defines which entities (in this case, the EC2 service) are allowed to assume the role to obtain temporary credentials. Since the application is running on EC2, the role's trust policy must trust EC2, not Lambda.

Step-by-Step Solution

1
Identify the execution environment of the application and the resource it is attempting to access.
The application is running on an Amazon EC2 instance and needs to read files from an Amazon S3 bucket.
Understanding the execution context helps determine which service principal must assume the IAM role.
2
Examine the current IAM trust policy configuration of the role associated with the EC2 instance.
The trust policy currently has the Principal.Service set to lambda.amazonaws.com.
This principal only allows the AWS Lambda service to assume the role, preventing EC2 from obtaining the necessary temporary security credentials.
3
Update the trust policy to reference the correct service principal.
Change the Principal.Service element value to ec2.amazonaws.com.
This allows the EC2 service principal to assume the role, enabling the EC2 instance profile to fetch and hand over temporary credentials to the running application.

Key Concept

IAM Trust Policies vs. Permissions Policies
Question 338Question →

A developer is building a serverless orchestration workflow using AWS Step Functions. One of the workflow's task states invokes an AWS Lambda function that integrates with a third-party merchant API. The merchant API requires a secure API key for authentication. The company's security policy requires that this API key be rotated every 30 days. Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager. Configure automatic rotation for the secret on a 30-day schedule using a rotation Lambda function, and configure the integration Lambda function to retrieve the secret at runtime.

Answer

Store the API key in AWS Secrets Manager. Configure automatic rotation for the secret on a 30-day schedule using a rotation Lambda function, and configure the integration Lambda function to retrieve the secret at runtime.
The correct option is to use AWS Secrets Manager with its built-in automatic rotation feature, configured with a rotation Lambda function on a 30-day schedule. AWS Secrets Manager is specifically designed for managing, rotating, and retrieving secrets securely at runtime, which satisfies the requirements with the lowest operational overhead.

Step-by-Step Solution

1
Evaluate the need for encryption and automatic rotation of credentials.
Identify that AWS Secrets Manager is the standard service designed to handle secrets requiring automatic rotation natively.
Systems Manager Parameter Store does not offer native automatic rotation out of the box.
2
Compare Secrets Manager and Systems Manager Parameter Store for custom third-party secrets.
Choose Secrets Manager because it supports automatic rotation via custom Lambda functions, minimizing custom orchestration code.
Implementing rotation in Parameter Store requires custom EventBridge rules and manual orchestration, increasing operational overhead.
3
Ensure the integration Lambda function retrieves the secret at runtime.
Avoid hardcoding or environment variables that complicate rotation and compromise security.
Retrieving the secret at runtime ensures that rotation does not break the integration Lambda function.

Key Concept

Secrets Manager vs Systems Manager Parameter Store Rotation Capabilities
Estimated Time:1m 30s
Question 339Question →

A developer is setting up an AWS Lambda function that needs to retrieve and write items to an Amazon DynamoDB table in the same AWS account. The developer creates an IAM role named `LambdaDbAccessRole` to be used as the function's execution role. However, when attempting to save the Lambda function configuration, the developer receives an error stating that the AWS Lambda service is not authorized to assume the role. The developer checks the trust policy currently attached to `LambdaDbAccessRole` and finds the following document:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Products"
}
]
}

How should the developer resolve this issue to allow the Lambda function to execute and interact with the DynamoDB table?

Show answer & explanation

Answer: Update the trust policy of `LambdaDbAccessRole` to allow the `lambda.amazonaws.com` service principal to perform the `sts:AssumeRole` action, and attach a separate identity-based permissions policy containing the DynamoDB actions to the role.

Answer

Update the trust policy of the execution role to allow the AWS Lambda service principal to assume the role, and attach a separate permissions policy to the role for DynamoDB access.
The trust policy of an IAM role defines which principals are allowed to assume it. For AWS Lambda to assume the execution role, the trust policy must allow the `lambda.amazonaws.com` service principal to perform the `sts:AssumeRole` action. The permissions to read and write to the DynamoDB table must be defined in a separate identity-based permissions policy attached to the role.

Step-by-Step Solution

1
Analyze the error message showing that AWS Lambda is not authorized to assume the role.
Identify that the trust policy must explicitly allow the `lambda.amazonaws.com` service principal to perform `sts:AssumeRole`.
Before a Lambda function can execute, the AWS Lambda service must be allowed to assume its execution role.
2
Identify that the current trust policy document contains DynamoDB table actions instead of assumption actions.
Determine that these actions cannot remain in a trust policy because trust policies only control role assumption.
Trust policies are resource policies on the IAM role itself, meant only to authorize trusted principals to assume the role.
3
Separate trust relationships from identity permissions.
Move the DynamoDB actions to a standard identity-based permissions policy attached to the role, and configure the trust policy for `sts:AssumeRole`.
This configuration adheres to the AWS security model, where trust policies govern who can assume a role, and permissions policies govern what the assumed role can access.

Key Concept

Separation of IAM Trust Policies (defining which trust entities can assume the role) and Permissions Policies (defining access rights to AWS resources).
Question 340Question →

A software engineer is configuring security for a web application where clients send requests to a REST API hosted on Amazon API Gateway. The application uses an Amazon Cognito User Pool for user authentication. The engineer must restrict access to the REST API so that only authenticated users with a valid JSON Web Token (JWT) can call the endpoints, without writing custom code to decode or validate the tokens. Which solution meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Configure an Amazon Cognito authorizer on the API Gateway REST API, referencing the User Pool, and pass the identity token in the request header.

Answer

Configure an Amazon Cognito authorizer on the API Gateway REST API, referencing the User Pool, and pass the identity token in the request header.
The correct solution uses an API Gateway Cognito authorizer linked to the Amazon Cognito User Pool. This is a built-in feature that automatically validates incoming JWT tokens (such as the ID token) without requiring any custom Lambda code, meeting all constraints with the lowest operational overhead.

Step-by-Step Solution

1
Identify the requirement to authenticate users using Amazon Cognito User Pools and authorize access to API Gateway without custom code.
Confirm that user identity validation must occur at the API Gateway layer without custom validation logic.
This helps narrow down the solutions to native integration options on API Gateway.
2
Evaluate built-in API Gateway authorizers and note that a Cognito Authorizer natively integrates with Cognito User Pools to validate tokens automatically.
Determine that the Amazon Cognito authorizer is the built-in mechanism designed for this specific scenario.
Using a native feature avoids the development and operational overhead of custom code or identity pools.
3
Pass the identity token (ID token) or access token generated by the User Pool in the request header (commonly Authorization) to the Cognito authorizer.
API Gateway automatically decodes, verifies, and validates the incoming token against the configured User Pool.
This ensures only authenticated clients with valid tokens are allowed to invoke the backend service.

Key Concept

API Gateway integration with Amazon Cognito User Pools using Cognito Authorizers
Estimated Time:1m 30s
PreviousPage 17 / 20Next