All practice questions

976 questions

Question 521Question

A SysOps administrator has created a new subnet within a VPC and launched a test Amazon EC2 instance inside it. The instance is assigned a public IPv4 address, and its security group allows all outbound traffic. However, the administrator is unable to connect to the internet from the instance. Upon checking the subnet's associated route table, the administrator notices it only contains the default local route.

Which route must be added to the route table to enable internet access from this subnet?

Show answer & explanation

Answer: A route with a destination of 0.0.0.0/00.0.0.0/0 pointing to the Internet Gateway (IGW) attached to the VPC.

Answer

A route with a destination of 0.0.0.0/00.0.0.0/0 pointing to the Internet Gateway (IGW) attached to the VPC.
To enable outbound and inbound internet access for EC2 instances with public IP addresses in a public subnet, the subnet's route table must include a default route (0.0.0.0/00.0.0.0/0) pointing to the Internet Gateway (IGW) attached to the VPC. This allows the VPC to route external traffic to and from the public internet.

Step-by-Step Solution

1
Review the subnet's current route table rules.
The route table only contains the default local route (e.g., 10.0.0.0/1610.0.0.0/16 pointing to local).
To identify if a path to the internet is defined at the network routing layer.
2
Determine the appropriate target for internet-bound traffic in a public subnet.
An Internet Gateway (IGW) must be targeted for public subnets where instances have public IP addresses.
The IGW performs the necessary 1-to-1 NAT translation between the instance's private IP and its public IP, allowing direct communication with the internet.
3
Add the default route to the route table.
A route with destination 0.0.0.0/00.0.0.0/0 is added, pointing to the IGW ID (e.g., igw-xxxxxxxx).
This directs all non-local traffic to the Internet Gateway, enabling internet connectivity.

Key Concept

Configuring a public subnet route table with a route to an Internet Gateway (IGW) to enable internet connectivity for EC2 instances with public IP addresses.
Question 522Question

An EC2 instance is located in private Subnet A (CIDR 10.0.1.0/2410.0.1.0/24) and needs to download software updates from an external repository at IP address 203.0.113.50203.0.113.50 over HTTPS (port 443443). The instance routes all outbound internet traffic through a NAT Gateway located in public Subnet B (CIDR 10.0.2.0/2410.0.2.0/24). The EC2 instance is associated with a Security Group that allows all outbound traffic but has no inbound rules. Subnet A is associated with a Network Access Control List (NACL-A) that has an inbound rule (Rule 100100) allowing TCP port 443443 from 0.0.0.0/00.0.0.0/0 and an outbound rule (Rule 100100) allowing TCP port 443443 to 0.0.0.0/00.0.0.0/0. Subnet B is associated with a Network Access Control List (NACL-B) that allows all inbound and outbound traffic. Despite this configuration, the EC2 instance fails to connect to the external repository. Which action will resolve this connectivity issue?

Show answer & explanation

Answer: Add an inbound rule to NACL-A that allows TCP traffic on ports 10241024-6553565535 from 0.0.0.0/00.0.0.0/0.

Answer

Add an inbound rule to NACL-A that allows TCP traffic on ports 10241024-6553565535 from 0.0.0.0/00.0.0.0/0.
Network Access Control Lists (NACLs) are stateless, which means they do not track connection states and require explicit inbound and outbound rules for communication to succeed. When the EC2 instance initiates an outbound connection to the external repository on TCP port 443443, the repository sends the response packets back to the instance's ephemeral ports, which are within the range 10241024-6553565535. Since NACL-A only has an inbound rule allowing port 443443 (which would only match incoming requests to a web server hosted on the instance), the response traffic to the ephemeral ports is blocked by the default deny rule. Adding an inbound rule to NACL-A for TCP ports 10241024-6553565535 from 0.0.0.0/00.0.0.0/0 allows the response traffic to reach the EC2 instance.

Step-by-Step Solution

1
Analyze the statefulness of the security components in the traffic path.
The Security Group is stateful and already permits all outbound traffic, meaning it automatically allows response traffic. However, the NACL (NACL-A) is stateless, so outbound requests and inbound responses must both be explicitly permitted by rules.
Troubleshooting network security controls requires distinguishing between the stateful nature of Security Groups and the stateless nature of NACLs.
2
Determine the destination port of the return traffic from the external repository.
The client initiates a connection to port 443443. The response traffic sent back by the repository targets the client's randomly allocated ephemeral port (range 10241024-6553565535).
Standard TCP client-server communications use ephemeral ports on the client side to receive return packets.
3
Evaluate the existing inbound rules in NACL-A.
NACL-A's inbound Rule 100100 only allows traffic targeting destination port 443443. It does not cover the ephemeral ports (10241024-6553565535) where the return traffic is destined, causing the return packets to be dropped by the default deny rule.
Identifying the specific blocked port in the stateless firewall explains why the TCP handshake cannot complete.
4
Identify the configuration change needed to permit the return traffic.
Adding an inbound rule to NACL-A allowing TCP traffic on ports 10241024-6553565535 from 0.0.0.0/00.0.0.0/0 will allow the return traffic to pass through the stateless firewall to the private EC2 instance.
This configuration correctly accounts for the return path of stateless network connections.

Key Concept

Stateless Network Access Control Lists (NACLs) require explicit rules for return traffic using ephemeral ports, whereas stateful Security Groups automatically allow return traffic.
Question 523Question

An organization is auditing its KMS key configurations. A SysOps Administrator is reviewing a customer managed key (CMK) in Account 111122223333111122223333. The key is used to encrypt an Amazon S3 bucket containing sensitive compliance logs.

The KMS key policy is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Allow Key Administration",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/AdminRole"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:TagResource",
"kms:UntagResource",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
},
{
"Sid": "Allow S3 Service Access",
"Effect": "Allow",
"Principal": {
"Service": "s3.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
]
}

An IAM role in the same account (111122223333111122223333), `AppExecutionRole`, needs to read objects from this S3 bucket. The administrator attaches the following IAM policy to `AppExecutionRole`:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "S3AndKMSRead",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"kms:Decrypt"
],
"Resource": [
"arn:aws:s3:::compliance-logs-111122223333/*",
"arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab"
]
}
]
}

