Examkin

Security

390 questions

All types390Multiple choice195Multiple select195
Question 221Question →

A developer is building a mobile game that needs to save user progress data directly to an Amazon DynamoDB table. Users must first authenticate, and the application must then obtain temporary, limited-privilege AWS credentials to authorize write operations to the DynamoDB table. Which Amazon Cognito feature should the developer use to obtain these temporary AWS credentials?

Show answer & explanation

Answer: Cognito Identity Pools

Answer

Cognito Identity Pools
Cognito Identity Pools (Federated Identities) are specifically designed to authorize users by exchanging authentication tokens (from Cognito User Pools or social providers) for temporary, limited-privilege AWS credentials. This allows mobile applications to call AWS services directly, such as writing to DynamoDB, using the permissions defined in the assumed IAM role.

Step-by-Step Solution

1
Identify the authentication and authorization requirements.
The application requires authentication to verify identity, and then authorization using temporary AWS credentials to write directly to DynamoDB.
Determining whether the client needs direct AWS resource access versus REST API access helps select the correct Cognito feature.
2
Differentiate between User Pools and Identity Pools.
Cognito User Pools provide user directories and authentication (JWTs). Cognito Identity Pools provide authorization by exchanging authentication tokens for temporary AWS credentials.
Selecting the feature that specifically generates temporary credentials ensures secure, direct SDK access to AWS services.

Key Concept

Amazon Cognito Identity Pools vs User Pools for AWS resource access
Estimated Time:45s
Question 222Question →

A developer is implementing application-side encryption for sensitive user profile data. When calling the AWS KMS `Encrypt` API, the developer includes an encryption context: `{"AppName": "UserProfileService"}`. The encrypted ciphertext is stored in a database. When the developer later attempts to decrypt this ciphertext using the AWS SDK, how must the encryption context be handled?

Show answer & explanation

Answer: The identical encryption context must be passed in the decryption API call; otherwise, AWS KMS will reject the request with an InvalidCiphertextException.

Answer

The identical encryption context must be passed in the decryption API call; otherwise, AWS KMS will reject the request with an InvalidCiphertextException.
When an encryption context is provided in an AWS KMS encryption request, it is cryptographically bound to the ciphertext as Additional Authenticated Data (AAD). To decrypt the ciphertext, the exact same encryption context (case-sensitive key-value pairs) must be supplied in the decryption request. If the context does not match, AWS KMS cannot decrypt the payload and returns an InvalidCiphertextException error.

Step-by-Step Solution

1
Analyze how AWS KMS handles encryption context during the `Encrypt` API call.
The encryption context is cryptographically bound to the ciphertext as Additional Authenticated Data (AAD) to ensure integrity.
This establishes that the encryption context is not merely metadata but a vital part of the cryptographic envelope.
2
Determine the requirements for the subsequent `Decrypt` API call.
The Decrypt request must include the exact same encryption context (key-value pairs) used during encryption.
If there is any mismatch in the keys or values, AWS KMS will fail to authenticate the payload and reject the request with an InvalidCiphertextException.

Key Concept

AWS KMS Encryption Context behaves as Additional Authenticated Data (AAD), requiring an exact, case-sensitive match during Decrypt operations to verify ciphertext integrity.
Estimated Time:1m 30s
Question 223Question →

A developer is deploying an application on an Amazon EC2 instance that needs to read data from an Amazon DynamoDB table and write reports to an Amazon S3 bucket. To follow security best practices, the developer decides to use an IAM role. Which two configurations are required to establish this access? (Select two.)

Select all that apply

Show answer & explanation

Answer: Create an IAM role with an identity-based permissions policy that grants DynamoDB read access and S3 write access.; Configure the IAM role's trust policy to allow the Amazon EC2 service to assume the role.

Answer

An IAM role must be configured with an identity-based permissions policy that grants DynamoDB read access and S3 write access, and its trust policy must allow the Amazon EC2 service to assume the role.
To grant an EC2 instance access to other AWS services securely, two components are required. First, the trust policy of the IAM role must permit the EC2 service principal to assume the role. Second, the role's permissions policy must define the specific resource-level permissions (DynamoDB read and S3 write) that the application needs to run.

Step-by-Step Solution

1
Define the permissions policy for the IAM role.
An identity-based permissions policy is created allowing action permissions like DynamoDB Read and S3 Write.
This determines what operations the application can perform after assuming the role.
2
Configure the trust relationship of the IAM role.
The trust policy is set to allow 'ec2.amazonaws.com' as the trusted entity.
This permits the Amazon EC2 service to assume the role and issue temporary security credentials to the instance.

Key Concept

An IAM role requires both a trust policy (specifying who can assume the role) and a permissions policy (specifying what resources and actions the role can access).
Question 224Question →

