Examkin

Security

390 questions

All types390Multiple choice195Multiple select195
Question 381Question →

A developer is configuring a containerized application to run on Amazon ECS using the AWS Fargate launch type. The application needs to read messages from an Amazon SQS queue and write records to an Amazon DynamoDB table. During container initialization, the ECS container agent must pull the container image from Amazon ECR, retrieve a database credential from AWS Secrets Manager to set as an environment variable, and send container logs to Amazon CloudWatch Logs. Which two IAM roles must the developer configure in the ECS task definition to meet these requirements with the minimum required privileges? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: An ECS Task Execution Role with a policy that allows the ecr:GetAuthorizationToken, ecr:BatchGetImage, secretsmanager:GetSecretValue, and logs:PutLogEvents actions.; An ECS Task Role with a policy that allows the sqs:ReceiveMessage, sqs:DeleteMessage, and dynamodb:PutItem actions.

Answer

An ECS Task Execution Role that allows the container agent to pull images, fetch secrets, and send logs, and an ECS Task Role that allows the application to read from SQS and write to DynamoDB.
The correct solution involves configuring both the ECS Task Execution Role and the ECS Task Role. The Task Execution Role is required by the ECS agent to prepare the environment (pull ECR images, retrieve secrets to set as environment variables, and send container logs to CloudWatch). The Task Role is required by the application code to interact with AWS services like Amazon SQS and Amazon DynamoDB.

Step-by-Step Solution

1
Analyze the requirements of the ECS container agent versus the application running inside the container.
The container agent needs to pull images, retrieve secrets for environment variables, and configure logging. The application code needs to interact with SQS and DynamoDB.
This separation determines which permissions go to the Task Execution Role and which go to the Task Role.
2
Assign agent-level permissions to the ECS Task Execution Role.
Permissions for ECR image pull, Secrets Manager secret retrieval, and CloudWatch log delivery are assigned to the Task Execution Role.
The ECS agent performs these tasks before launching the application container, so they must be in the execution role.
3
Assign application-level permissions to the ECS Task Role.
Permissions to receive/delete messages from SQS and put items to DynamoDB are assigned to the Task Role.
The application code running inside the container assumes the Task Role to perform its business logic.

Key Concept

Distinction between ECS Task Role (application permissions) and ECS Task Execution Role (agent/infrastructure permissions) in AWS Fargate.
Question 382Question →

A developer is creating an AWS Lambda function that processes files uploaded to an Amazon S3 bucket. The developer creates an IAM role named `S3ProcessRole` with the required S3 permission policies. However, when trying to assign the role to the Lambda function, the developer receives an error indicating that the role cannot be assumed by Lambda. The developer inspects the role's trust policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::987654321098:root"
},
"Action": "sts:AssumeRole"
}
]
}

Which modification to the trust policy is required to resolve this error?

Show answer & explanation

Answer: Update the Principal block in the trust policy to specify "Service": "lambda.amazonaws.com".

Answer

Update the Principal block in the trust policy to specify the Lambda service principal.
The correct answer is to modify the Principal block to allow the AWS Lambda service principal (lambda.amazonaws.com) to assume the role. When Lambda runs a function, it must assume the execution role via the sts:AssumeRole action. For this to succeed, the role's trust policy must explicitly trust the Lambda service principal.

Step-by-Step Solution

1
Identify the cause of the failure: the trust policy limits assumption of the role to the root of AWS account 987654321098, preventing the AWS Lambda service from assuming it.
Discovered that the Principal specifies the account root rather than the Lambda service principal.
Before a service can assume an IAM role, the trust policy must explicitly permit that specific service principal.
2
Locate the Principal block in the trust policy JSON.
Isolated the 'Principal': { 'AWS': 'arn:aws:iam::987654321098:root' } block.
This is the segment governing who is trusted to assume the role.
3
Change the Principal from the AWS account root to the Lambda service principal, lambda.amazonaws.com, and keep the Action as sts:AssumeRole.
The Lambda service principal is now trusted, allowing the function to execute with the role's permissions.
This establishes the necessary trust relationship for the AWS Lambda service.