However, when an application using the `AppExecutionRole` attempts to retrieve an object from the S3 bucket, it receives an "Access Denied" error from KMS.

Which action should the SysOps Administrator take to resolve this issue?

Show answer & explanation

Answer: Add a statement to the KMS key policy that grants the AWS account root principal (`arn:aws:iam::111122223333:root`) access to the `kms:*` actions on the key, allowing IAM policies to delegate permissions.

Answer

Add a statement to the KMS key policy that grants the AWS account root principal (`arn:aws:iam::111122223333:root`) access to the `kms:*` actions on the key, allowing IAM policies to delegate permissions.
The correct action is to add the account root principal statement to the KMS key policy. Unlike other AWS resources where IAM policies are sufficient if they are in the same account, KMS requires that the key policy explicitly allows the actions or delegates access control to the account's IAM policies. By adding a statement that grants the root principal (`arn:aws:iam::111122223333:root`) access to `kms:*`, you enable the account's IAM policies to delegate access to the key. This allows the IAM policy attached to the `AppExecutionRole` to take effect.

Step-by-Step Solution

1
Identify the authorization model for AWS KMS keys.
KMS key policies are the primary authorization mechanism, and IAM policies are ignored unless the key policy explicitly delegates authority to IAM.
To understand why the application is getting 'Access Denied' despite having a valid IAM policy.
2
Examine the provided KMS key policy for IAM delegation.
The key policy allows access only to `AdminRole` and the S3 service principal (`s3.amazonaws.com`). It does not contain a statement delegating authority to the AWS account root principal (`arn:aws:iam::111122223333:root`).
To diagnose why the IAM policy on `AppExecutionRole` is not taking effect.
3
Determine the correct modification to allow IAM policies to grant access.
Add a statement to the KMS key policy that grants the root account (`arn:aws:iam::111122223333:root`) permissions for `kms:*` on the key.
This delegates key access control to the account's IAM policies, enabling the IAM policy attached to `AppExecutionRole` to successfully grant access.

Key Concept

AWS KMS Key Policy vs IAM Policy precedence and the requirement of root principal delegation to enable IAM-based KMS authorizations.
Estimated Time:2m 30s
Question 524Question

An enterprise requires a centralized security auditing strategy across its multi-account environment. A SysOps Administrator is tasked with configuring a multi-region trail that delivers logs to a central Amazon S3 bucket located in a dedicated logging account. The logs must be encrypted at rest using an AWS Key Management Service (AWS KMS) customer managed key. Which two configuration steps are required to establish this secure logging and monitoring flow? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach a policy to the KMS key that grants `kms:GenerateDataKey*` and `kms:DescribeKey` permissions to the `cloudtrail.amazonaws.com` service principal, restricting the source trail using the `aws:SourceArn` condition.; Configure the S3 bucket policy in the logging account to allow the `cloudtrail.amazonaws.com` service principal to perform `s3:PutObject` operations, requiring the `s3:x-amz-acl` condition to be set to `bucket-owner-full-control`.

Answer

The correct configuration requires attaching a KMS key policy that permits `kms:GenerateDataKey*` and `kms:DescribeKey` to the CloudTrail service principal with an `aws:SourceArn` condition, and configuring the S3 bucket policy in the logging account to permit `s3:PutObject` operations from the CloudTrail service principal with the `bucket-owner-full-control` ACL condition.
The correct steps involve granting CloudTrail the necessary permissions to write logs to the target S3 bucket and encrypt them using the KMS customer managed key. The S3 bucket policy must allow `s3:PutObject` with the `bucket-owner-full-control` ACL requirement so that the destination logging account owns the logs. The KMS key policy must allow `kms:GenerateDataKey*` and `kms:DescribeKey` to encrypt the logs, restricted by `aws:SourceArn` for security.

Step-by-Step Solution

1
Configure S3 permissions for CloudTrail log delivery
The S3 bucket policy is updated to allow `s3:PutObject` from `cloudtrail.amazonaws.com` and enforces the `s3:x-amz-acl` header to ensure bucket owner full control.
This allows CloudTrail to write log files into the centralized bucket across accounts while retaining ownership of the objects in the logging account.
2
Configure KMS key policy for CloudTrail encryption
The customer managed key policy is updated to grant `kms:GenerateDataKey*` and `kms:DescribeKey` permissions to `cloudtrail.amazonaws.com` with `aws:SourceArn` condition.
This allows CloudTrail to encrypt the log files before putting them into the S3 bucket using a secure, trail-restricted key.

Key Concept

CloudTrail log encryption and S3 delivery access control using resource-based policies.
Estimated Time:3m 0s
Question 525Question

A SysOps administrator is configuring an AWS Database Migration Service (DMS) replication task to migrate data to an Amazon S3 target bucket. The administrator creates an IAM role named dms-s3-role to grant AWS DMS permissions to write to the S3 bucket. The trust policy of the role is configured to trust the DMS service principal. However, when the administrator attempts to create the S3 endpoint using the AWS Management Console and associates the dms-s3-role with it, the operation fails with an Access Denied error.

Which of the following actions must the SysOps administrator perform to successfully associate the IAM role with the endpoint? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM identity that grants the iam:PassRole permission for the dms-s3-role resource.; Ensure that the trust policy of the dms-s3-role allows the dms.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

To resolve the Access Denied error, the SysOps administrator must attach an IAM policy to their own identity granting iam:PassRole permission on the target role, and ensure the target role's trust policy permits the dms.amazonaws.com service principal to assume it.
To successfully configure an AWS service to act on your behalf, two conditions must be met: the user configuring the service must have the iam:PassRole permission for the target role, and the role's trust policy must allow the service principal (dms.amazonaws.com) to assume the role via the sts:AssumeRole action.

Step-by-Step Solution

1
Determine why the role assignment is failing.
Identify that the administrator requires permission to delegate (pass) the dms-s3-role to the AWS DMS service.
AWS prevents unauthorized users from passing powerful IAM roles to services by requiring the iam:PassRole permission on the user's policy.
2
Verify that the AWS service is trusted to assume the role.
Ensure the service principal dms.amazonaws.com is listed in the trust relationship policy of the dms-s3-role.
An AWS service cannot assume an IAM role unless the role's trust policy explicitly allows the service principal to perform the sts:AssumeRole action.

Key Concept

