IAM Policies and Roles

90 soru

Soru 1Soru

A developer is implementing an AWS Lambda function in Account A (111111111111111111111111) that needs to retrieve database credentials stored as a secure parameter in the Systems Manager Parameter Store in Account B (222222222222222222222222). The parameter is encrypted using an AWS KMS customer managed key (CMK) in Account B. The developer intends to use the AWS Security Token Service (STS) to assume an IAM role named `DbConfigReaderRole` in Account B.

The Lambda function is associated with an execution role named `LambdaExecutionRole` in Account A.

Which of the following configuration steps must be performed to allow the Lambda function to retrieve the configuration parameter? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: In Account B, configure the trust policy for `DbConfigReaderRole` to allow the principal `arn:aws:iam::111111111111:role/LambdaExecutionRole` to perform the `sts:AssumeRole` action.; In Account A, attach a policy to `LambdaExecutionRole` that grants `sts:AssumeRole` permissions on the resource `arn:aws:iam::222222222222:role/DbConfigReaderRole`.

Cevap

The configuration requires adding the calling role as a trusted principal in the trust policy of the target role in Account B, and granting permission to assume the target role in the identity-based policy of the caller's role in Account A.
For cross-account access via STS, two distinct components are required: the target role's trust policy must list the source principal as a trusted entity, and the source identity's permissions policy must permit the call to assume the target role.

Adım Adım Çözüm

1
Identify the cross-account trust requirement.
The target role `DbConfigReaderRole` in Account B (222222222222222222222222) must explicitly trust the Lambda execution role in Account A (111111111111111111111111) via its trust policy.
Without this trust relationship, STS will deny the assume role request from Account A's principal.
2
Identify the delegation permission requirement.
The source execution role `LambdaExecutionRole` in Account A must be granted permission to perform the `sts:AssumeRole` action on the target role's ARN in Account B.
By default, IAM execution roles do not have permission to assume arbitrary external roles; this must be explicitly allowed.
3
Differentiate trust policies from identity-based policies and resource-based policies.
Confirm that trust relationships are defined in trust policies (not identity-based policies) and that Systems Manager Parameter Store does not support resource policies.
This rules out the incorrect options that attempt to configure trust in permissions policies or use non-existent parameter resource policies.

Anahtar Kavram

IAM Policies and Roles
Tahmini Süre:2m 0s
Soru 2Soru

A developer is deploying a containerized application to Amazon Elastic Container Service (Amazon ECS) on AWS Fargate. The application needs to retrieve data from an Amazon DynamoDB table. The developer creates an IAM role named AppDynamoDBRole with a permissions policy that allows dynamodb:GetItem and dynamodb:Query operations, and configures the task definition's taskRoleArn parameter to point to this role. The trust policy for AppDynamoDBRole is configured as follows:

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

When the containerized application runs, it fails to authenticate with DynamoDB, and the container logs show an authorization error when attempting to assume the task role. Which of the following modifications to the configuration will resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Change the Service value under the Principal block in the trust policy from ecs.amazonaws.com to ecs-tasks.amazonaws.com.

Cevap

Change the Service value under the Principal block in the trust policy from ecs.amazonaws.com to ecs-tasks.amazonaws.com.
The correct option is changing the Service principal to ecs-tasks.amazonaws.com. When configuring an ECS task definition, the taskRoleArn parameter allows containerized applications to make authorized AWS API calls. To enable this, the ECS agent must assume the designated IAM role. The trust relationship policy of the IAM role must explicitly allow the ECS tasks service principal (ecs-tasks.amazonaws.com) to perform the sts:AssumeRole action.

Adım Adım Çözüm

1
Examine the trust policy of the IAM role to determine who is permitted to assume it.
The current trust policy permits the ecs.amazonaws.com service principal to assume the role.
This determines if the correct AWS service or identity has been granted trust.
2
Identify the service principal responsible for launching and executing ECS tasks.
ECS tasks run under the ecs-tasks.amazonaws.com service principal, whereas service-level control plane operations run under ecs.amazonaws.com.
The correct service principal must match the specific entity requesting the sts:AssumeRole action.
3
Update the trust policy to authorize the ecs-tasks.amazonaws.com service principal.
The ECS agent can now successfully assume the AppDynamoDBRole on behalf of the containerized application.
This establishes a valid trust relationship, resolving the authorization error.

Anahtar Kavram

IAM trust policies for Amazon ECS tasks must trust the ecs-tasks.amazonaws.com service principal to allow the ECS agent to assume the task role on behalf of containers.
Tahmini Süre:2m 0s
Soru 3Soru

A developer is configuring an AWS Lambda function in Account A (111122223333111122223333) to write data to an Amazon DynamoDB table in Account B (444455556666444455556666) by assuming an IAM role named `CrossAccountDynamoDBRole` in Account B. The Lambda function's execution role in Account A is named `LambdaExecutionRole`.

When the Lambda function invokes the `AssumeRole` API call using the AWS SDK, the execution fails with the following error:
`User: arn:aws:sts::111122223333:assumed-role/LambdaExecutionRole/my-function is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::444455556666:role/CrossAccountDynamoDBRole`

