A hospital alarm invokes a Lambda function that is supposed to restart a stuck agent through Systems Manager. The function log shows it ran, and the instance never changes. The function role has no ssm:SendCommand permission. What should be granted?
Select an answer to reveal the explanation.
Short Explanation
The function got up and walked to the door, and the door would not open. You can see the run in the log, and Systems Manager rejected the command because the function's role cannot call ssm:SendCommand. Putting that permission on the instance profile points it at the wrong principal.
Full Explanation
The Lambda function assumes its execution role and, from that role, calls Systems Manager to run the restart document on the instance. Without ssm:SendCommand, and the related document and instance permissions that call requires, Systems Manager denies the command and the agent is never restarted. The instance profile is what the instance uses to call AWS. The instance is the target of the command, not the caller, so adding SendCommand there does not let the function send it. lambda:InvokeFunction allows something to start the function. The alarm is already invoking it, which the log proves, so that permission is not the gap. ec2:RebootInstances is an EC2 API. Granting it to the alarm does not add an SSM permission to the function role, and a reboot is a different remediation from restarting one agent. Caveat: scope the command permission to the restart document and the fleet's instance ARNs so the function cannot run arbitrary documents on arbitrary instances. Operational check: invoke the function once in a test account and confirm the Systems Manager command history shows Success for that instance.