Delegating permissions to AWS services requires the user to have iam:PassRole permission and the service role to trust the specific AWS service principal.
Question 526Question

A SysOps administrator is troubleshooting connectivity between two VPCs: VPC A (10.0.0.0/1610.0.0.0/16) and VPC B (172.16.0.0/16172.16.0.0/16) that are connected via an active VPC peering connection. An EC2 instance in VPC A cannot establish a connection with an EC2 instance in VPC B. Which of the following routing table configurations are required to allow communication between the two VPCs? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: In the route table associated with the subnet in VPC A, add a route with a destination of 172.16.0.0/16172.16.0.0/16 and the VPC peering connection as the target.; In the route table associated with the subnet in VPC B, add a route with a destination of 10.0.0.0/1610.0.0.0/16 and the VPC peering connection as the target.

Answer

To allow communication between the two peered VPCs, routes must be added to the subnet route tables in both VPC A and VPC B pointing to the CIDR block of the peered VPC with the VPC peering connection as the target.
For two VPCs to communicate over a peering connection, bidirectional routes must be explicitly defined. The route table in the source VPC must point to the destination VPC's CIDR block using the peering connection ID as the target, and the route table in the destination VPC must have a corresponding route pointing back to the source VPC's CIDR block.

Step-by-Step Solution

1
Configure the route table in VPC A.
A route is added for destination 172.16.0.0/16172.16.0.0/16 targeting the VPC peering connection.
Allows traffic from VPC A to find the peering path to VPC B.
2
Configure the route table in VPC B.
A route is added for destination 10.0.0.0/1610.0.0.0/16 targeting the VPC peering connection.
Allows return traffic and new requests from VPC B to reach VPC A over the peering path.

Key Concept

VPC peering requires bidirectional routing updates in the subnet route tables of both VPCs involved in the peering relationship.
Question 527Question

A company's SysOps administrator is updating an AWS CloudFormation stack that manages a three-tier web application. During the update, a failure occurs, and CloudFormation attempts to roll back the stack. However, the rollback also fails, leaving the stack in the `UPDATE_ROLLBACK_FAILED` state. Investigations show that the CloudFormation service role (`RoleARN`) is missing the permissions required to delete an Amazon S3 bucket that was created during the failed update. Which combination of actions will allow the administrator to successfully return the stack to a stable state? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Update the CloudFormation service role's IAM policy to grant the necessary permissions, or specify a different IAM role with sufficient permissions.; Execute the Continue Update Rollback operation from the AWS CloudFormation console or by using the AWS CLI.

Answer

Updating the CloudFormation service role's IAM policy or specifying a different role with sufficient permissions, and then executing the Continue Update Rollback operation from the console or CLI.
To recover from a stack in the UPDATE_ROLLBACK_FAILED state, the administrator must fix the underlying issue that blocked the rollback. In this case, updating the service role's policy or specifying a different role solves the permissions issue. Then, triggering the Continue Update Rollback operation tells CloudFormation to retry the rollback.

Step-by-Step Solution

1
Analyze the stack events to identify the resource causing the rollback failure and the reason for the failure.
The S3 bucket deletion fails due to insufficient permissions in the service role.
Before remediating, the exact cause of the UPDATE_ROLLBACK_FAILED state must be determined.
2
Update the CloudFormation service role's policy to add the missing permissions, or prepare a different service role that has these permissions.
CloudFormation now has the necessary authority to delete the S3 bucket during rollback.
CloudFormation needs valid API permissions to perform delete operations on resources in the stack.
3
Trigger the Continue Update Rollback action via the console or run the `aws cloudformation continue-update-rollback` command.
The stack successfully continues rolling back and reaches the UPDATE_ROLLBACK_COMPLETE state.
This operation commands CloudFormation to retry the rollback process using the updated permissions.

Key Concept

AWS CloudFormation Stack and Drift Management
Estimated Time:1m 30s
Question 528Question

An organization manages its AWS accounts using AWS Organizations with all features enabled. A SysOps administrator in a member account is troubleshooting why an IAM user (`arn:aws:iam::111122223333:user/LogOperator`) cannot delete objects from an Amazon S3 bucket named `prod-log-bucket`, despite the user having an identity-based IAM policy that allows `s3:DeleteObject` and `s3:DeleteObjectVersion` on the bucket.

The administrator discovers that the management account has applied the following Service Control Policy (SCP) to the member account:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictDeletions",
"Effect": "Deny",
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion"
],
"Resource": "arn:aws:s3:::prod-log-bucket/*",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::111122223333:role/LogCleanupRole"
}
}
}
]
}

Why is the IAM user unable to delete objects from the S3 bucket?

Show answer & explanation

Answer: The SCP contains an explicit Deny statement that applies to all principals in the member account except the specified LogCleanupRole, which overrides the IAM user's Allow permission.

Answer

The Service Control Policy (SCP) contains an explicit Deny statement that applies to all principals in the member account except the specified LogCleanupRole, which overrides the IAM user's Allow permission.
The correct answer explains that the SCP contains an explicit Deny statement that applies to all principals except the LogCleanupRole. Since the user LogOperator is not the LogCleanupRole, the explicit Deny is triggered. In AWS policy evaluation, an explicit Deny in an SCP overrides any local identity-based Allow statements, resulting in an Access Denied error.

Step-by-Step Solution

1
Evaluate the evaluation logic of AWS policies.
By default, all requests are denied. An explicit deny in any policy (including SCPs) overrides any explicit allows.
Understanding the policy evaluation hierarchy is critical for troubleshooting access issues in multi-account environments.
2
Analyze the Service Control Policy (SCP) applied to the member account.
The SCP explicitly denies the s3:DeleteObject and s3:DeleteObjectVersion actions on the specified S3 bucket resource if the calling principal is NOT the LogCleanupRole role.
Identifying the target resource, actions, and condition criteria determines who is affected by the policy restriction.
3
Compare the calling principal's ARN with the condition pattern.
The calling principal is the IAM user LogOperator. This does not match the LogCleanupRole ARN, meaning the condition is satisfied and the explicit Deny is applied.
Evaluating the ArnNotEquals operator determines if the calling principal falls under the scope of the Deny statement.

Key Concept