Which TWO configurations must the developer implement to resolve this error?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Add a permission policy to the LambdaExecutionRole in Account A that allows the sts:AssumeRole action on arn:aws:iam::444455556666:role/CrossAccountDynamoDBRole.; Configure the trust policy of CrossAccountDynamoDBRole in Account B to allow the sts:AssumeRole action for the principal arn:aws:iam::111122223333:role/LambdaExecutionRole.

Cevap

To allow the Lambda function to perform cross-account access, the developer must grant the sts:AssumeRole permission to the Lambda execution role in Account A and configure the target role in Account B to trust the Lambda execution role in Account A.
The correct configurations involve setting up both sides of the trust boundary. First, the calling role in Account A must be granted permission to perform the sts:AssumeRole action. Second, the trust policy of the target role in Account B must be updated to trust the calling role in Account A as the principal.

Adım Adım Çözüm

1
Analyze the error message and the configuration requirements.
The error indicates that the Lambda execution role in Account A is not authorized to perform sts:AssumeRole on the cross-account role in Account B.
For cross-account role assumption to succeed, two permissions must match: the caller role must have a permission policy allowing sts:AssumeRole, and the destination role must have a trust policy allowing the caller role to assume it.
2
Configure the calling side (Account A).
Attach an IAM policy to the LambdaExecutionRole allowing the action sts:AssumeRole on the resource arn:aws:iam::444455556666:role/CrossAccountDynamoDBRole.
This grants the source role the necessary authorization to call the STS AssumeRole API.
3
Configure the receiving side (Account B).
Update the trust policy of CrossAccountDynamoDBRole to specify the ARN of the LambdaExecutionRole (arn:aws:iam::111122223333:role/LambdaExecutionRole) as the principal and allow sts:AssumeRole.
This establishes the trust relationship, allowing the principal from Account A to assume the role in Account B.

Anahtar Kavram

Cross-account IAM role assumption requires configuration on both the source account (identity policy permitting sts:AssumeRole) and the destination account (trust policy permitting the source identity).
Soru 4Soru

A developer is deploying an application on an Amazon EC2 instance. The application is configured to read configuration templates from an Amazon S3 bucket. The developer creates an IAM role named `AppConfigReadRole` with an attached policy that allows `s3:GetObject` on the target bucket. However, the application fails to retrieve the templates and receives an 'Access Denied' error. The developer inspects the trust policy of `AppConfigReadRole` and finds the following document:

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

Which of the following modifications to the trust policy will resolve the Access Denied error and allow the EC2 instance to assume the role?

Cevabı ve açıklamayı göster

Cevap: Change the principal service in the trust policy from `lambda.amazonaws.com` to `ec2.amazonaws.com`.

Cevap

Changing the service principal in the trust policy from `lambda.amazonaws.com` to `ec2.amazonaws.com`.
The trust policy of an IAM role determines which principals are allowed to assume it. For an application running on an Amazon EC2 instance to assume a role via an instance profile, the role's trust policy must specify the EC2 service principal (`ec2.amazonaws.com`) under the `Principal.Service` key, along with the `sts:AssumeRole` action. The original policy mistakenly trusted the Lambda service principal (`lambda.amazonaws.com`), which prevented the EC2 instance from assuming the role.

Adım Adım Çözüm

1
Identify the compute environment where the application is running.
The application is running on an Amazon EC2 instance.
Understanding the host environment determines which AWS service principal needs permission to assume the IAM role.
2
Examine the trust policy of the `AppConfigReadRole` IAM role.
The principal is currently set to `lambda.amazonaws.com`.
An incorrect principal in a trust policy prevents the target service (EC2) from obtaining temporary credentials to assume the role.
3
Update the trust policy principal to match the hosting service.
Replace `lambda.amazonaws.com` with `ec2.amazonaws.com` in the trust policy.
This configures the role to trust the EC2 service, allowing the EC2 instance profile to successfully assume the role and access the S3 bucket.

Anahtar Kavram

IAM Role Trust Policies vs Permission Policies for EC2 Instances
Soru 5Soru

A developer is configuring an AWS Step Functions state machine to orchestrate a serverless workflow. The state machine needs to invoke an AWS Lambda function and publish execution status updates to an Amazon SNS topic. During testing, the state machine execution fails with an IAM authorization error. Which of the following configurations are required to resolve this issue and grant the state machine the necessary permissions? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Attach an IAM role to the Step Functions state machine with a trust policy that allows the `states.amazonaws.com` service principal to perform the `sts:AssumeRole` action.; Attach a permissions policy to the Step Functions execution role that allows the `lambda:InvokeFunction` action on the Lambda function's ARN and the `sns:Publish` action on the SNS topic's ARN.

Cevap

