Automatically trigger Relay
Final part of the exercise is observing Relay respond to events sent to it by Puppet Enterprise.
Switch to Relay to observe workflow trigger
- Click on name of previously imported workflow
- May currently be labled as RUNNING

Examine steps to see where workflow exits
- Each time Puppet runs, it sends those previously observed events to the PE server, which forwards them off to any number of configured endpoints for additional processing and storage
- Some instances of the workflow have probably already ran, the PE server is also managed by Puppet and been forwarding events
- Click into the most recent run
- Workflow will exit success but report a number of steps skipped

Verify that no corrective changes were detected by examining step logs
- Click on View logs of the detect-changes step

Make a change to the EC2 instance’s sudo configuration out of band of Puppet
- Removing a file within the
/etc/sudoers.d
directory is sufficient
sudo -i rm /etc/sudoers.d/10_puppetadmin

Re-run Puppet to trigger a corrective change
sudo -i puppet agent -t
- Output will again report events related to Sudo::Conf but this time you can see that they are tagged corrective

Return to Relay again to witness the post corrective change workflow run
- Another instance of the workflow should now be running

Approve instance shutdown action
- Having detected corrective changes, the workflow will eventually pause at step Approval required
- This approval could be replaced with another mechanism or augmented by a chatops step to prevent having to check in on these runs periodically
- Click on Approve

Once complete, verify which instance ID was shutdown by Relay
- When the ec2-stop-instances step in complete, open its logs to see the ID of the instance it stopped

Once shutdown, your SSH connection will also be terminated
- When you return to your EC2 instance’s SSH connection, it’ll also now be terminated