AWS Organizations Service Control Policies (SCPs) act as permission guards that specify the maximum permissions for an account. An explicit Deny statement in an SCP overrides any local IAM policy Allow statements, preventing even administrative users or specific IAM users from executing restricted actions if they do not meet the condition criteria.
Question 529Question

A SysOps administrator configures a new gateway VPC endpoint for Amazon S3 to enable private access for Amazon EC2 instances in a private subnet. After deploying the endpoint, the administrator notices that the EC2 instances are still routing their traffic to Amazon S3 through an existing NAT gateway. Which of the following is the most likely cause of this behavior?

Show answer & explanation

Answer: The route table associated with the private subnet was not selected during the gateway endpoint creation.

Answer

The route table associated with the private subnet was not selected during the gateway endpoint creation.
A gateway VPC endpoint works by automatically adding a route to the associated route tables that directs traffic destined for Amazon S3 (using its prefix list) to the endpoint. If the administrator does not select the private subnet's route table during creation, the route table will not contain the prefix list entry, and traffic to S3 will continue to match the default route (0.0.0.0/0) pointing to the NAT gateway.

Step-by-Step Solution

1
Analyze how gateway VPC endpoints direct traffic.
Gateway endpoints work by adding a route to the specified route tables targeting the AWS service prefix list (e.g., pl-xxxxxx) with the gateway endpoint ID (vpce-xxxxxx) as the target.
This direct route is necessary to override the default 0.0.0.0/0 route pointing to the NAT gateway.
2
Determine why the traffic continues to route to the NAT gateway.
If the private subnet's route table was not selected (associated) during the creation of the gateway endpoint, the S3 prefix list route will not be added to that route table.
Without the specific prefix list route in the table, traffic to S3 will fall back to the default route (0.0.0.0/0) which points to the NAT gateway.

Key Concept

Gateway VPC endpoints require explicit route table association to add prefix list routing.
Question 530Question

A SysOps administrator is troubleshooting connectivity for an application hosted on Amazon EC2 instances in a private subnet (Subnet-ASubnet\text{-}A, CIDR 10.0.1.0/2410.0.1.0/24). The instances need to download packages from the internet and upload large files to an Amazon S3 bucket in the same Region. Currently, the route table for Subnet-ASubnet\text{-}A has a route for 0.0.0.0/00.0.0.0/0 pointing to a NAT Gateway in a public subnet. S3 upload traffic is currently routed through the NAT Gateway, incurring high data processing charges. To eliminate these charges, the administrator creates a Gateway VPC endpoint for Amazon S3 but notices that S3 traffic continues to flow through the NAT Gateway. Additionally, a new security policy is applied to the VPC, and the administrator configures a custom network ACL (NACL) for Subnet-ASubnet\text{-}A that allows outbound TCP traffic to ports 8080 and 443443 and inbound TCP traffic on port 2222 for management. Immediately after applying the NACL, the EC2 instances lose all connectivity to both the internet and S3. Which combination of actions will resolve both the routing issue to S3 and the package download issue?

Show answer & explanation

Answer: Associate the S3 Gateway VPC endpoint with the route table of Subnet-ASubnet\text{-}A, and add an inbound rule to the custom NACL allowing TCP traffic from source ports 8080 and 443443 to destination ports 1024-655351024\text{-}65535.

Answer

Associate the S3 Gateway VPC endpoint with the route table of the private subnet, and add an inbound rule to the custom network ACL allowing TCP traffic from source ports 80 and 443 to destination ports 1024-65535.
The correct action is to associate the S3 Gateway VPC endpoint with the route table of the private subnet and add an inbound rule to the custom network ACL allowing TCP traffic from source ports 80 and 443 to destination ports 1024-65535. Associating the Gateway endpoint dynamically inserts the S3 prefix list route into the route table, routing S3 traffic privately and avoiding NAT Gateway charges. Because network ACLs are stateless, return packets from outbound HTTP/HTTPS and S3 requests will target the client's ephemeral ports (1024-65535) from source ports 80 and 443; hence, they must be allowed explicitly.

Step-by-Step Solution

1
Analyze the S3 routing issue.
Creating a Gateway VPC endpoint does not automatically redirect traffic unless the endpoint is associated with the subnet's route table. If not associated, traffic destined for S3 will match the default route (0.0.0.0/00.0.0.0/0) pointing to the NAT Gateway, incurring data processing charges.
VPC route tables must contain the specific prefix list route for S3 pointing to the Gateway endpoint (vpce-xxxxxxvpce\text{-}xxxxxx) to bypass the NAT Gateway.
2
Analyze the network ACL stateless behavior.
Network ACLs are stateless, meaning return traffic must be explicitly allowed. When the instances initiate outbound requests to download packages (ports 8080 and 443443) or connect to S3, the response traffic from the external servers returns to the instances' ephemeral source ports (1024-655351024\text{-}65535).
Without an inbound rule allowing response traffic on ephemeral ports, the return packets are dropped, breaking all outward-initiated connections.
3
Synthesize the resolution steps.
To route S3 traffic privately, associate the S3 Gateway endpoint with the route table of Subnet-ASubnet\text{-}A. To fix the stateless NACL block, add an inbound rule allowing TCP traffic from source ports 8080 and 443443 to destination ports 1024-655351024\text{-}65535.
These combined actions resolve both the route table configuration issue and the return-traffic NACL block.

Key Concept

Troubleshooting Gateway VPC endpoints and stateless network ACL ephemeral port return traffic rules.
Estimated Time:3m 0s
Question 531Question

A SysOps Administrator is setting up an organization-wide AWS CloudTrail trail in Account A (111122223333111122223333). The trail is configured to deliver log files to an Amazon S3 bucket located in Account B (444455556666444455556666). The administrator wants to encrypt these log files using a customer managed KMS key that is also located in Account B. The S3 bucket policy in Account B has already been configured to allow the `cloudtrail.amazonaws.com` service principal to write logs. However, when the administrator enables KMS encryption on the trail using the KMS key from Account B, CloudTrail log delivery fails.

Which configuration change must the administrator make to resolve this delivery issue?

Show answer & explanation

Answer: Modify the KMS key policy in Account B to allow the `cloudtrail.amazonaws.com` service principal to perform `kms:GenerateDataKey*` and `kms:DescribeKey` actions, with a condition matching the trail ARN from Account A in the `kms:EncryptionContext:aws:cloudtrail:arn` key.