Key Concept

IAM Role Trust Policies vs. Permissions Policies
Estimated Time:1m 30s
Question 383Question →

A developer is running an application on an Amazon EC2 instance in Account 123456789012123456789012. The EC2 instance is associated with an IAM instance profile that uses a role named `EC2InstanceRole`. The application needs to perform temporary tasks by assuming an IAM role named `DataProcessorRole` in the same account.

The developer runs a script on the instance using the AWS SDK to assume `DataProcessorRole`, but the operation fails with an `AccessDenied` error.

The trust policy of `DataProcessorRole` is currently configured as follows:

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

Which of the following configuration changes must the developer make to resolve this issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the trust policy of `DataProcessorRole` to specify the ARN of `EC2InstanceRole` as the Principal.; Attach an IAM permissions policy to `EC2InstanceRole` that allows the `sts:AssumeRole` action on `arn:aws:iam::123456789012:role/DataProcessorRole`.

Answer

To resolve the issue, the developer must modify the trust policy of the target role (DataProcessorRole) to trust the assuming identity (EC2InstanceRole) as a principal, and attach a permissions policy to the assuming identity (EC2InstanceRole) that permits the sts:AssumeRole action on the target role's resource ARN.
For an application running on an EC2 instance to assume another IAM role, the target role's trust policy must explicitly trust the IAM identity of the calling application (the option recommending modifying the trust policy of the target role to reference the EC2 instance role ARN). Furthermore, the caller's identity-based policies must authorize it to make the call (the option recommending attaching a permissions policy allowing the assume role operation to the instance role).

Step-by-Step Solution

1
Analyze the execution caller and error condition.
The SDK script runs as the EC2InstanceRole principal. The current trust policy of DataProcessorRole only trusts the service principal 'ec2.amazonaws.com'.
When EC2 software assumes a role via SDK, the direct caller is the IAM role associated with the instance, not the EC2 service itself.
2
Correct the trust relationship of the target role.
Update the trust policy of DataProcessorRole so its Principal block contains the ARN of EC2InstanceRole.
This establishes that DataProcessorRole trusts the EC2InstanceRole principal to assume it.
3
Configure permissions for the calling identity.
Attach a permissions policy to EC2InstanceRole allowing the 'sts:AssumeRole' action on 'arn:aws:iam::123456789012:role/DataProcessorRole'.
Even when the target role trusts the caller, the caller must have client-side identity permissions authorizing it to make the AssumeRole API call.

Key Concept

Delegation via IAM AssumeRole requires permissions on both sides: the trust policy of the target role must trust the caller, and the permission policy of the calling role must allow sts:AssumeRole on the target.
Question 384Question →

A developer is configuring an Amazon API Gateway REST API to send incoming event data directly to an Amazon Kinesis data stream using a service proxy integration. To authorize this integration, the developer creates an IAM role named `APIGatewayKinesisRole` with a permissions policy that allows `kinesis:PutRecord` on the target stream. However, when testing the API Gateway integration, the developer receives an error indicating that API Gateway is not authorized to assume the role. The developer inspects the trust policy of `APIGatewayKinesisRole`, which is configured as follows:

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

How should the developer resolve this authorization error?

Show answer & explanation

Answer: Change the Service principal in the trust policy to apigateway.amazonaws.com.

Answer

Change the Service principal in the trust policy to apigateway.amazonaws.com.
To resolve the authorization issue, the service principal in the trust policy must be changed to apigateway.amazonaws.com. This tells IAM that the API Gateway service is trusted to assume the role. When API Gateway executes the integration, it calls sts:AssumeRole on the specified role to get temporary credentials with the permissions defined in the attached policy (which allows kinesis:PutRecord).

Step-by-Step Solution

1
Analyze the error message and the configuration.
The error indicates that API Gateway is unable to assume the role. The trust policy defines the principal as kinesis.amazonaws.com.
To find why the assume role action fails, we must verify if the correct entity is allowed to assume the role.
2
Identify the service executing the action.
Amazon API Gateway is the service that needs to assume the role to send data to the Kinesis data stream.
The trust policy principal must designate the service requesting the role assumption.
3
Correct the principal in the trust policy.
Change the principal from kinesis.amazonaws.com to apigateway.amazonaws.com.
This allows the API Gateway service to successfully call sts:AssumeRole and acquire temporary credentials.

