Added screen shots to md files.

instructions/2-deploying-trustworthy-code.md

@@ -21,6 +21,8 @@ Throughout this project, you will be asked to take screenshots or provide URLs t
 
 The goal of a build phase is to compile or lint the source code to check for syntax errors or unintentional typos in code. It’s your first line of defense against bugs as you attempt to integrate the pieces of your project together. This is especially important to UdaPeople because we don’t want to waste credits or time running other steps if the code can’t even compile.
 
+![Job properly failing because of compile errors.](screenshots/SCREENSHOT01.png)
+
 - Add jobs to the `.circleci/config.yml` file to build/compile both front-end and back-end code (one job for each). 
 - You should have separate jobs for front-end and back-end so that failure alerts are more descriptive.
 - Job should fail if code cannot be compiled (fail for the right reasons). We have provided an easy-to-fix compile error in the code to prove the jobs fail. Provide a screenshot of jobs that failed because of compile errors. **[SCREENSHOT01]**
@@ -31,6 +33,8 @@ The goal of a build phase is to compile or lint the source code to check for syn
 
 Unit tests are one of the many very important building blocks of a system that enables Continuous Delivery (notice, we didn’t say “the only or most important thing”). UdaPeople believes that tests should come first just like they do in the scientific method. So, if a test fails, it's because the code is no longer trustworthy. Only trustworthy code should get a ticket to continue the ride!
 
+![Job properly failing because of test failures.](screenshots/SCREENSHOT02.png)
+
 - Add jobs to the config file to run all the unit tests in both layers. The command you use to run the tests should generate some sort of test results file in a standard format. You may need to check the test runner docs for this.
 - Again, this should be in separate jobs.
 - A unit test job should fail the job and prevent any future jobs from running.
@@ -42,6 +46,8 @@ Unit tests are one of the many very important building blocks of a system that e
 
 UdaPeople handles some private information like social security numbers, salary amount, etc. It would be a shame if a package with a known vulnerability left a security hole in our application, giving hackers access to that information! That’s why we should include a job that checks for known vulnerabilities every time we check in new code.
 
+![Job properly failing because of security vulnerabilities.](screenshots/SCREENSHOT03.png)
+
 - Add jobs to the config file to check for security vulnerabilities in the packages used in the application.
   - Create a simple job to run nodejs commands. The product `npm` comes with an “audit” feature that will check for known package vulnerabilities. Just `cd` into the directory of front-end and back-end and run the following:
 ```bash
@@ -58,6 +64,8 @@ npm audit fix --audit-level=critical --force
 
 When a build fails for any reason, the UdaPeople dev team needs to know about it. That way they can jump in and save the day (the day that they almost ruined by checking in bad code… but we digress). We’re going to add an alert so that botched builds raise a nice wavy red flag.
 
+![An alert when the build breaks.](screenshots/SCREENSHOT04.png)
+
 - Integrate Slack, email or another communication tool to receive alerts when jobs fail. 
 - Alerts should include a summary of what happened and a link to the job console output for quick troubleshooting.
 - Provide a screenshot of an alert from one of your failed builds. **[SCREENSHOT04]**

instructions/3-configuration-management.md

@@ -30,6 +30,8 @@
 
 Setting up servers and infrastructure is complicated business. There are many, many moving parts and points of failure. The opportunity for failure is massive when all that infrastructure is handled manually by human beings. Let’s face it. We’re pretty horrible at consistency. That’s why UdaPeople adopted the IaC (“Infrastructure as Code”) philosophy after “Developer Dave” got back from the last DevOps conference. We’ll need a job that executes some CloudFormation templates so that the UdaPeople team never has to worry about a missed deployment checklist item.
 
+![Job properly failing because of an error when creating infrastructure.](screenshots/SCREENSHOT05.png)
+
 - Add jobs to your config file to create your infrastructure using [CloudFormation templates](https://github.com/udacity/cdond-c3-projectstarter/tree/master/.circleci/files). Again, provide a screenshot demonstrating an appropriate job failure (failing for the right reasons). **[SCREENSHOT05]**
   - Use the pipeline/workflow id to name, tag or otherwise mark your CloudFormation stacks so that you can reference them later on (ex: rollback). If you'd like, you can use the parameterized CloudFormation templates we provided. 
   - New EC2 Instance for back-end.
@@ -73,6 +75,8 @@ Now that the infrastructure is up and running, it’s time to configure for depe
 
 All this automated deployment stuff is great, but what if there’s something we didn’t plan for that made it through to production? What if the UdaPeople website is now down due to a runtime bug that our unit tests didn’t catch? Users won’t be able to access their data! This same situation can happen with manual deployments, too. In a manual deployment situation, what’s the first thing you do after you finish deploying? You do a “smoke test” by going to the site and making sure you can still log in or navigate around. You might do a quick `curl` on the backend to make sure it is responding. In an automated scenario, you can do the same thing through code. Let’s add a job to provide the UdaPeople team with a little sanity check.
 
+![Job properly failing because of a failed smoke test.](screenshots/SCREENSHOT06.png)
+
 - Add a job to make a simple test on both front-end and back-end. Use the suggested tests below or come up with your own. 
   - Check `$API_URL/api/status` to make sure it returns a healthy response.
 ```bash