To resolve the authorization issue, you must configure a trust policy on the Step Functions execution role allowing the `states.amazonaws.com` service principal to perform `sts:AssumeRole`, and attach a permissions policy to that execution role that allows the `lambda:InvokeFunction` and `sns:Publish` actions on the target resource ARNs.
AWS Step Functions must assume an IAM role to perform tasks like invoking Lambda functions or publishing messages to SNS. For the service to assume this role, the trust policy must explicitly allow the `states.amazonaws.com` service principal to perform the `sts:AssumeRole` action. Additionally, the role itself must be granted permissions via an attached permissions policy to perform `lambda:InvokeFunction` and `sns:Publish` on the specific resources.

Adım Adım Çözüm

1
Determine the executing principal that requires access.
The executing principal is the AWS Step Functions service (`states.amazonaws.com`).
Step Functions requires an IAM execution role to make API calls to other AWS resources on behalf of the user.
2
Establish the trust relationship for the execution role.
Add a trust policy to the role allowing `states.amazonaws.com` to call `sts:AssumeRole`.
Without this trust policy, the Step Functions service cannot assume the role to retrieve temporary security credentials.
3
Define the resource permissions for the execution role.
Attach an identity-based permissions policy granting `lambda:InvokeFunction` and `sns:Publish` on the respective ARNs.
Once the role is assumed, Step Functions must have the explicit authorization to perform the required actions on the target resources.

Anahtar Kavram

Configuring IAM execution roles requires establishing a trust policy that permits the calling service principal to assume the role, combined with a permissions policy that grants the role access to perform actions on specific resources.
Soru 6Soru

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

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

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

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

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

Cevap

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

Adım Adım Çözüm

1
Differentiate between the ECS Task Role and the ECS Task Execution Role.
The application code running inside the container uses the ECS Task Role for AWS API permissions. The ECS Task Execution Role is used only by the container agent for setup tasks.
This determines which role identity makes the sts:AssumeRole call.
2
Configure the trust relationship in Account B.
The role CrossAccountS3Writer in Account B must list the ECS Task Role (arn:aws:iam::111122223333:role/ecsTaskRole) as a trusted entity in its assume role policy document.
This permits the application running under the Task Role identity to assume the target role.
3
Utilize temporary credentials in the application.
Capture the AccessKeyId, SecretAccessKey, and SessionToken returned by the AssumeRole API call and pass them to the AWS SDK client builder.
The client must use these temporary credentials rather than its default credentials to access the cross-account S3 bucket.

Anahtar Kavram

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

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

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

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

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

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

Cevap

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

Adım Adım Çözüm

1
Analyze the error message and the trust policy structure.
The error is AccessDenied during sts:AssumeRole while trying to pass session tags, and the trust policy only permits sts:AssumeRole.
AWS STS requires explicit permission for the sts:TagSession action in the trust policy to allow callers to pass session tags.
2
Evaluate the caller's permissions.
The caller (AppDeveloper) must also have permissions to perform both sts:AssumeRole and sts:TagSession in their identity-based policy.
AWS security requires authorization on both the resource (the role trust policy) and the caller (identity-based policy) for session tag operations.
3
Differentiate between aws:RequestTag and aws:PrincipalTag.
Confirm that aws:RequestTag is the correct key because tags are passed in the request, not already attached to the user.
aws:RequestTag evaluates the tags that are passed in the API call request, whereas aws:PrincipalTag evaluates the tags attached to the calling principal.

Anahtar Kavram

IAM Session Tags and sts:TagSession Authorization
Soru 8Soru

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

Trust Policy:

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

Permissions Policy:

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

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

python
import boto3
import os

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

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

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

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

Cevabı ve açıklamayı göster

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

Cevap

The authorization failure is caused by the explicit initialization of the boto3 client with fallback dummy credentials, which bypasses the default credential provider chain. To resolve this, initialize the client using `boto3.client('s3')` without passing explicit credentials.
The correct answer explains that explicitly initializing the SDK client with credentials (in this case, fallback dummy values because the environment variables were unset) bypasses the default credential provider chain. In a Lambda environment, the execution role's temporary credentials are automatically made available to the SDK via standard environment variables. By removing the explicit credential parameters, the SDK successfully falls back to the default provider chain and automatically retrieves the correct execution role credentials.

Adım Adım Çözüm