A media streaming company is designing a new REST API using Amazon API Gateway to serve premium video content metadata to web clients. Users log in using their corporate identities federated with an Amazon Cognito User Pool. The developer wants to restrict access to the API Gateway resources based on this authentication. The backend is implemented using AWS Lambda functions with custom integrations (non-proxy integration). The solution must validate tokens at the API Gateway boundary and pass the authenticated user's claims to the backend with minimal custom validation code. Which two steps should the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure a COGNITO_USER_POOLS authorizer on the API Gateway method, specify the Amazon Cognito User Pool ARN, and pass the token in the identity source header.; Configure an API Gateway integration mapping template to extract the user claims from the $context.authorizer.claims variable and inject them into the request payload sent to the Lambda function.

Answer

Configure a COGNITO_USER_POOLS authorizer on the API Gateway method and use an API Gateway integration mapping template to map the $context.authorizer.claims variable to the Lambda function payload.
To secure the API with minimal overhead, a native Cognito User Pools authorizer must be configured. This authorizer validates JWTs at the API Gateway level before executing the backend. For Lambda custom integrations, mapping templates are required to forward claims (such as user profile and groups) stored in the $context.authorizer.claims context variable to the Lambda function input.

Step-by-Step Solution

1
Configure the API Gateway method authentication.
Create and configure a Cognito User Pools authorizer on the API Gateway method, pointing to the User Pool ARN, to handle JWT validation natively.
This offloads token validation to API Gateway natively, ensuring unauthorized requests are rejected at the edge with zero custom code.
2
Map the authorizer context to the backend.
Define an API Gateway integration mapping template for the request integration.
Since the backend uses a custom integration (non-proxy), mapping templates are required to extract claims from the authorizer context using $context.authorizer.claims and pass them as JSON fields to the Lambda function.

Key Concept

API Gateway provides native integration with Cognito User Pools via COGNITO_USER_POOLS authorizers, which validate JWTs without custom code. When using custom (non-proxy) integrations, mapping templates are required to forward authorizer claims from API Gateway to the backend Lambda function.
Question 225Question →

A developer is building a fitness tracking mobile application that uses an Amazon API Gateway REST API backed by AWS Lambda. The developer needs to secure the API so that only authenticated users can access their workout logs. The authentication system must use Amazon Cognito User Pools, and the API Gateway should directly validate the JSON Web Tokens (JWT) sent in the HTTP Authorization header without calling custom validation code. Which two configuration steps must the developer perform to implement this security control?

Select all that apply

Show answer & explanation

Answer: Create an Amazon API Gateway authorizer of type Cognito, referencing the Cognito User Pool ID and setting the token source header to Authorization.; Configure the REST API's resource methods to use the newly created Cognito authorizer and redeploy the API.

Answer

To secure the API using Cognito User Pools directly at the API Gateway layer, the developer must create a Cognito authorizer associated with the Cognito User Pool ID and configure the token source header to Authorization. Additionally, they must configure the API methods to use this authorizer and deploy the API.
The correct actions are to create an API Gateway authorizer of type Cognito configured with the Cognito User Pool ID, and to bind this authorizer to the API's resource methods while deploying the API. This enables built-in validation of user pool JWT tokens at the API Gateway layer.

Step-by-Step Solution

1
Create a Cognito User Pool authorizer in API Gateway.
API Gateway is configured with the Cognito User Pool ID to validate incoming user tokens directly.
Natively validates the identity token or access token without custom Lambda functions.
2
Configure method request settings and redeploy.
API Gateway applies the authorizer to the target endpoints and publishes the configuration to the active stage.
Method integration binds the authentication policy, and deployment makes it active.

Key Concept

API Gateway Cognito User Pool Authorizer
Question 226Question →

A developer is configuring an application running on an Amazon EC2 instance in Account A (111122223333111122223333) to write logs to an Amazon S3 bucket in Account B (444455556666444455556666) by assuming an IAM role. The EC2 instance is associated with an IAM instance profile containing a role named `AppEngineRole`. In Account B, the developer has created an IAM role named `LogWriterRole` with a permissions policy allowing `s3:PutObject` on the S3 bucket.

Currently, the application fails to write logs and receives an `AccessDenied` error. The developer reviews the existing configurations:

Account A - `AppEngineRole` Permissions Policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::account-b-logs-bucket/*"
}
]
}

Account B - `LogWriterRole` Trust Policy:

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

Which of the following changes must the developer make to resolve the error and allow the application to assume the role and write to the S3 bucket? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Modify the permissions policy of `AppEngineRole` in Account A to allow the `sts:AssumeRole` action on `arn:aws:iam::444455556666:role/LogWriterRole`.; Modify the trust policy of `LogWriterRole` in Account B to specify the principal `"AWS": "arn:aws:iam::111122223333:role/AppEngineRole"` instead of the EC2 service principal.

Answer

To resolve the issue, the developer must allow the `AppEngineRole` in Account A to perform the `sts:AssumeRole` action on `LogWriterRole`, and they must update the trust policy of `LogWriterRole` in Account B to trust the ARN of `AppEngineRole` rather than the EC2 service principal.
For cross-account role assumption to succeed, two configurations are required: first, the permissions policy of the calling role in Account A must grant the `sts:AssumeRole` action targeting the ARN of the role in Account B. Second, the trust policy of the target role in Account B must designate the calling role's ARN in Account A as a trusted principal. Currently, the calling role in Account A lacks the permission to call `sts:AssumeRole`, and the target role in Account B incorrectly trusts the EC2 service principal rather than the calling IAM role itself.

Step-by-Step Solution

1
Analyze the execution environment and required IAM authorization flow.
The application runs on EC2 in Account A under the identity of `AppEngineRole` and needs to perform tasks in Account B. Direct bucket access is not configured; instead, the application must assume the `LogWriterRole` in Account B to obtain temporary credentials.
Understanding the authorization flow (role assumption across accounts) is necessary to identify the missing components.
2
Evaluate the permissions policy of the calling role (`AppEngineRole` in Account A).
The permissions policy currently grants `s3:PutObject` on the Account B bucket directly. However, to assume `LogWriterRole` in Account B, the caller must have `sts:AssumeRole` permissions on that specific role.
An IAM entity cannot assume a role unless it is explicitly permitted to call `sts:AssumeRole` on the target resource.
3
Evaluate the trust policy of the target role (`LogWriterRole` in Account B).
The trust policy currently trusts the service principal `ec2.amazonaws.com`. This configuration only allows the EC2 service to assume the role. It must be updated to trust the actual IAM role `AppEngineRole` from Account A.
For an application running on an EC2 instance to assume a cross-account role, the target role's trust policy must trust the calling IAM role's ARN, not the EC2 service principal.

Key Concept

Cross-account IAM role delegation requires a bi-directional handshake: the caller's identity-based policy must allow `sts:AssumeRole` on the target role, and the target role's trust policy must trust the caller's IAM ARN.
Question 227Question →

A developer is configuring an application running on AWS Elastic Beanstalk that requires access to a database. The database password must be rotated automatically every 30 days. Which solution should the developer implement to meet these security requirements?

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and enable the built-in automatic rotation feature.

Answer

Store the database password in AWS Secrets Manager and enable the built-in automatic rotation feature.
AWS Secrets Manager natively supports automatic rotation of database credentials using built-in templates, satisfying the security requirements with minimal effort.

Step-by-Step Solution

1
Analyze the requirement to store database credentials securely with automatic rotation every 30 days.
Automatic rotation of credentials is a primary capability of AWS Secrets Manager.
Choosing a service that natively supports automatic rotation avoids custom code.
2
Evaluate and eliminate options that do not support automatic rotation natively.
AWS Systems Manager Parameter Store and Amazon S3 do not support native automatic rotation.
Eliminating options with high operational overhead narrows down the correct service.

Key Concept

AWS Secrets Manager vs Systems Manager Parameter Store for automatic secrets rotation
Estimated Time:45s
Question 228Question →

A developer is implementing an AWS Lambda function that performs data enrichment. The function must query an Amazon Aurora MySQL database cluster running in a private VPC subnet. In addition, the function must invoke an external public API to retrieve conversion rates and securely access database credentials. The Lambda function is configured to run within the same private VPC subnet. Which configuration will allow the Lambda function to meet these requirements?

Show answer & explanation

Answer: Deploy the Lambda function in the private subnet. Create a NAT Gateway in a public subnet, and add a route in the private subnet's route table pointing 0.0.0.0/0 to the NAT Gateway. Store the database credentials in AWS Secrets Manager, and grant the Lambda execution role permissions to retrieve the secret.

Answer

Deploy the Lambda function in the private subnet, configure a NAT Gateway in a public subnet for external internet traffic, and secure credentials using AWS Secrets Manager with IAM execution role permissions.
The correct configuration deploys the Lambda function in the private subnet to connect locally to the private Aurora database. To access the external API, a NAT Gateway is deployed in a public subnet, and the private subnet's route table is updated to route internet-bound traffic (0.0.0.0/0) through it. Secrets Manager securely stores the database credentials, which the Lambda execution role can retrieve using standard identity-based permissions.

Step-by-Step Solution

1
Determine network access requirements for the Lambda function to reach the Aurora database and the external API.
The Lambda function must be placed in a VPC private subnet to access the private Aurora database. To reach the external API (public internet), it requires a NAT Gateway situated in a public subnet.
Lambda functions associated with a VPC private subnet do not have direct internet access unless outbound traffic is routed through a NAT Gateway or NAT instance.
2
Establish secure storage and access for database credentials.
Store the sensitive credentials in AWS Secrets Manager, and grant the Lambda execution role the necessary IAM permissions (secretsmanager:GetSecretValue) to retrieve them.
Storing credentials in Secrets Manager ensures encryption at rest and transit, supports rotation, and complies with security best practices.
3
Configure routing and security groups.
Add a route to the private subnet's route table directing 0.0.0.0/0 traffic to the NAT Gateway. Ensure the security groups allow outbound traffic from the Lambda function to the database and the NAT Gateway.
Proper route tables and security group rules are required to establish network paths to both local VPC resources and external services.

Key Concept

Configuring VPC routing and external API access for Lambda functions deployed inside private subnets, while securing credentials using AWS Secrets Manager.
Question 229Question →

A developer is designing a containerized microservice to be deployed on Amazon Elastic Container Service (Amazon ECS) with the AWS Fargate launch type. The microservice requires secure access to two configurations:
1. A database connection string that is static and changes infrequently.
2. A payment gateway API key that must be automatically rotated every 30 days.
The microservice must retrieve the rotated API key dynamically at runtime without requiring a task restart or redeployment. The developer wants to minimize costs and API call latency.

Which combination of configuration steps should the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database connection string as a SecureString parameter in AWS Systems Manager Parameter Store, and reference it in the ECS container definition secrets section using the ECS task execution role for decryption.; Store the payment gateway API key in AWS Secrets Manager, configure automatic rotation using an AWS Lambda function, and retrieve the secret dynamically at runtime using the AWS SDK with permissions granted via the ECS task role.

Answer

Store the database connection string as a SecureString parameter in AWS Systems Manager Parameter Store, referencing it in the ECS container definition secrets section using the ECS task execution role, and store the payment gateway API key in AWS Secrets Manager, configuring automatic rotation using an AWS Lambda function, and retrieving it dynamically at runtime using the AWS SDK with permissions granted via the ECS task role.
For static values like a database connection string, Systems Manager Parameter Store is the most cost-effective solution. Using the ECS container definition's secrets section allows the ECS agent to inject the decrypted parameter as an environment variable at startup, using the Task Execution Role. For values requiring rotation, AWS Secrets Manager is the correct service due to its native support for Lambda-based rotation. To ensure the application dynamically retrieves the rotated key without a task restart, the microservice must query Secrets Manager at runtime using the AWS SDK, leveraging permissions from the ECS Task Role.

Step-by-Step Solution

1
Analyze secret characteristics and choose the storage service.
Determine that SSM Parameter Store is the most cost-effective choice for the static string, while AWS Secrets Manager is required for the API key to utilize built-in automatic rotation.
Standard parameters in Parameter Store have no storage cost, whereas Secrets Manager charges per secret and supports Lambda-based rotation.
2
Determine the injection mechanism for the static secret.
Reference the Parameter Store SecureString in the ECS container definition secrets section.
The ECS agent will retrieve and inject the connection string as an environment variable during container startup using permissions from the task execution role. Since the connection string is static, injecting it at startup is efficient.
3
Determine the retrieval mechanism for the rotating secret.
Use the AWS SDK inside the microservice code to retrieve the API key dynamically from Secrets Manager at runtime.
Environment variables are static once the container is running; querying the API at runtime is necessary to handle rotations dynamically without restarting tasks. The task role provides the application runtime permissions.

Key Concept

Selecting and integrating Secrets Manager vs Parameter Store based on rotation requirements and ECS role configuration.
Question 230Question →

A developer is building a serverless backend where users must register and sign in to access private API Gateway endpoints. The developer wants to use built-in AWS features to authenticate users and control access to the APIs with minimal custom code.

Which TWO Amazon Cognito features or configurations should the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An Amazon Cognito User Pool to manage user registration, sign-in, and token generation.; An Amazon Cognito Authorizer in API Gateway to validate the JSON Web Tokens (JWTs) returned after user authentication.

Answer

Implementing an Amazon Cognito User Pool and configuring an Amazon Cognito Authorizer in API Gateway
To authenticate users and authorize API Gateway requests with minimal overhead, a developer should use an Amazon Cognito User Pool to handle user directory services (registration and sign-in) and token issuance, and pair it with an API Gateway Cognito Authorizer to validate those tokens at the API entry point.

Step-by-Step Solution

1
Set up user authentication and directory
Create an Amazon Cognito User Pool to serve as the user directory and handle registration, sign-in, and the issuance of JWT tokens.
This establishes the identity store and authentication mechanism for the application.
2
Configure API Gateway authorization
Configure an Amazon Cognito Authorizer on the API Gateway resource and point it to the Cognito User Pool.
This enables API Gateway to automatically intercept incoming requests, extract the JWT token from the Authorization header, and validate it against the User Pool.

Key Concept

Amazon Cognito User Pools provide authentication and issue tokens, while API Gateway Cognito Authorizers provide built-in token validation for authorization.
Question 231Question →

A developer is building a document processing application that must client-side encrypt files up to 15 MB15\text{ MB} in size before uploading them to an Amazon S3 bucket. The application must use a customer managed key in AWS Key Management Service (AWS KMS) for this process. Which of the following actions must the developer perform to implement this client-side encryption workflow? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Call the KMS GenerateDataKey API operation using the customer managed key to receive a plaintext data key and an encrypted data key.; Encrypt the file locally using the plaintext data key, then delete the plaintext data key from memory.

Answer

The correct actions are calling the KMS GenerateDataKey API operation to obtain the plaintext and encrypted data keys, and encrypting the file locally using the plaintext data key while discarding it from memory afterwards.
To implement client-side envelope encryption for large files (such as 15 MB15\text{ MB}), the developer must first call the KMS GenerateDataKey API operation to retrieve both a plaintext and an encrypted data key. The developer then encrypts the file locally using the plaintext key and immediately deletes the plaintext key from memory to prevent leakage, leaving only the encrypted data and the encrypted data key.

Step-by-Step Solution

1
Request a data key from AWS KMS.
Obtained a plaintext data key for encryption and an encrypted version of the same data key (ciphertext data key) for storage.
Because files larger than 4 KB4\text{ KB} cannot be directly encrypted using the KMS Encrypt API due to size limitations, requiring envelope encryption.
2
Encrypt the file locally.
The file is encrypted using the plaintext data key.
The client-side application must perform the bulk data encryption using a local symmetric key rather than transmitting the entire large payload over the network to AWS KMS.
3
Clean up the memory.
The plaintext data key is purged from the application memory.
To ensure security best practices are followed and the plaintext key is not exposed or leaked.

Key Concept

AWS KMS Envelope Encryption Workflow for Large Payloads
Question 232Question →

A developer is creating an IAM role for an AWS Lambda function. The developer configures the permissions policy correctly but receives an authorization error stating that the function cannot assume the role. The developer inspects the role's trust policy:

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

Which modification must the developer make to the trust policy to allow the Lambda function to assume the role?

Show answer & explanation

Answer: Change the Service principal in the trust policy from "ec2.amazonaws.com" to "lambda.amazonaws.com".

Answer

Change the Service principal in the trust policy from "ec2.amazonaws.com" to "lambda.amazonaws.com".
The trust policy determines which principals can assume the role. Because the current trust policy specifies the Amazon EC2 service principal ("ec2.amazonaws.com"), only EC2 instances can assume the role. To allow AWS Lambda to assume the role, the principal must be updated to the Lambda service principal ("lambda.amazonaws.com").

Step-by-Step Solution

1
Analyze the error message and the trust policy.
The Lambda function is unable to assume the IAM role because the trust policy only permits the "ec2.amazonaws.com" service principal.
An AWS service cannot assume an IAM role unless it is explicitly trusted in the role's trust relationship document.
2
Identify the correct service principal for AWS Lambda.
The service principal for AWS Lambda is "lambda.amazonaws.com".
Each AWS service that assumes roles has a specific service principal identifier used in IAM trust policies.
3
Update the trust policy with the correct service principal.
Changing "ec2.amazonaws.com" to "lambda.amazonaws.com" allows the Lambda service to assume the execution role.
This establishes the necessary trust relationship, allowing the function to execute with the role's permissions.

Key Concept

IAM trust policies define which principals (users, roles, accounts, or services) are authorized to assume an IAM role.
Question 233Question →

A developer is implementing a secure corporate portal that exposes sensitive administrative endpoints through an Amazon API Gateway REST API. The portal's frontend application authenticates users against an Amazon Cognito User Pool. The developer wants to restrict access to these REST API endpoints to authenticated users only. To comply with security best practices and keep development and operational overhead to a minimum, the developer wants to avoid writing and maintaining custom code for token verification. Which approach should the developer use to authorize these API requests?

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool authorizer on the API Gateway resources, and verify the authorization by passing the identity JSON Web Token (JWT) in the request headers.

Answer

Configure an Amazon Cognito User Pool authorizer on the API Gateway resources, and verify the authorization by passing the identity JSON Web Token (JWT) in the request headers.
Configuring an Amazon Cognito User Pool authorizer is a native, built-in feature of Amazon API Gateway. It validates JSON Web Tokens (JWT) sent in the request header directly against the configured Cognito User Pool without executing custom Lambda code. This approach eliminates custom code development, reduces operational overhead, and minimizes execution costs.

Step-by-Step Solution

1
Identify the authentication source and authorization requirements.
Users authenticate against an Amazon Cognito User Pool, and the API Gateway REST API must allow access only to these authenticated users.
Establishing the source of the identity tokens helps determine which built-in integrations are available.
2
Evaluate the constraints regarding development and operational overhead.
Custom code for token verification must be avoided.
This eliminates custom Lambda authorizers or validation within the backend Lambda function, favoring native API Gateway integrations.
3
Select the built-in, code-free API Gateway security mechanism.
Configure an Amazon Cognito User Pool authorizer on the API Gateway REST API resources.
This native feature validates the JWT signature and expiration directly at the API Gateway layer without requiring custom code or extra Lambda execution.

Key Concept

Natively securing Amazon API Gateway REST APIs using Cognito User Pool Authorizers to validate JSON Web Tokens (JWT) without custom code execution.
Question 234Question →

An asynchronous processing system utilizes an AWS Lambda function to retrieve messages from an Amazon SQS queue and perform updates on an Amazon Aurora PostgreSQL database. The database is hosted in private subnets within a custom VPC. To connect to the database, the Lambda function is associated with the same private subnets. However, the Lambda function fails to retrieve any messages from the queue and times out during execution. How should the network and endpoint configuration be adjusted to allow the function to securely poll the SQS queue?

Show answer & explanation

Answer: Establish an Interface VPC endpoint for Amazon SQS within the private subnets, enabling private DNS hostnames for the VPC endpoint to route requests internally.

Answer

Establish an Interface VPC endpoint for Amazon SQS within the private subnets, enabling private DNS hostnames for the VPC endpoint to route requests internally.
Establishing an Interface VPC endpoint for Amazon SQS inside the private VPC subnets allows the Lambda function to securely and privately access SQS over the AWS internal network. Activating private DNS hostnames ensures that the standard SQS DNS hostname automatically resolves to the private IP addresses of the endpoint network interfaces.

Step-by-Step Solution

1
Analyze the network configuration of the Lambda function.
The Lambda function is placed in a private VPC subnet to access the private Aurora database.
By placing Lambda in a VPC subnet, it loses its default internet connectivity and can only access resources inside the VPC or via VPC gateways/endpoints.
2
Identify the destination endpoint requirements.
The Lambda function needs to communicate with Amazon SQS, which is a public AWS service.
Since the function is in a private subnet with no path to the public internet, it cannot resolve or reach the public SQS endpoint directly.
3
Determine the secure, private solution for AWS service integration.
Create an Interface VPC endpoint (powered by AWS PrivateLink) for SQS in the VPC and enable Private DNS.
This places elastic network interfaces (ENIs) inside the private subnets, allowing the Lambda function to route SQS API calls entirely within the AWS network.

Key Concept

VPC Endpoint Connectivity for Serverless Resources
Estimated Time:1m 30s
Question 235Question →

An application deployed on Amazon EC2 instances must connect to an external database. The developer needs to store the database endpoint URL, which is non-sensitive, and the database credentials, which must be rotated automatically every 30 days. Which combination of actions should the developer take to configure these parameters in a secure and cost-effective manner? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the non-sensitive database endpoint URL as a Parameter Store parameter.; Store the database credentials in AWS Secrets Manager with automatic rotation enabled.

Answer

Store the non-sensitive database endpoint URL as a Parameter Store parameter, and store the database credentials in AWS Secrets Manager with automatic rotation enabled.
Storing the non-sensitive database endpoint in Systems Manager Parameter Store provides a low-cost, fully-managed configuration store. Storing the sensitive database credentials in AWS Secrets Manager provides native automated credentials rotation, which meets security requirements with minimal operational overhead.

Step-by-Step Solution

1
Identify parameter sensitivity and rotation requirements.
The database endpoint URL is non-sensitive and does not require rotation. The database credentials are sensitive and require regular rotation.
Correct classification helps in choosing the most cost-effective and secure service.
2
Select the appropriate AWS service for each parameter class.
Use Systems Manager Parameter Store for the endpoint URL, and use AWS Secrets Manager for the database credentials.
Parameter Store offers cost-effective storage for configuration parameters, whereas Secrets Manager provides out-of-the-box automatic rotation for sensitive credentials.

Key Concept

Selecting between Systems Manager Parameter Store and AWS Secrets Manager based on credential sensitivity and automatic rotation requirements.
Question 236Question →

A developer is configuring a web application running on Amazon EC2 instances in an Auto Scaling group. The application must retrieve a database password to connect to an Amazon Aurora PostgreSQL DB cluster. The database password must be rotated every 30 days. Both the EC2 instances and the database cluster are deployed in private subnets within a VPC that has no internet connectivity. Which combination of steps should the developer take to meet these requirements securely with the minimum operational overhead?

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager. Enable automatic rotation on the secret using the single-user rotation template for Amazon RDS, and configure the Lambda rotation function to run in the private subnets of the VPC. Create an interface VPC endpoint for Secrets Manager, and assign an IAM role to the EC2 instances that grants access to the secret.

Answer

Store the database password in AWS Secrets Manager. Enable automatic rotation on the secret using the single-user rotation template for Amazon RDS, and configure the Lambda rotation function to run in the private subnets of the VPC. Create an interface VPC endpoint for Secrets Manager, and assign an IAM role to the EC2 instances that grants access to the secret.
The correct solution uses AWS Secrets Manager, which natively supports automated rotation of RDS database credentials using pre-built Lambda templates. Since the database and EC2 instances reside in a private VPC without internet access, deploying the Lambda rotation function inside the VPC allows it to reach the database. Creating an interface VPC endpoint for Secrets Manager allows the EC2 instances and the Lambda rotation function to securely interact with Secrets Manager privately. Access is granted to the EC2 instances via an IAM instance profile, ensuring no credentials are hardcoded.

Step-by-Step Solution

1
Store the secret in AWS Secrets Manager.
The database password is encrypted and stored securely.
AWS Secrets Manager is designed for storing secrets (like passwords and API keys) and supports native automatic rotation.
2
Enable automatic rotation using the standard RDS template and deploy the rotation Lambda function within the VPC private subnets.
Secrets Manager automatically manages password updates in both the database and the secret storage every 30 days.
Since the database has no public internet access, the Lambda function must run inside the VPC to connect to the database cluster and update the password.
3
Create an interface VPC endpoint (AWS PrivateLink) for AWS Secrets Manager in the VPC.
The EC2 instances and the Lambda rotation function can securely connect to Secrets Manager without internet access.
An interface VPC endpoint allows secure, private traffic routing to AWS services within a isolated VPC.
4
Attach an IAM role containing Secrets Manager read access to the EC2 instance profile.
The application retrieves the credential dynamically at runtime.
This avoids hardcoding credentials and uses temporary security credentials instead.

Key Concept

AWS Secrets Manager vs. Systems Manager Parameter Store and Private VPC Networking Integration
Question 237Question →

A developer is designing a secure integration for an enterprise application. While human users authenticate interactively via an Amazon Cognito User Pool, an external partner’s automated service must programmatically invoke a specific Amazon API Gateway REST API. The partner's service needs to perform machine-to-machine (M2M) communication without any user interaction. Which configuration meets these requirements with the least operational overhead?

Show answer & explanation

Answer: Configure a resource server in the Cognito User Pool and define a custom scope. Create a user pool client for the partner service, enable the Client Credentials grant flow, and configure the API Gateway method to use a Cognito authorizer that requires the custom scope.

Answer

Configure a resource server in the Cognito User Pool and define a custom scope. Create a user pool client for the partner service, enable the Client Credentials grant flow, and configure the API Gateway method to use a Cognito authorizer that requires the custom scope.
Configuring a Cognito resource server and using the Client Credentials grant flow allows machine-to-machine clients to obtain OAuth 2.0 access tokens. API Gateway Cognito authorizers can natively validate these access tokens and restrict access based on the configured custom scopes. This requires no custom validation code or external identity pools.

Step-by-Step Solution

1
Analyze the client interaction requirements.
The requirement calls for machine-to-machine (M2M) communication without user interaction.
This rules out interactive authorization flows like Authorization Code or Implicit, pointing towards the OAuth 2.0 Client Credentials grant flow.
2
Select the appropriate Amazon Cognito feature set.
Amazon Cognito User Pools support OAuth 2.0 resource servers, custom scopes, and client clients with the Client Credentials grant.
Using a User Pool is more lightweight than building a custom credential exchange service with Cognito Identity Pools.
3
Determine the API Gateway integration strategy.
API Gateway's built-in Cognito authorizer can validate access tokens containing custom scopes natively.
Using a native authorizer avoids writing custom Lambda code to verify JWT signatures, reducing operational overhead and request latency.

Key Concept

Amazon Cognito User Pool Resource Servers and Client Credentials Flow
Question 238Question →

A developer is deploying a containerized application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate in Account A (111111111111111111111111). The application must assume an IAM role named `CrossAccountDynamoDBAccess` in Account B (222222222222222222222222) to perform read operations on a DynamoDB table.

The task definition in Account A is configured with an ECS Task Role named `TaskRole` and an ECS Task Execution Role named `TaskExecutionRole`. The developer configures the trust policy for the `CrossAccountDynamoDBAccess` role in Account B as follows:

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

When the container starts, the application throws an `AccessDenied` error when calling the AWS Security Token Service (STS) `AssumeRole` API.

How should the developer modify the configuration to resolve this issue and grant the application access using the principle of least privilege?

Show answer & explanation

Answer: Update the trust policy of `CrossAccountDynamoDBAccess` in Account B to specify the principal as `"AWS": "arn:aws:iam::111111111111:role/TaskRole"`. Additionally, attach a policy to `TaskRole` in Account A that allows `sts:AssumeRole` on the `CrossAccountDynamoDBAccess` role ARN.

Answer

Update the trust policy of the cross-account role in Account B to trust the ARN of the ECS Task Role, and attach an IAM policy to the ECS Task Role in Account A allowing it to assume the cross-account role.
The correct solution involves modifying the trust policy of the cross-account role in Account B to trust the specific IAM role associated with the running application container (the Task Role in Account A). Additionally, the Task Role in Account A must be granted permission to call the Security Token Service (STS) AssumeRole API on the role in Account B. This allows the application to assume the role using temporary credentials retrieved via the ECS Task Role, complying with the principle of least privilege.

Step-by-Step Solution

1
Identify the role that executes the application code in ECS.
The containerized application runs using the permissions of the ECS Task Role (`TaskRole`), not the ECS Task Execution Role (`TaskExecutionRole`).
The Task Execution Role is for container agent operations (like pulling images and shipping logs), whereas the Task Role provides AWS API credentials directly to the containerized application.
2
Determine the required trust policy for the cross-account role in Account B.
The trust policy of `CrossAccountDynamoDBAccess` must trust the caller's identity: `arn:aws:iam::111111111111:role/TaskRole`.
The current trust policy incorrectly trusts the service principal `ecs-tasks.amazonaws.com`, which allows ECS to assume the TaskRole but does not allow the TaskRole to assume the cross-account role.
3
Define the required permissions policy in the source account (Account A).
Attach an IAM policy to `TaskRole` in Account A allowing `sts:AssumeRole` on `arn:aws:iam::222222222222:role/CrossAccountDynamoDBAccess`.
For cross-account role assumption to succeed, the source identity must be explicitly granted permission to perform the `sts:AssumeRole` action on the target role.

Key Concept

IAM Cross-Account Role Assumption with Amazon ECS Task Roles
Question 239Question →

A developer is configuring an AWS Lambda function to run inside private subnets of a custom VPC. The Lambda function needs to read data from an Amazon Aurora PostgreSQL database located in another private subnet of the same VPC. Additionally, the Lambda function must retrieve database credentials from AWS Secrets Manager. To meet security requirements, all traffic must remain within the AWS network. Which two configurations must the developer implement to allow the Lambda function to connect to both the database and AWS Secrets Manager? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the security groups to allow outbound traffic from the Lambda function to the database, and inbound traffic to the database from the Lambda function.; Create an Interface VPC Endpoint for AWS Secrets Manager in the private subnets, and configure the Lambda function's security group to allow outbound traffic to the endpoint.

Answer

Configure the security groups to allow outbound traffic from the Lambda function to the database (and inbound traffic to the database from the Lambda function) and create an Interface VPC Endpoint for AWS Secrets Manager in the private subnets, configuring the Lambda function's security group to allow outbound traffic to the endpoint.
To secure communications between resources, security groups must explicitly allow traffic between the Lambda function and the database. Additionally, because the Lambda function resides in a private VPC subnet and must reach AWS Secrets Manager without using the public internet, an Interface VPC Endpoint must be provisioned. This places an Elastic Network Interface in the private subnet to facilitate private communication with Secrets Manager.

Step-by-Step Solution

1
Configure the security groups for the local database connection.
The Lambda function is allowed to initiate outbound connections to the database, and the database accepts inbound connections from the Lambda function on the PostgreSQL port.
Security groups act as stateful firewalls at the resource interface level to allow communication within the VPC.
2
Determine the endpoint type required to access AWS Secrets Manager privately.
Identify that an Interface VPC Endpoint (AWS PrivateLink) is needed for AWS Secrets Manager, as Gateway Endpoints are not supported for this service.
Interface VPC Endpoints allow resources inside private subnets to communicate securely with AWS services without leaving the Amazon network.
3
Establish the Interface VPC Endpoint and configure its security group.
The endpoint is created in the private subnets, and its security group is updated to allow inbound HTTPS traffic from the Lambda function's security group.
Interface endpoints use Elastic Network Interfaces (ENIs) which require security group configurations to permit incoming traffic from client resources.

Key Concept

AWS VPC private connectivity using Security Groups and Interface VPC Endpoints.
Question 240Question →

A developer is building a web application and needs to implement user sign-up, sign-in, and password recovery features to manage the application's user directory. The application does not require users to access any AWS resources directly. Which Amazon Cognito feature should the developer use to meet these requirements?

Show answer & explanation

Answer: Amazon Cognito User Pools

Answer

Amazon Cognito User Pools
Amazon Cognito User Pools is the correct component because it functions as a user directory that provides sign-up, sign-in, and self-service password recovery workflows out-of-the-box, which matches the application's requirement to manage end-user authentication without needing access to AWS resources.

Step-by-Step Solution

1
Identify the primary requirement: managing a user directory with sign-up, sign-in, and password recovery capabilities for an application's end-users.
Requires an authentication directory service rather than an authorization service for AWS resources.
The scenario specifies managing sign-up, sign-in, and password recovery without needing direct access to AWS resources.
2
Compare the core functions of Cognito User Pools and Cognito Identity Pools.
User Pools provide identity provider and user directory services. Identity Pools provide temporary AWS credentials for accessing AWS resources.
This avoids the common misconception of confusing User Pools (authentication/directory) with Identity Pools (authorization/credentials).

Key Concept

Amazon Cognito User Pools provide authentication, user directories, and profile management for application users, whereas Identity Pools provide authorization to AWS resources via temporary credentials.
Estimated Time:45s
PreviousPage 12 / 20Next
Security Practice Questions — AWS Certified Developer - Associate — Page 12 | Examkin