Answer

Modify the KMS key policy in Account B to allow the `cloudtrail.amazonaws.com` service principal to perform `kms:GenerateDataKey*` and `kms:DescribeKey` actions, with a condition matching the trail ARN from Account A in the `kms:EncryptionContext:aws:cloudtrail:arn` key.
To allow AWS CloudTrail (a service running on behalf of Account A) to encrypt log files using a KMS key in Account B, the KMS key policy in Account B must explicitly permit the `cloudtrail.amazonaws.com` service principal to use the key. Specifically, CloudTrail requires the `kms:GenerateDataKey*` action to generate data keys for encrypting the log objects, and `kms:DescribeKey` to check key properties. Additionally, using the `kms:EncryptionContext:aws:cloudtrail:arn` condition key restricts key usage to the specific trail in Account A, ensuring proper security boundaries.

Step-by-Step Solution

1
Analyze the log delivery path and identify why CloudTrail cannot deliver logs.
CloudTrail in Account A must write encrypted logs to Account B. Since encryption is enabled with a customer managed key in Account B, the CloudTrail service principal requires access to that KMS key to generate data keys.
Without key access, CloudTrail cannot encrypt the logs, resulting in failed log delivery.
2
Determine where the KMS permissions must be configured.
Because the KMS key is in Account B and the service runs on behalf of a resource in Account A, the KMS key policy in Account B must be updated to grant permissions directly to the `cloudtrail.amazonaws.com` service principal.
KMS key policies are the primary authorizers for KMS key usage; IAM policies in an external account cannot grant access to a KMS key without the key policy itself permitting it.
3
Verify the required KMS policy actions and conditions.
The key policy must allow `kms:GenerateDataKey*` and `kms:DescribeKey` actions to the service principal, and restrict usage to the specific trail using the `kms:EncryptionContext:aws:cloudtrail:arn` condition key.
CloudTrail requires these specific actions to perform envelope encryption on the log files before writing them, and the condition prevents unauthorized accounts or trails from using the key.

Key Concept

Cross-account AWS Service access to KMS CMKs requires explicit configuration of the KMS key policy to permit the service principal, constrained by specific encryption contexts.
Question 532Question

A SysOps Administrator is troubleshooting network connectivity between two private subnets in a VPC. Application servers are located in Subnet A (172.16.1.0/24172.16.1.0/24) and need to perform secure directory lookups on an LDAP server located in Subnet B (172.16.2.0/24172.16.2.0/24) over TCP port 636636.

Both subnets are associated with custom Network Access Control Lists (NACLs). The security groups associated with the application servers and the LDAP server are already configured to allow the required traffic. However, the directory lookups are currently failing.

Which two changes should the SysOps Administrator make to the NACLs to resolve this issue? (Select two.)

Select all that apply

Show answer & explanation

Answer: In the Subnet A NACL, add an inbound rule that allows TCP traffic from Subnet B (172.16.2.0/24172.16.2.0/24) on destination ports 1024655351024-65535.; In the Subnet B NACL, add an outbound rule that allows TCP traffic to Subnet A (172.16.1.0/24172.16.1.0/24) on destination ports 1024655351024-65535.

Answer

In the Subnet A NACL, add an inbound rule that allows TCP traffic from Subnet B on destination ports 1024655351024-65535, and in the Subnet B NACL, add an outbound rule that allows TCP traffic to Subnet A on destination ports 1024655351024-65535.
Because Network Access Control Lists (NACLs) are stateless, separate rules must be defined for request and response traffic. When a client in Subnet A initiates an LDAP request to Subnet B on TCP port 636636, the client uses a random port in the ephemeral range (1024655351024-65535) as its source port. The LDAP server's response will therefore be sent from source port 636636 to destination ports 1024655351024-65535. To allow this return traffic, the Subnet B NACL must have an outbound rule allowing TCP traffic to the Subnet A CIDR range on destination ports 1024655351024-65535, and the Subnet A NACL must have an inbound rule allowing TCP traffic from the Subnet B CIDR range on destination ports 1024655351024-65535.

Step-by-Step Solution

1
Analyze the flow of LDAP traffic and the stateless nature of NACLs.
Identify that the LDAP query request flows from Subnet A to Subnet B on destination TCP port 636636. The response flows from Subnet B back to Subnet A on destination ephemeral ports (1024655351024-65535). Since NACLs are stateless, rules for both the request and response traffic must be explicitly allowed.
To determine which network paths and ports are currently blocked by the stateless custom NACLs.
2
Identify the required return path rules in both NACLs.
The response traffic leaving Subnet B needs an outbound rule in Subnet B's NACL targeting Subnet A's CIDR (172.16.1.0/24172.16.1.0/24) on destination ports 1024655351024-65535. The response traffic entering Subnet A needs an inbound rule in Subnet A's NACL allowing source IP range Subnet B (172.16.2.0/24172.16.2.0/24) on destination ports 1024655351024-65535.
To specify the correct stateless rules that must be added to the NACLs.
3
Evaluate the stateful behavior of security groups in the context of this scenario.
Verify that since security groups are stateful, no additional outbound rule is needed on the LDAP server's security group, as the return response is tracked and allowed automatically.
To confirm that security group modifications are not needed and to rule out security group-based distractors.

Key Concept

Because Network Access Control Lists (NACLs) are stateless, return traffic to client ephemeral ports (1024655351024-65535) must be explicitly permitted in both inbound and outbound rules.
Estimated Time:1m 30s
Question 533Question

An organization uses an AWS Transit Gateway to connect its VPC (10.100.0.0/1610.100.0.0/16) to an on-premises network (192.168.10.0/24192.168.10.0/24) over an AWS Site-to-Site VPN. An application server running on an Amazon EC2 instance (10.100.1.5510.100.1.55) in a private subnet (10.100.1.0/2410.100.1.0/24) must connect to an on-premises database (192.168.10.200192.168.10.200) on TCP port 33063306.