Key Concept

IAM trust policy service principal configuration
Question 385Question →

A developer is setting up an Amazon S3 Batch Operations job to execute an AWS Lambda function on millions of objects in an Amazon S3 bucket. The developer creates an IAM role to grant the necessary permissions. However, the S3 Batch Operations job fails to run during initialization, resulting in an authorization failure. The developer inspects the trust policy attached to the role:

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

Which two actions should the developer take to resolve this authorization failure and successfully run the batch job? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the service principal in the trust policy to batchoperations.s3.amazonaws.com; Attach a permissions policy to the IAM role that allows the lambda:InvokeFunction action on the target Lambda function's ARN

Answer

Update the service principal in the trust policy to batchoperations.s3.amazonaws.com and attach a permissions policy to the IAM role that allows the lambda:InvokeFunction action on the target Lambda function's ARN.
To fix the authorization error, the trust policy must explicitly allow the S3 Batch Operations service to assume the role. The correct service principal is batchoperations.s3.amazonaws.com. Additionally, the role needs a permissions policy attached to it that permits the lambda:InvokeFunction action on the specific Lambda function being run.

Step-by-Step Solution

1
Identify the service attempting to assume the IAM role.
The service is S3 Batch Operations, which uses the specific service principal batchoperations.s3.amazonaws.com.
The standard s3.amazonaws.com principal is used for basic features like replication and event notifications, but not for batch operations.
2
Modify the trust policy principal accordingly.
The trust policy allows batchoperations.s3.amazonaws.com to perform sts:AssumeRole.
This establishes trust between the S3 Batch Operations service and the IAM role.
3
Determine the necessary operational permissions.
The role requires permission to run the Lambda function, which corresponds to the lambda:InvokeFunction action.
Trust policies only control delegation; standard IAM permissions policies must be attached to the role to authorize downstream actions.

Key Concept

Separation of Trust Policies and Permissions Policies
Question 386Question →

A developer is deploying an application on Amazon ECS using the AWS Fargate launch type. The application container needs to read messages from an Amazon SQS queue. The developer creates an IAM role with the correct SQS permissions, but the ECS task fails to start, returning an error that the task role could not be assumed. The developer inspects the trust policy currently associated with the IAM role:

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

Which modification to the trust policy will resolve this issue and allow the ECS task to assume the role?

Show answer & explanation

Answer: Change the "Service" value in the "Principal" block to "ecs-tasks.amazonaws.com".

Answer

Change the "Service" value in the "Principal" block to "ecs-tasks.amazonaws.com".
The correct option is correct because the Amazon ECS container agent requires the trust policy to specify the 'ecs-tasks.amazonaws.com' service principal. This allows ECS Fargate to assume the role and associate its permissions with the containers running in the task.

Step-by-Step Solution

1
Identify the service attempting to assume the IAM role.
The ECS task container agent needs to assume the role to run the task.
Understanding which entity is requesting the role helps determine the correct service principal.
2
Analyze the existing trust policy principal.
The principal is currently set to "ecs.amazonaws.com".
This principal is for the ECS service scheduler (used for task registration and ELB interactions), not the tasks themselves.
3
Update the trust policy service principal to allow ECS tasks to assume the role.
Change the principal to "ecs-tasks.amazonaws.com".
This allows the ECS container agent to successfully assume the role on behalf of the container.

Key Concept

IAM Trust Policies and Service Principals for ECS Tasks
Question 387Question →

A developer is configuring an Amazon EventBridge Scheduler schedule to send messages to an Amazon SQS queue named OrderProcessingQueue in the same AWS account. The schedule is failing to deliver messages, and execution metrics show access denied errors.

Which two configurations are required to resolve this permissions issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the trust policy of the EventBridge Scheduler IAM execution role to allow the scheduler.amazonaws.com service principal to assume the role using the sts:AssumeRole action.; Attach a permissions policy to the EventBridge Scheduler IAM execution role that allows the sqs:SendMessage action on the arn:aws:sqs:us-east-1:123456789012:OrderProcessingQueue resource.