1
Analyze the boto3 client initialization code.
The code uses `os.environ.get()` with fallback hardcoded dummy credentials ('AKIAIOSFODNN7EXAMPLE' and 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY') for the `aws_access_key_id` and `aws_secret_access_key` arguments.
To determine how the SDK is obtaining authentication credentials.
2
Evaluate the execution environment state.
The `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables are not set in the Lambda configuration, causing the SDK to use the fallback dummy strings.
To verify if the environment overrides the hardcoded fallback credentials.
3
Understand the default credential provider chain behavior in AWS Lambda.
Explicitly passing credentials to `boto3.client()` overrides the default provider chain. Normally, the SDK would automatically resolve the execution role's temporary credentials injected by the Lambda service.
To identify why the function is not using the assigned `LambdaS3ReaderRole` permissions.
4
Apply the resolution by removing the hardcoded fallback parameters.
Initializing the client as `boto3.client('s3')` allows the default credential provider chain to retrieve the role's temporary credentials, resolving the AccessDenied error.
To restore standard IAM role execution credentials usage.

Anahtar Kavram

AWS SDK Default Credential Provider Chain and Lambda Execution Roles
Tahmini Süre:3m 0s
Soru 9Soru

A developer is implementing a serverless application where an AWS Lambda function in Account A (111122223333111122223333) needs to access a DynamoDB table in Account B (444455556666444455556666). The developer creates an IAM role named `CrossAccountDynamoDBRole` in Account B that has the required permissions to access the DynamoDB table. The Lambda function is configured with an execution role named `arn:aws:iam::111122223333:role/LambdaExecutionRole` and runs code that calls the `AssumeRole` API of AWS Security Token Service (STS) to assume `CrossAccountDynamoDBRole`.

However, when the Lambda function runs, the `AssumeRole` call fails with an `AccessDenied` error. The developer reviews the trust policy of `CrossAccountDynamoDBRole` in Account B:

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

Which modification to the trust policy of `CrossAccountDynamoDBRole` in Account B will resolve this error?

Cevabı ve açıklamayı göster

Cevap: Update the `Principal` block to reference the ARN of the Lambda function's IAM execution role in Account A:

"Principal": {
"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"
}

Cevap

Update the Principal block of the target role's trust policy in Account B to trust the Lambda execution role's ARN in Account A.
The correct option is correct because when Lambda code runs, the AWS SDK client initiates API calls signed with the function's execution role credentials. To assume the cross-account role, the trust policy in Account B must specify the caller's IAM execution role ARN (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) as the principal in the trust relationship statement.

Adım Adım Çözüm

1
Analyze the IAM configuration and identify the entity calling the `AssumeRole` API.
The Lambda function uses its execution role (`arn:aws:iam::111122223333:role/LambdaExecutionRole`) to sign and execute AWS API requests, including `sts:AssumeRole`.
When a function runs, it uses the temporary credentials of its execution role to authorize all actions.
2
Inspect the trust policy of the target role `CrossAccountDynamoDBRole` in Account B.
The current trust policy only allows the service principal `lambda.amazonaws.com` to assume the role.
This configuration is for allowing the Lambda service to assume an execution role, not for allowing an assumed role to call another role.
3
Update the trust policy of the target role to authorize the correct principal.
The principal is changed to `"AWS": "arn:aws:iam::111122223333:role/LambdaExecutionRole"`.
This establishes a cross-account trust relationship allowing the execution role in Account A to assume the role in Account B.

Anahtar Kavram

Cross-Account IAM Roles and Service vs. AWS Principals
Soru 10Soru

A developer is setting up an application on an on-premises server that must archive daily transaction logs to a private Amazon S3 bucket. To implement this securely without storing long-term credentials on the server, the developer creates an IAM User named `archive-agent` in the AWS account `111122223333` and an IAM Role named `S3UploaderRole` that has permissions to write to the S3 bucket. The application will authenticate as `archive-agent` using short-term configurations and then assume `S3UploaderRole` to perform the S3 uploads.

Which two configuration policies are required to establish this role-assumption trust relationship and grant the necessary permissions? (Select two.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: A trust policy attached to S3UploaderRole that allows the archive-agent user to assume the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "sts:AssumeRole"
}
]
}
; A permissions policy attached to the archive-agent user that permits calling sts:AssumeRole on the role:

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

Cevap

To establish the trust relationship and grant permissions, the developer must attach a trust policy to the S3UploaderRole that lists the archive-agent user as the trusted principal allowed to perform the sts:AssumeRole action, and attach an IAM permissions policy to the archive-agent user that permits calling sts:AssumeRole on the role's Amazon Resource Name (ARN).
Role assumption is a two-way handshake. The trust policy attached to the S3UploaderRole must declare the archive-agent IAM User as a trusted principal that is permitted to execute the sts:AssumeRole action. Simultaneously, the archive-agent user must possess a permissions policy that explicitly permits it to perform the sts:AssumeRole action against the target role's ARN. This combination ensures that the user is authorized to request the role and the role is authorized to trust the user.

Adım Adım Çözüm

1
Configure the trust policy on the destination IAM Role.
The target role (S3UploaderRole) allows sts:AssumeRole requests originating from the archive-agent IAM User principal.
An IAM Role's trust policy establishes which trusted identities (principals) are authorized to assume it.
2
Configure the permissions policy on the source IAM User.
The archive-agent user has explicit permission to call sts:AssumeRole on the ARN of the S3UploaderRole.
By default, IAM users do not have permissions to call STS AssumeRole; this must be explicitly granted in their permissions policy.

Anahtar Kavram

Role assumption requires permissions configured on both sides: a trust policy on the role defining who can assume it, and an identity permissions policy on the user permitting the assume role action.
Soru 11Soru

A developer is implementing an AWS Lambda function in AWS Account 111111111111111111111111 (Account A) that must write messages to an Amazon SQS queue in AWS Account 222222222222222222222222 (Account B). The security team requires using temporary security credentials via IAM role assumption for cross-account access. The Lambda function is configured with an execution role named `LambdaExecutionRole` in Account A.

The developer attempts to set up an IAM role in Account B named `QueueWriterRole` with the following trust policy:

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

Which of the following actions are required to successfully and securely establish this cross-account access? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Modify the trust policy of `QueueWriterRole` in Account B to replace `lambda.amazonaws.com` with `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"` in the `Principal` element.; Attach an identity-based policy to `LambdaExecutionRole` in Account A that allows the `sts:AssumeRole` action on the Amazon Resource Name (ARN) of `QueueWriterRole` in Account B.

Cevap

To establish cross-account access securely, the trust policy of the IAM role in the destination account must be updated to trust the source role's ARN, and the execution role in the source account must have an identity-based policy allowing it to perform the assume role action on the destination role.
Cross-account delegation requires configuration on both sides. First, the destination role's trust policy in Account B must define who is trusted to assume it. This is done by modifying the principal element to target the specific execution role ARN of the Lambda function. Second, the execution role in Account A must be granted permission to perform the `sts:AssumeRole` action on the destination role's ARN.

Adım Adım Çözüm

1
Inspect the initial trust policy on the role in the destination account (Account B) and identify the principal misconfiguration.
The current trust policy uses the service principal `lambda.amazonaws.com`. This configuration only allows the AWS Lambda service within the same account to assume the role directly, not a specific role from a different AWS account.
Correcting the trust relationship is necessary because cross-account trust requires specifying the specific AWS account or IAM principal in the trust policy.
2
Modify the trust policy of the target role in Account B to trust the specific IAM role in Account A.
The `Principal` element is changed to `"AWS": "arn:aws:iam::111111111111:role/LambdaExecutionRole"`.
This establishes that the role in Account B trusts the execution role of the Lambda function in Account A.
3
Grant the execution role in Account A the permission to perform `sts:AssumeRole` on the target role in Account B.
An identity-based policy with the `sts:AssumeRole` action and the target role's ARN as the resource is attached to `LambdaExecutionRole` in Account A.
Even if the target role trusts the source role, the source role must explicitly be granted permission to perform the assume-role operation.

Anahtar Kavram

Cross-account IAM role delegation requires two-way permission configuration: a trust policy on the target role trusting the source principal, and an identity-based permission policy on the source principal allowing the assume-role action.
Soru 12Soru

A developer is configuring an AWS Lambda function to retrieve messages from an Amazon SQS queue. To follow the security principle of least privilege, the developer decides to create a custom IAM role for the Lambda function. Which of the following configurations are required to establish this access? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: An IAM permissions policy attached to the IAM role that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the specific SQS queue ARN.; An IAM trust policy on the IAM role that allows the `lambda.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

Cevap

The configurations required are: an IAM permissions policy attached to the IAM role that allows SQS actions on the queue ARN, and an IAM trust policy on the IAM role that allows the Lambda service principal to assume the role.
The correct options specify the two key components of an IAM execution role. First, the trust policy (trust relationship) is configured on the IAM role to allow the AWS Lambda service principal (lambda.amazonaws.com) to assume the role. Second, a permissions policy is attached to the IAM role to grant the permissions necessary for the function's code to run, which in this case includes actions such as reading and deleting messages from the specific SQS queue resource.

Adım Adım Çözüm

1
Configure the trust relationship on the IAM role.
The trust policy allows the AWS Lambda service principal (lambda.amazonaws.com) to assume the role using the sts:AssumeRole action.
This enables the Lambda service to obtain temporary security credentials when executing the function.
2
Configure the permissions policy on the IAM role.
The identity-based permissions policy grants the role specific access to the SQS queue resource using actions like sqs:ReceiveMessage.
This enforces the principle of least privilege, ensuring the Lambda function can only perform authorized operations on designated resources.

Anahtar Kavram

IAM Roles, Permissions Policies, and Trust Policies
Tahmini Süre:1m 30s
Soru 13Soru

A developer is configuring an AWS Lambda function in AWS Account A (111111111111) that needs to read objects from an Amazon S3 bucket in AWS Account B (222222222222) by assuming an IAM role named CrossAccountS3Reader in Account B. The Lambda function is assigned an execution role in Account A named LambdaExecutionRole. However, when the Lambda function attempts to assume the CrossAccountS3Reader role using AWS STS, the API call fails with an AccessDenied error. Which of the following configurations are required to resolve this issue? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: In Account A, attach an IAM policy to the LambdaExecutionRole that allows the sts:AssumeRole action on the ARN of the CrossAccountS3Reader role in Account B.; In Account B, update the trust policy of the CrossAccountS3Reader role to allow the ARN of the LambdaExecutionRole from Account A to perform the sts:AssumeRole action.

Cevap

In Account A, attach an IAM policy to the LambdaExecutionRole that allows the sts:AssumeRole action on the ARN of the CrossAccountS3Reader role in Account B, and in Account B, update the trust policy of the CrossAccountS3Reader role to allow the ARN of the LambdaExecutionRole from Account A to perform the sts:AssumeRole action.
For cross-account role assumption using AWS STS, two configurations are required: first, the identity-based policy of the caller (the Lambda execution role in Account A) must grant permission to perform sts:AssumeRole on the target role; second, the trust policy of the target role in Account B must trust the caller's role ARN.

Adım Adım Çözüm

1
Configure the calling principal's permissions in Account A.
Attached an identity-based IAM policy to the LambdaExecutionRole allowing sts:AssumeRole targeting the ARN of the CrossAccountS3Reader role.
The entity attempting to assume a role must have explicit permission to perform the assume-role operation.
2
Configure the target role's trust relationship in Account B.
Updated the CrossAccountS3Reader role's trust policy to include the LambdaExecutionRole ARN as a trusted principal.
The destination role must trust the specific calling identity from the external account to successfully complete the sts:AssumeRole API call.

Anahtar Kavram

Cross-account IAM role delegation using AWS STS
Soru 14Soru

A developer is deploying a Java application on Amazon EC2 instances in AWS account `123456789012`. The application requires access to retrieve database credentials from AWS Systems Manager Parameter Store. The developer creates an IAM role named `SSMParameterReaderRole` and attaches a permissions policy that allows the `ssm:GetParameter` action. The developer then configures an Amazon EC2 Instance Profile to associate the EC2 instances with this role. During startup, the application fails to retrieve the parameters, and CloudTrail logs show that the EC2 service was unable to assume the role.

The trust policy currently attached to `SSMParameterReaderRole` is as follows:

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

Which modification must the developer make to the trust policy of `SSMParameterReaderRole` to resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Update the trust policy's Principal block to specify the EC2 service principal (`"Service": "ec2.amazonaws.com"`) instead of the AWS account root principal.

Cevap

Update the trust policy's Principal block to specify the EC2 service principal (`"Service": "ec2.amazonaws.com"`) instead of the AWS account root principal.
The correct answer is to update the trust policy's Principal block to specify the EC2 service principal. When an application runs on an EC2 instance and uses an instance profile, the EC2 service must assume the associated IAM role on behalf of the instance. Therefore, the IAM role's trust policy must trust the service principal `ec2.amazonaws.com` rather than the AWS account root principal, which only allows IAM identities within the account to assume the role via direct STS calls.

Adım Adım Çözüm

1
Analyze the CloudTrail error indicating that the Amazon EC2 service is unable to assume the IAM role.
Identified that the issue is with the trust relationship of the IAM role, which defines which principals are allowed to assume it.
To allow a service like EC2 to assume a role, the trust policy must explicitly grant permission to that service principal.
2
Examine the current trust policy of the IAM role.
Observed that the Principal is set to the AWS account root (`arn:aws:iam::123456789012:root`) rather than the service principal.
The current configuration only allows IAM users or roles within the account to assume this role via STS, not the EC2 service itself.
3
Update the Principal field in the trust policy to specify the EC2 service principal.
The Principal is modified to `"Service": "ec2.amazonaws.com"`.
This allows the EC2 service to successfully perform `sts:AssumeRole` on behalf of the instance, enabling the application to access AWS resources using the instance profile.

Anahtar Kavram

IAM Role Trust Policy vs Permissions Policy
Tahmini Süre:1m 30s
Soru 15Soru

A developer is deploying a containerized application to Amazon ECS using AWS Fargate. The application needs to perform read and write operations on an Amazon DynamoDB table. Additionally, the ECS agent must pull the container image from a private Amazon ECR repository and send container startup logs to Amazon CloudWatch Logs.

To satisfy these security requirements using the principle of least privilege, how should the developer configure the IAM roles?

Cevabı ve açıklamayı göster

Cevap: Define an ECS Task Role with a permissions policy allowing DynamoDB actions and assign it to the task definition. Define an ECS Task Execution Role with a permissions policy allowing ECR and CloudWatch logs actions, and assign it as the execution role in the task definition.

Cevap

Define an ECS Task Role with a permissions policy allowing DynamoDB actions and assign it to the task definition. Define an ECS Task Execution Role with a permissions policy allowing ECR and CloudWatch logs actions, and assign it as the execution role in the task definition.
The correct configuration uses two distinct roles to enforce the principle of least privilege. The ECS Task Role is designated for credentials needed by the application itself running inside the container (e.g., calling DynamoDB APIs). The ECS Task Execution Role is designated for actions performed by the Amazon ECS container agent (e.g., pulling the Docker image from Amazon ECR and sending container logs to Amazon CloudWatch). Specifying both correctly in the task definition allows the containerized workload to execute securely.

Adım Adım Çözüm

1
Analyze the container application permissions needs.
The application inside the container makes API requests to write and read from DynamoDB.
These application-level permissions must be mapped to the ECS Task Role.
2
Analyze the infrastructure and agent permissions needs.
The ECS Fargate agent needs to pull images from ECR and write system/startup logs to CloudWatch.
These agent-level infrastructure permissions must be mapped to the ECS Task Execution Role.
3
Map roles to the ECS task definition parameters.
Assign the DynamoDB role to taskRoleArn, and the ECR/CloudWatch role to executionRoleArn.
This separation follows AWS security best practices for container permissions.

Anahtar Kavram

ECS Task Role vs ECS Task Execution Role separation of duties
Soru 16Soru

A developer is setting up an Amazon EventBridge rule to route custom application events to an Amazon Kinesis Data Firehose delivery stream. The developer creates an IAM role named `EventBridgeToFirehoseRole` to allow EventBridge to put records into the delivery stream. The IAM role has the following trust policy:

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

The permissions policy attached to the role is:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"firehose:PutRecord",
"firehose:PutRecordBatch"
],
"Resource": "arn:aws:firehose:us-east-1:123456789012:deliverystream/my-stream"
}
]
}

However, when events are triggered, EventBridge fails to send the events to the delivery stream. Which of the following changes will resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Update the IAM role trust policy to list events.amazonaws.com as the service principal instead of firehose.amazonaws.com.

Cevap

Update the IAM role trust policy to list events.amazonaws.com as the service principal instead of firehose.amazonaws.com.
The correct option is to update the trust policy because Amazon EventBridge is the service initiating the action and needs to assume the IAM role to put records into the Kinesis Data Firehose delivery stream. The trust policy governs which security principal is allowed to assume the role. Listing firehose.amazonaws.com in the trust policy is a common mistake that incorrectly trusts the destination service instead of the invoking service.

Adım Adım Çözüm

1
Identify which AWS service principal needs to assume the role to perform the action.
Amazon EventBridge (events.amazonaws.com) is the service triggering the rule and needs to write to the Firehose delivery stream.
The service invoking the target must be the one granted permission to assume the execution role.
2
Inspect the role's trust policy to verify the trusted entity.
The current trust policy lists firehose.amazonaws.com as the trusted entity.
A misconfigured trust policy will prevent the calling service (EventBridge) from assuming the role to perform downstream tasks.
3
Modify the trust policy to trust the correct calling service principal.
Change the principal service from firehose.amazonaws.com to events.amazonaws.com.
This allows EventBridge to assume the role and use the permissions granted in the permissions policy to write to Kinesis Firehose.

Anahtar Kavram

IAM Trust Policies vs. Permissions Policies
Soru 17Soru

A developer is deploying an AWS Lambda function that reads incoming user data from an Amazon Kinesis data stream. The developer creates an IAM role with a permissions policy allowing the necessary Kinesis read actions. However, the Lambda function fails to retrieve data, and the logs indicate that the Lambda service is unauthorized to assume the configured execution role.

The trust policy attached to the IAM role is shown below:

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

How should the developer resolve this issue to allow the Lambda function to execute and read from the stream?

Cevabı ve açıklamayı göster

Cevap: Change the service principal in the trust policy to "lambda.amazonaws.com" to allow the Lambda service to assume the execution role.

Cevap

Change the service principal in the trust policy to "lambda.amazonaws.com" to allow the Lambda service to assume the execution role.
To resolve the assumption failure, the trust policy of the execution role must specify lambda.amazonaws.com as the trusted service principal. This grants the AWS Lambda service the permission to assume the role and perform actions on behalf of the function.

Adım Adım Çözüm

1
Analyze the error logs and trust policy of the execution role.
The log states the Lambda service is unauthorized to assume the role, and the trust policy lists 'kinesis.amazonaws.com' as the service principal.
Understanding why the assumption failed requires verifying the trust relationship configuration.
2
Identify the service principal that needs to assume the role.
The Lambda service itself ('lambda.amazonaws.com') is responsible for assuming the execution role and running the function code.
The trust policy must grant the service running the resource the permission to call 'sts:AssumeRole'.
3
Update the trust policy's principal block.
Change 'kinesis.amazonaws.com' to 'lambda.amazonaws.com'.
This grants the Lambda service the permission to assume the execution role natively.

Anahtar Kavram

IAM trust policies define which entities (accounts, users, or AWS services) are trusted to assume an IAM role, while IAM permissions policies define what actions the assumed role can perform.
Soru 18Soru

A developer is configuring an AWS Lambda function in Account A (123456789012123456789012) to write data to an Amazon DynamoDB table in Account B (210987654321210987654321). The developer wants to use a cross-account IAM role named `DynamoDBWriterRole` in Account B to perform the DynamoDB operations. The Lambda function runs under an execution role named `LambdaExecutionRole` in Account A. Which two configurations are required to establish this cross-account trust and allow the Lambda function to write to the table? (Select TWO.)

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: A trust policy attached to the role in Account B that specifies the Lambda execution role in Account A as the principal and allows the sts:AssumeRole action.; An IAM permissions policy attached to the Lambda execution role in Account A that allows the sts:AssumeRole action on the Amazon Resource Name (ARN) of the role in Account B.

Cevap

To configure cross-account access, the developer must attach a trust policy to the role in Account B that lists the Lambda execution role in Account A as a principal and allows the sts:AssumeRole action. In addition, the developer must attach an IAM permissions policy to the Lambda execution role in Account A allowing the sts:AssumeRole action on the target role's ARN in Account B.
Establishing cross-account delegation requires both sides to agree: the target role's trust policy in Account B must trust the calling IAM entity in Account A, and the calling identity in Account A must be granted permission in its identity policy to assume that target role.

Adım Adım Çözüm

1
Configure the trust relationship on the target role in Account B.
The target role (DynamoDBWriterRole) trust policy is updated to permit the Lambda execution role ARN in Account A to perform sts:AssumeRole.
This establishes that the role in Account B trusts the specific entity in Account A to assume it.
2
Add permissions to the source Lambda execution role in Account A.
The Lambda execution role in Account A is granted identity-based permissions to call sts:AssumeRole on the ARN of DynamoDBWriterRole.
The entity in the source account must have permissions to initiate the AssumeRole call.
3
Implement the sts:AssumeRole API call in the Lambda function code.
The Lambda function uses the AWS SDK to retrieve temporary security credentials and uses them to write to the DynamoDB table.
This allows the function to execute operations with the authorization level of the target role in Account B.

Anahtar Kavram

Cross-account IAM Role Delegation
Tahmini Süre:2m 0s
Soru 19Soru

A developer is configuring an AWS CodeBuild project in Account 111111111111111111111111 that must retrieve database configuration credentials from AWS Systems Manager Parameter Store in Account 222222222222222222222222. The developer creates an IAM role named CrossAccountParamReaderRole in Account 222222222222222222222222 with permission to read the parameters.

The CodeBuild project's service role in Account 111111111111111111111111 has permissions to assume CrossAccountParamReaderRole. However, during the build phase, the CodeBuild build fails with an AccessDenied error when executing the assume-role CLI command.

The trust policy for CrossAccountParamReaderRole in Account 222222222222222222222222 is configured as follows:

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

Which modification to the trust policy in Account 222222222222222222222222 will resolve this issue?

Cevabı ve açıklamayı göster

Cevap: Update the Principal block of the trust policy to reference Account 111111111111111111111111 or the specific CodeBuild service role ARN instead of the CodeBuild service principal.

Cevap

Update the Principal block of the trust policy to reference Account 111111111111111111111111 or the specific CodeBuild service role ARN instead of the CodeBuild service principal.
To allow an IAM identity (such as a role or user) from another AWS account to assume an IAM role, the target role's trust policy must specify that external account or the specific IAM identity as a trusted principal. The original trust policy only trusts the regional AWS CodeBuild service principal within the same account (Account 222222222222222222222222). Updating the Principal block to trust Account 111111111111111111111111 (or the specific CodeBuild service role in Account 111111111111111111111111) permits the STS AssumeRole request to succeed.

Adım Adım Çözüm

1
Identify the type of policy configuration error.
The current trust policy only trusts the regional 'codebuild.amazonaws.com' service within its own account (Account 222222222222222222222222).
For cross-account access, a trust policy must explicitly trust the external account or the specific identity attempting to assume the role.
2
Select the correct Principal modification.
Changing the Principal to target Account 111111111111111111111111 or the specific CodeBuild service role ARN allows the delegation of authority.
This establishes the trust boundary between the two AWS accounts so that sts:AssumeRole calls from Account 111111111111111111111111 are accepted.

Anahtar Kavram

IAM trust policies vs identity-based policies in cross-account access
Soru 20Soru

A developer is configuring a local application to access an Amazon DynamoDB table in an AWS account. To comply with security best practices, the application must run locally by assuming an IAM role named DbAccessRole using temporary credentials. The developer has a local AWS CLI profile named dev-user configured with IAM user credentials.

Which two actions must the developer take to configure the application to assume the role?

Geçerli olan tümünü seçin

Cevabı ve açıklamayı göster

Cevap: Define a new profile in the local ~/.aws/config file, specifying the role_arn of DbAccessRole and setting the source_profile to dev-user.; Configure the trust policy of DbAccessRole to allow the sts:AssumeRole action for the ARN of the dev-user IAM user.

Cevap

Define a new profile in the local ~/.aws/config file, specifying the role_arn of DbAccessRole and setting the source_profile to dev-user. Also, configure the trust policy of DbAccessRole to allow the sts:AssumeRole action for the ARN of the dev-user IAM user.
The correct configuration requires both configuring the target role to trust the specific IAM user, and setting up the local CLI configuration to chain the profiles. Specifying the role_arn and source_profile in ~/.aws/config tells the AWS SDK or CLI to use the credentials from the source profile to call sts:AssumeRole for the target role. The target role's trust policy must list the IAM user as a principal and allow the sts:AssumeRole action.

Adım Adım Çözüm

1
Configure the IAM role trust relationship.
The role DbAccessRole is configured to trust the dev-user IAM user.
Before any principal can assume an IAM role, that principal must be explicitly trusted by the role's trust policy via the sts:AssumeRole action.
2
Configure the local AWS configuration profile.
A profile in ~/.aws/config is created that links the credentials profile to the target role.
Using the ~/.aws/config profile chaining mechanism allows the AWS CLI and SDKs to automatically handle the sts:AssumeRole API call and manage the lifecycle of temporary credentials without hardcoding secrets.

Anahtar Kavram

IAM role assumption requires a trust policy specifying the trusted principal, and client applications can use profile chaining in the local configuration to automatically retrieve temporary credentials.
Sayfa 1 / 5Sonraki