The EC2 instance's security group allows all outbound traffic to 0.0.0.0/00.0.0.0/0 and has no inbound rules. The private subnet's route table has a default route (0.0.0.0/00.0.0.0/0) targeting a NAT Gateway, and a local route for 10.100.0.0/1610.100.0.0/16. The private subnet's Network Access Control List (NACL) allows outbound traffic to 0.0.0.0/00.0.0.0/0 on all ports, but the inbound NACL only allows traffic from the local VPC range (10.100.0.0/1610.100.0.0/16).

The EC2 instance cannot establish a connection to the on-premises database.

Which combination of actions must a SysOps administrator take to resolve this connectivity issue? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a route for 192.168.10.0/24192.168.10.0/24 in the private subnet's route table with the Transit Gateway as the target.; Add an inbound rule to the private subnet's NACL that allows traffic from 192.168.10.0/24192.168.10.0/24 on ephemeral ports (1024655351024-65535).

Answer

To resolve the connectivity issue, the administrator must add a route for the on-premises network (192.168.10.0/24192.168.10.0/24) targeting the Transit Gateway in the private subnet's route table, and add an inbound rule to the private subnet's NACL to allow return traffic from the on-premises network (192.168.10.0/24192.168.10.0/24) on ephemeral ports (1024655351024-65535).
To resolve the connectivity issue, two changes are required. First, a route for the on-premises network range (192.168.10.0/24192.168.10.0/24) must be added to the private subnet's route table pointing to the Transit Gateway. This ensures that outbound packets destined for the database are routed to the Transit Gateway instead of matching the default route to the NAT Gateway. Second, since Network Access Control Lists (NACLs) are stateless, an inbound rule must be added to the private subnet's NACL to allow traffic from the on-premises database subnet (192.168.10.0/24192.168.10.0/24) on ephemeral ports (1024655351024-65535). This allows the return packets of the TCP connection back to the client.

Step-by-Step Solution

1
Analyze the routing configuration of the private subnet.
The current route table only contains a local route and a default route targeting a NAT Gateway. Packets destined for the database IP (192.168.10.200192.168.10.200) will match the default route (0.0.0.0/00.0.0.0/0) and be sent to the NAT Gateway rather than the Transit Gateway.
To identify why the database traffic is not reaching the Transit Gateway VPN attachment.
2
Add a specific route to the private subnet's route table.
A route for 192.168.10.0/24192.168.10.0/24 pointing to the Transit Gateway is added, directing database traffic correctly.
To override the default route for the on-premises destination and send it to the Transit Gateway.
3
Analyze the private subnet's stateless NACL rules.
The inbound NACL only allows traffic from the local VPC (10.100.0.0/1610.100.0.0/16), meaning return traffic from the database (192.168.10.0/24192.168.10.0/24) will be blocked.
To determine why return packets are being dropped at the VPC boundary despite the security group being stateful.
4
Add an inbound rule to the NACL allowing ephemeral ports.
An inbound rule is added to allow traffic from 192.168.10.0/24192.168.10.0/24 on ports 1024655351024-65535.
Because NACLs are stateless, return packets destined for the EC2 instance's dynamic client ports must be explicitly allowed.

Key Concept

Troubleshooting routing tables and stateless NACL ephemeral ports in hybrid networking scenarios.
Question 534Question

An enterprise uses AWS Systems Manager State Manager to enforce security configurations across all EC2 instances. Every instance has the SSM Agent running and is assigned an IAM instance profile with the `AmazonSSMManagedInstanceCore` policy. To automate compliance checks, a SysOps administrator is configuring a State Manager association that will execute a custom SSM document using a service role. When creating the association, the administrator receives an 'Access Denied' error. Which of the following IAM configurations is required to successfully create this association?

Show answer & explanation

Answer: Attach an IAM policy to the administrator's IAM user that grants the `iam:PassRole` action for the Systems Manager service role.

Answer

Attach an IAM policy to the administrator's IAM user that grants the `iam:PassRole` action for the Systems Manager service role.
To create a Systems Manager State Manager association that uses a service role to run commands or automation on instances, the IAM user configuring the association must have the `iam:PassRole` permission for that service role. This ensures that the administrator is authorized to assign the service role to Systems Manager.

Step-by-Step Solution

1
Analyze the error message and context.
The administrator receives an 'Access Denied' error when creating a State Manager association that uses a service role.
This indicates that the administrator's identity lacks the permission required to associate the service role with the Systems Manager resource.
2
Determine the required IAM permission for passing a role to an AWS service.
The identity configuring the resource must have the `iam:PassRole` permission.
AWS prevents unauthorized users from assigning high-privileged roles to services by requiring the explicit `iam:PassRole` permission.
3
Identify the correct option that addresses the user policy requirement.
Grants the `iam:PassRole` permission to the administrator's IAM identity.
This allows the administrator to pass the Systems Manager service role to State Manager.

Key Concept

IAM PassRole permissions for AWS Systems Manager configurations
Question 535Question

A company hosts a high-traffic API on a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB). The ALB is integrated with an AWS WAF Web ACL that logs all web requests to an Amazon CloudWatch Logs log group. Due to the high volume of traffic, the CloudWatch Logs ingestion and storage costs have exceeded the budget. The security team requires that only requests that are explicitly blocked by the Web ACL be retained for analysis. Which action should the SysOps administrator take to meet these requirements with the least operational effort?

Show answer & explanation

Answer: Configure a logging filter in the AWS WAF logging configuration. Define a filter rule that matches the BLOCK action to keep the logs, and set the default behavior to drop logs for all other requests.

Answer

Configure a logging filter in the AWS WAF logging configuration. Define a filter rule that matches the BLOCK action to keep the logs, and set the default behavior to drop logs for all other requests.
Configuring a logging filter directly in AWS WAF allows filtering out requests before they are sent to CloudWatch Logs. By matching the BLOCK action and keeping only those logs while dropping all others, ingestion and storage costs are minimized while satisfying the security requirement.

Step-by-Step Solution

1
Identify the target for cost optimization, which is reducing the volume of AWS WAF logs ingested by CloudWatch Logs.
Determined that allowed web requests contribute to the majority of log volume and should be excluded at the source.
Ingestion costs in CloudWatch Logs are charged per gigabyte, meaning filtering must occur prior to log delivery.
2
Evaluate native filtering capabilities within the AWS WAF logging configuration.
Selected AWS WAF logging filters to filter requests based on rule action parameters.
AWS WAF supports native log filtering, which incurs no additional processing layer or external utility costs.
3
Configure the logging filter to match the security team's specification.
Created a filter rule matching the BLOCK action set to KEEP, and configured the default behavior to DROP.
This configuration ensures only blocked requests are sent to the CloudWatch Logs log group, lowering ingestion and storage costs.

