Question

Difficulty: HardAWS Systems Manager Configuration and Run Command Automation

A SysOps Administrator is setting up an AWS Systems Manager Automation workflow to execute a maintenance script on a fleet of Amazon EC2 instances. The SSM Agent is running on all target instances, and each instance has an IAM instance profile attached with the AmazonSSMManagedInstanceCore policy. The administrator creates a service role named SSMAutomationExecutionRole for Systems Manager to execute the workflow.

When the administrator attempts to start the Automation workflow specifying this service role, the execution fails to start with an access denied error. Additionally, the administrator notices that several EC2 instances tagged with 'role: webserver' are not receiving the maintenance script, while others tagged with 'Role: WebServer' are successfully targeted.

Which combination of actions will resolve these issues? (Select TWO.)

  1. Add a policy to the administrator's IAM user or group that allows the iam:PassRole action on the SSMAutomationExecutionRole resource.Answer
  2. Update the Automation document target parameters to ensure the tag key and value match the exact case of the tags on all target EC2 instances.Answer
  3. C
    Add the sts:AssumeRole permission for the SSMAutomationExecutionRole to the EC2 instance profile's IAM role.
  4. D
    Configure the target tag filter in Systems Manager to use a wildcard pattern such as role:*webserver to enable case-insensitive matching.
  5. E
    Modify the EC2 instances' security groups to allow inbound SSH traffic (port 22) from the Systems Manager service endpoint CIDR blocks.

Answer

Add a policy to the administrator's IAM user or group that allows the iam:PassRole action on the SSMAutomationExecutionRole resource, and update the Automation document target parameters to ensure the tag key and value match the exact case of the tags on all target EC2 instances.
To resolve the access denied error when starting the Automation workflow, the administrator's IAM identity must have permission to pass the service role (SSMAutomationExecutionRole) to Systems Manager, which is achieved by granting iam:PassRole. Additionally, because Systems Manager targeting tag keys and values are strictly case-sensitive, the tag keys and values in the Automation document targets must match the exact case of the tags on the EC2 instances.

Step-by-Step Solution

1
Analyze the access denied error during Automation startup.
Identify that the administrator lacks permission to delegate the service role to Systems Manager.
Systems Manager requires the user initiating the execution to possess iam:PassRole permissions for the service role being passed.
2
Analyze the targeting failure where some instances are skipped.
Observe the mismatch in case between the tags 'role: webserver' and 'Role: WebServer'.
AWS Systems Manager targeting filters are case-sensitive, meaning different case variations of the same words are evaluated as completely distinct tags.
3
Apply the IAM policy change and tag alignment actions.
The Automation workflow successfully starts using the SSMAutomationExecutionRole, and all target EC2 instances are matched correctly.
Resolving the case sensitivity mismatch and granting iam:PassRole access eliminates both root causes.

Key Concept

AWS Systems Manager Automation permissions and case-sensitive resource targeting
Rate this question