@@ -98,6 +102,8 @@ fi
 
 Of course, we all hope every pipeline follows the “happy path.” But any experienced UdaPeople developer knows that it’s not always the case. If the smoke test fails, what should we do? The smart thing would be to hit CTRL-Z and undo all our changes. But is it really that easy? It will be once you build the next job!
 
+![Successful rollback job.](screenshots/SCREENSHOT07.png)
+
 - Add a “[command](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-commands)” that rolls back the last change:
   - Only trigger rollback jobs if the smoke tests or any following jobs fail. 
   - Delete files uploaded to S3.
@@ -111,6 +117,8 @@ Of course, we all hope every pipeline follows the “happy path.” But any expe
 
 Assuming the smoke test came back clean, we should have a relatively high level of confidence that our deployment was a 99% success. Now’s time for the last 1%. UdaPeople uses the “Blue-Green Deployment Strategy” which means we deployed a second environment or stack next to our existing production stack. Now that we’re sure everything is "A-okay", we can switch from blue to green. 
 
+![Successful promotion job.](screenshots/SCREENSHOT08.png)
+
 - Add a job that promotes our new front-end to production
   - Use a [CloudFormation template](https://github.com/udacity/cdond-c3-projectstarter/tree/master/.circleci/files) to change the origin of your CloudFront distribution to the new S3 bucket ARN.
 - Provide a screenshot of the successful job. **[SCREENSHOT08]**
@@ -121,9 +129,13 @@ Assuming the smoke test came back clean, we should have a relatively high level
 
 The UdaPeople finance department likes it when your AWS bills are more or less the same as last month OR trending downward. But, what if all this “Blue-Green” is leaving behind a trail of dead-end production environments? That upward trend probably means no Christmas bonus for the dev team. Let’s make sure everyone at UdaPeople has a Merry Christmas by adding a job to clean up old stacks.
 
+![Successful cleanup job.](screenshots/SCREENSHOT09.png)
+
 - Add a job that deletes the previous S3 bucket and EC2 instance. 
 - Provide a screenshot of the successful job. **[SCREENSHOT09]**
 
 #### Other Considerations
 
 - Make sure you only run deployment-related jobs on commits to the `master` branch. Provide screenshot of a build triggered by a non-master commit. It should only run the jobs prior to deployment. **[SCREENSHOT10]**
+
+![Deploy jobs only run on master](screenshots/SCREENSHOT10.png)

instructions/4-turn-errors-into-sirens.md

@@ -15,6 +15,8 @@ UdaPeople chose Prometheus as a monitoring solution since it is open-source and
 
 In order for server instances to speak to Prometheus, we need to install an “exporter” in each one.  Create a job that uses Ansible to go into the EC2 instance and install the exporter.
 
+![Graphs of CPU, Disk and Memory utilization on systems being monitored.](screenshots/SCREENSHOT11.png)
+
 - Add a section to your back-end configuration job to install the `node_exporter` for Prometheus monitoring. This should be done using Ansible. Your playbook can simulate the steps in [this tutorial](https://codewizardly.com/prometheus-on-aws-ec2-part2/). 
 - After deploy, ensure your back-end is being discovered by the Prometheus Server.
 - Provide a screenshot of a graph of your EC2 instance including available memory, available disk space, and CPU usage. **[SCREENSHOT11]**
@@ -24,6 +26,8 @@ In order for server instances to speak to Prometheus, we need to install an “e
 
 Now that Prometheus and our EC2 instance have an open line of communication, we need to set up some alerts. The UdaPeople dev team loves their chat tool and wants to receive an alert in chat when the server starts running out of memory or disk space. Set up a job to make that dream a reality.
 
+![Alerts from a failing system that is being monitored.](screenshots/SCREENSHOT12.png)
+
 - SSH into your Prometheus Server
 - Install and configure AlertManager by following [these instructions](https://codewizardly.com/prometheus-on-aws-ec2-part4/).
 - You can decide if you will use Slack, email, or another messaging service.