Answer

To resolve the permissions issue, the developer must configure a trust policy on the IAM role that allows the EventBridge Scheduler service principal (scheduler.amazonaws.com) to assume the role, and attach an IAM permissions policy to that execution role that allows the sqs:SendMessage action on the specific target SQS queue resource.
For Amazon EventBridge Scheduler to deliver messages to Amazon SQS, it must assume an execution role. This requires a trust policy allowing the Scheduler service principal (scheduler.amazonaws.com) to assume the role, and a permissions policy attached to the role that grants the sqs:SendMessage permission on the target SQS queue.

Step-by-Step Solution

1
Identify the service principal that needs to assume the role.
The service principal scheduler.amazonaws.com requires trust permission to assume the role.
Since EventBridge Scheduler is running the task, it must be allowed to assume the IAM role to perform actions on your behalf.
2
Configure the trust relationship on the IAM role.
Add scheduler.amazonaws.com to the trust policy with the sts:AssumeRole action.
This establishes trust between IAM and the Scheduler service.
3
Grant SQS permissions to the execution role.
Attach an IAM permissions policy to the role that allows sqs:SendMessage on the specific SQS queue ARN.
This gives the assumed role the required permissions to deliver the messages to the SQS queue.

Key Concept

IAM execution roles require both a trust policy (allowing the service principal to assume the role) and a permissions policy (granting the role access to target resources).
Question 388Question →

A developer is configuring an application running on an Amazon EC2 instance in Account B (444455556666444455556666) to read objects from an Amazon S3 bucket named `data-bucket` located in Account A (111122223333111122223333). The EC2 instance uses an IAM instance profile with an IAM role named `ReaderRole`.

The developer has attached the following IAM policy to `ReaderRole` in Account B:

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

However, the application receives an AccessDenied error when attempting to download objects from `data-bucket`.

Which action should the developer take to resolve this error?

Show answer & explanation

Answer: Add a bucket policy to data-bucket in Account A that grants s3:GetObject permissions to the principal arn:aws:iam::444455556666:role/ReaderRole.

Answer

Add a bucket policy to the S3 bucket in Account A that explicitly allows the IAM role from Account B to access the objects.
For cross-account S3 access, permissions must be granted in two locations: the identity-based IAM policy in the trusted account (Account B) must allow the action, and the resource-based S3 bucket policy in the trusting account (Account A) must trust the caller's identity. Because the identity-based policy is already correctly configured in Account B, adding the bucket policy in Account A that references the caller's IAM role ARN resolves the authorization gap.

Step-by-Step Solution

1
Analyze cross-account permissions requirements.
Determine that cross-account S3 access requires authorization from both the identity-based policy in the caller's account (Account B) and the resource-based policy in the resource owner's account (Account A).
By default, cross-account access is denied unless both accounts explicitly grant permission.
2
Draft a bucket policy for the S3 bucket in Account A.
Identify that the principal in the bucket policy must target the specific IAM role ARN (arn:aws:iam::444455556666:role/ReaderRole) rather than the instance profile or the entire account.
Specifying the IAM role ARN follows the principle of least privilege, restricting access only to the container/instance running the application.
3
Apply the bucket policy in Account A.
The bucket policy is applied, linking the IAM role to the S3 resource permission, resolving the AccessDenied error.
With both policies permitting the action, the IAM evaluation engine successfully authorizes the request.

Key Concept

Cross-Account IAM Resource Authorization
Question 389Question →

A developer is configuring a Lambda function named `DataProcessor` in AWS Account A (111122223333111122223333) to write records to an Amazon DynamoDB table in AWS Account B (444455556666444455556666). The Lambda function's execution role is named `LambdaExecutionRole`.

To facilitate cross-account access, the developer creates an IAM role named `CrossAccountDynamoDbRole` in Account B with a permission policy that allows writing to the DynamoDB table. The trust policy for `CrossAccountDynamoDbRole` in Account B is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
},
"Action": "sts:AssumeRole"
}
]
}