Key Concept

AWS WAF Log Filtering
Question 536Question

A SysOps Administrator in Account 111111111111111111111111 is troubleshooting a decryption error. An application running on an Amazon EC2 instance with the IAM role `AppExecutionRole` attached is attempting to decrypt a configuration file using a Customer Managed Key (CMK). The IAM policy attached to `AppExecutionRole` contains the following statement:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowKmsDecrypt",
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "arn:aws:kms:us-east-1:111111111111:key/12345678-1234-1234-1234-123456789012"
}
]
}

However, the application receives a `KMS.AccessDeniedException` when calling the `Decrypt` API. The Administrator reviews the current KMS key policy for the CMK:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowKeyAdmins",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/KmsAdminRole"
},
"Action": [
"kms:Create*",
"kms:Describe*",
"kms:Enable*",
"kms:List*",
"kms:Put*",
"kms:Update*",
"kms:Revoke*",
"kms:Disable*",
"kms:Get*",
"kms:Delete*",
"kms:ScheduleKeyDeletion",
"kms:CancelKeyDeletion"
],
"Resource": "*"
}
]
}

Which changes will resolve the decryption error? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Add a statement to the KMS key policy that grants the root account principal (`arn:aws:iam::111111111111:root`) permissions for `kms:*` to enable IAM policy delegation.; Add a statement to the KMS key policy that explicitly grants the `AppExecutionRole` principal (`arn:aws:iam::111111111111:role/AppExecutionRole`) permission to perform the `kms:Decrypt` action.

Answer

To resolve the decryption error, you must either add a statement to the KMS key policy that grants the root account principal (`arn:aws:iam::111111111111:root`) permissions for `kms:*` to enable IAM policy delegation, or add a statement to the KMS key policy that explicitly grants the `AppExecutionRole` principal (`arn:aws:iam::111111111111:role/AppExecutionRole`) permission to perform the `kms:Decrypt` action.
The KMS key policy is the primary authorization mechanism for KMS keys. To allow an IAM policy to grant access to a KMS key, the key policy must delegate that authority to the account. This is accomplished by adding a statement to the key policy that grants the account root principal (`arn:aws:iam::111111111111:root`) permissions to perform KMS actions (typically `kms:*`). Alternatively, the KMS key policy can directly grant permissions to the specific IAM principal (`arn:aws:iam::111111111111:role/AppExecutionRole`) for the `kms:Decrypt` action, bypassing the need for delegation.

Step-by-Step Solution

1
Analyze the IAM policy attached to the role to verify that the `kms:Decrypt` action is allowed on the correct KMS key ARN.
The IAM policy correctly specifies the `kms:Decrypt` action and targets the correct KMS key ARN.
This determines if the application's identity has been granted the necessary local permissions.
2
Examine the KMS key policy to check if access control is delegated to IAM policies or if the role has direct permissions.
The key policy only contains an administrative statement for `KmsAdminRole` and does not reference the root account principal (`arn:aws:iam::111111111111:root`) or the role principal directly.
KMS key policies are the primary authorization mechanism. Without a statement delegating control to the root account principal or directly listing the role, IAM policies targeting the key have no effect.
3
Identify the required changes to the KMS key policy to permit authorization.
Either add a statement delegating permissions to the root account principal so the existing IAM policy takes effect, or add a statement directly granting `kms:Decrypt` to the execution role in the key policy.
This establishes the missing trust and authorization chain in KMS for the decrypt operation.

Key Concept

KMS key policy precedence and IAM delegation
Estimated Time:2m 30s
Question 537Question

An application running on an Amazon EC2 instance in Account A (111122223333) uses an IAM role named AppReaderRole. The application needs to read and decrypt files stored in an Amazon S3 bucket in Account B (444455556666). The S3 bucket is configured with server-side encryption using a customer managed key (CMK) in Account B. The AppReaderRole in Account A has been granted s3:GetObject on the S3 bucket and kms:Decrypt on the CMK via its local IAM policy. The S3 bucket policy in Account B allows s3:GetObject to the AppReaderRole. However, when the application attempts to download an encrypted file, it receives an AccessDenied error from KMS. The KMS key policy in Account B contains only the default statement that allows all actions to Account B's root principal. Which action should the SysOps Administrator take to resolve this issue?

Show answer & explanation

Answer: Modify the KMS key policy in Account B to allow the AppReaderRole in Account A (or the Account A root principal) to perform the kms:Decrypt action.

Answer

Modify the KMS key policy in Account B to allow the AppReaderRole in Account A (or the Account A root principal) to perform the kms:Decrypt action.
For cross-account access to resources encrypted with a Customer Managed KMS key (CMK), the key policy in the owning account must explicitly grant permission to the external account (either the external root account to delegate via IAM, or directly to the external IAM role). Additionally, the IAM policy in the consuming account must also allow the action. Since the IAM role in Account A already has the necessary IAM permissions, modifying the KMS key policy in Account B to trust the role or Account A's root will complete the trust path and resolve the AccessDenied error.

Step-by-Step Solution

1
Identify that the resource is encrypted using a Customer Managed KMS key in a different account (Account B).
Realize that standard cross-account IAM delegation rules apply to the KMS key.
To decrypt the object, both Account A's IAM policy and Account B's KMS key policy must permit the operation.
2
Examine the KMS key policy in Account B.
Determine that it only permits access to local root/IAM users in Account B.
Since KMS key policies do not automatically trust external accounts, Account B's key policy is currently blocking Account A's AppReaderRole.
3
Modify the KMS key policy in Account B to grant access to the external identity.
Add a statement allowing Account A's root principal (allowing Account A's IAM to delegate) or directly allowing the AppReaderRole ARN.
This establishes the necessary trust relationship to permit the cross-account decryption request.

Key Concept

Cross-account KMS key access delegation using KMS key policies and IAM policies.
Question 538Question

An application tier deployed on Amazon EC2 instances in Subnet App (10.120.10.0/2410.120.10.0/24) must connect to a MongoDB database cluster running on EC2 instances in Subnet DB (10.120.20.0/2410.120.20.0/24) on TCP port 2701727017. Both subnets are associated with custom Network Access Control Lists (NACLs) that currently deny all traffic by default. The associated Security Groups are already configured to allow all required database traffic.

Which two NACL rules must be added to the Subnet DB NACL to successfully allow this database communication? (Select two.)

Select all that apply

Show answer & explanation

Answer: An inbound rule that allows TCP traffic on port 2701727017 from source CIDR 10.120.10.0/2410.120.10.0/24.; An outbound rule that allows TCP traffic on ports 10241024-6553565535 to destination CIDR 10.120.10.0/2410.120.10.0/24.

Answer

To allow the connection, the database subnet's NACL needs an inbound rule allowing TCP traffic on port 27017 from the application subnet, and an outbound rule allowing response traffic on ephemeral ports 1024-65535 back to the application subnet.
The correct configurations are the inbound rule to allow traffic on the database listening port and the outbound rule to allow return traffic on ephemeral ports. Since NACLs are stateless, they require separate rules for both directions. The inbound rule allows the connection request to reach the database, and the outbound rule allows the response to return to the client's ephemeral port range.

Step-by-Step Solution

1
Identify the stateless behavior of NACLs.
Recognize that rules must be configured for both request (inbound) and response (outbound) paths on the Subnet DB NACL, regardless of the Security Group configuration.
Unlike stateful security groups, NACLs do not track connection state and require explicit rules for return traffic.
2
Configure the inbound rule to allow the database request.
Allow TCP port 27017 from the source application subnet CIDR of 10.120.10.0/2410.120.10.0/24.
This allows the application instances to initiate connection handshakes to the MongoDB service running in the database subnet.
3
Configure the outbound rule to allow the response path.
Allow TCP ports 1024-65535 to the destination application subnet CIDR of 10.120.10.0/2410.120.10.0/24.
Connection responses from the database server must reach the application instances on the client's ephemeral port range (1024-65535).

Key Concept

Stateless nature of Network Access Control Lists (NACLs) and ephemeral port requirements.
Question 539Question

A SysOps Administrator uses an AWS CloudFormation stack to manage an Amazon S3 bucket used for public asset hosting. A developer manually modified the bucket's CORS (Cross-Origin Resource Sharing) configuration directly in the Amazon S3 console to enable access for a new partner domain. The administrator runs drift detection on the stack and identifies that the S3 bucket is in a drifted state. The administrator wants to resolve the drift and align the stack and the S3 bucket configuration.

Which of the following actions can the administrator take to remediate the drift? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Manually revert the CORS configuration on the S3 bucket to match the configuration specified in the CloudFormation template.; Update the CloudFormation template to include the new CORS configuration, and then perform a stack update using the updated template.

Answer

The administrator can resolve the drift by manually reverting the S3 bucket's CORS configuration to match the template, or by updating the template to include the new CORS configuration and running a stack update.
The correct remediation steps are to either manually revert the CORS configuration on the S3 bucket to match the template definition, or to update the template to reflect the manual changes and run a stack update. These are the two standard ways to align drifted resources with the stack configuration in CloudFormation.

Step-by-Step Solution

1
Analyze the drift detection report to identify which resource and properties have drifted.
The S3 bucket CORS configuration is identified as drifted.
Before remediating, you must know what configuration values differ from the template.
2
Evaluate the desired state of the resource (whether the manual changes should be kept or discarded).
Determine if the developer's changes are valid and should be codified, or if they should be undone.
If the developer's changes are temporary or incorrect, they should be undone. If they are permanent, they must be incorporated into the stack template.
3
Execute the appropriate remediation method.
Either manually revert the S3 bucket's CORS configuration to match the template, or update the template to match the configuration and perform a stack update.
These are the two officially supported ways to resolve CloudFormation drift.

Key Concept

CloudFormation Drift Remediation
Estimated Time:1m 30s
Question 540Question

A SysOps Administrator is configuring automated remediation for non-compliant resources detected by AWS Config. The administrator is using an AWS Systems Manager (SSM) Automation document to remediate non-compliant Amazon S3 buckets. The administrator creates an IAM role named `S3RemediationRole` with the required permissions to modify bucket configurations. When configuring the remediation action in AWS Config, the administrator specifies the Amazon Resource Name (ARN) of `S3RemediationRole` as the `AutomationAssumeRole` parameter. However, when the remediation is triggered, the execution fails to start and indicates that the role cannot be assumed. Which action must the administrator take to resolve this issue?

Show answer & explanation

Answer: Modify the trust policy of `S3RemediationRole` to allow the `ssm.amazonaws.com` service principal to assume the role.

Answer

Modify the trust policy of `S3RemediationRole` to allow the `ssm.amazonaws.com` service principal to assume the role.
AWS Config automated remediation executes remediations by calling AWS Systems Manager Automation. The IAM role specified as `AutomationAssumeRole` is assumed by the Systems Manager Automation service. Therefore, the trust policy of `S3RemediationRole` must list `ssm.amazonaws.com` as a trusted entity and allow the `sts:AssumeRole` action. Without this permission, Systems Manager cannot assume the role, and the remediation task fails to initialize.

Step-by-Step Solution

1
Identify the service executing the automated remediation document.
AWS Config delegates the execution of remediation actions to AWS Systems Manager Automation.
Understanding which service performs the action is critical to determining which service principal needs assume role permissions.
2
Determine the required service principal for the trust relationship.
The Systems Manager service principal (`ssm.amazonaws.com`) must assume `S3RemediationRole` to execute the remediation actions.
Since Systems Manager Automation is the caller, it must be the trusted entity in the IAM role's trust policy.
3
Update the trust policy of the IAM role.
The trust policy of `S3RemediationRole` is updated to allow `sts:AssumeRole` for the `ssm.amazonaws.com` service principal.
This allows the remediation execution to start successfully without encountering authentication or assume role errors.

Key Concept

AWS Config automated remediation utilizes Systems Manager Automation documents, meaning the specified execution role must trust the Systems Manager service principal (`ssm.amazonaws.com`), not AWS Config.
Estimated Time:2m 0s
PreviousPage 27 / 49Next
All practice questions — AWS Certified SysOps Administrator - Associate | Examkin