Which TWO additional actions must the developer take to enable the Lambda function to write to the DynamoDB table? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach a permission policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the ARN of the IAM role in Account B.; Modify the Lambda function code to call the sts:AssumeRole API operation to retrieve temporary credentials, and use those credentials to instantiate the DynamoDB client.

Answer

Attach a permission policy to the Lambda execution role in Account A that allows the sts:AssumeRole action on the IAM role in Account B, and modify the Lambda function code to retrieve temporary credentials using the sts:AssumeRole API operation to initialize the DynamoDB client.
To successfully establish cross-account access via role assumption, a developer must configure both sides of the relationship: the trusting account (Account B) must allow the trusted entity (the Lambda execution role in Account A) to assume the role, and the trusted entity must have permissions to perform the assumption action. Finally, the application code must actively assume the role to acquire temporary credentials for accessing the target resource.

Step-by-Step Solution

1
Configure the identity-based policy in Account A.
Attached a policy to the Lambda execution role that grants permission to assume the cross-account role.
Before an IAM role can be assumed, the caller (Lambda execution role) must be explicitly granted the sts:AssumeRole permission in its identity-based policy.
2
Implement role assumption in the Lambda function code.
The Lambda function uses the AWS SDK to call the sts:AssumeRole API.
Retrieving temporary security credentials for the target role allows the application to authenticate using an identity from the target account (Account B).
3
Initialize the DynamoDB client with temporary credentials.
The DynamoDB client is instantiated using the temporary Access Key ID, Secret Access Key, and Session Token.
This ensures that subsequent PutItem API requests to the DynamoDB table in Account B are authorized under the permissions of the assumed role.

Key Concept

Cross-account IAM role assumption
Question 390Question →

An AWS Lambda function in Account A (111111111111111111111111) uses its execution role, `LambdaExecutionRole`, to retrieve parameters from AWS Systems Manager Parameter Store in Account B (222222222222222222222222). To perform this task, the function's code executes an AWS STS `AssumeRole` API call targeting an IAM role in Account B named `ParameterReaderRole`. Although `LambdaExecutionRole` is granted permissions to perform `sts:AssumeRole` on the target resource, the invocation fails with an `AccessDenied` error. The trust policy for `ParameterReaderRole` is configured as follows:

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

How should the developer modify the trust policy of `ParameterReaderRole` to resolve this issue?

Show answer & explanation

Answer: Change the Principal block in the trust policy of ParameterReaderRole to reference the Lambda function's execution role ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".

Answer

Change the Principal block in the trust policy of ParameterReaderRole to reference the Lambda function's execution role ARN: "AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole".
The correct answer is the option proposing to change the Principal block to reference the Lambda function's execution role ARN. When a Lambda function runs code that calls `sts:AssumeRole`, the identity making the request is the function's execution role. Therefore, the trust policy of the target role in Account B must explicitly specify that execution role as a trusted principal to allow the cross-account role assumption to succeed.

Step-by-Step Solution

1
Identify the caller initiating the sts:AssumeRole API call.
The caller is the Lambda function running under the credentials of its execution role: arn:aws:iam::111111111111:role/LambdaExecutionRole.
When a Lambda function executes code to assume a role, the execution role is the IAM identity that performs the action.
2
Analyze the existing trust policy of the destination IAM role (ParameterReaderRole) in Account B.
The trust policy currently trusts the service principal 'lambda.amazonaws.com'.
This configuration allows the Lambda service itself to assume the role (e.g., as a function execution role), but does not trust the execution role of a specific function in another account.
3
Modify the trust policy principal to match the caller.
The principal block is updated to trust the ARN of the Lambda execution role in Account A.
To establish a cross-account trust relationship, the trust policy in the target account must explicitly list the trusted IAM entity (the execution role) from the source account as the principal.

Key Concept

Cross-Account IAM Role Assumption and Trust Policies
Estimated Time:1m 30s
PreviousPage 20 / 20
Security Practice Questions — AWS Certified Developer - Associate — Page 20 | Examkin