* Describe each of the following components in Ansible, including the relationship between them:
* Task
* Module
* Play
* Playbook
* Role
```
Task – a call to a specific Ansible module
Module – the actual unit of code executed by Ansible on your own host or a remote host. Modules are indexed by category (database, file, network, …) and also referred as task plugins.
Play – One or more tasks executed on a given host(s)
Playbook – One or more plays. Each play can be executed on the same or different hosts
Role – Ansible roles allows you to group resources based on certain functionality/service such that they can be easily reused. In a role, you have directories for variables, defaults, files, templates, handlers, tasks, and metadata. You can then use the role by simply specifying it in your playbook.
* Write a task to create the directory ‘/tmp/new_directory’
```
- name: Create a new directory
file:
path: "/tmp/new_directory"
state: directory
```
* What would be the result of the following play?
```
---
- name: Print information about my host
hosts: localhost
gather_facts: 'no'
tasks:
- name: Print hostname
debug:
msg: "It's me, {{ ansible_hostname }}"
```
```
When given a written code, always inspect it thoroughly. If your answer is “this will fail” then you are right. We are using a fact (ansible_hostname), which is a gathered piece of information from the host we are running on. But in this case, we disabled facts gathering (gather_facts: no) so the variable would be undefined which will result in failure.
```
* Write a playbook to install ‘zlib’ and ‘vim’ on all hosts if the file ‘/tmp/mario’ exists on the system.
```
---
- hosts: all
vars:
mario_file: /tmp/mario
package_list:
- 'zlib'
- 'vim'
tasks:
- name: Check for mario file
stat:
path: "{{ mario_file }}"
register: mario_f
- name: Install zlib and vim if mario file exists
become: "yes"
package:
name: "{{ item }}"
state: present
with_items: "{{ package_list }}"
when: mario_f.stat.exists
```
* Write a playbook to deploy the file ‘/tmp/system_info’ on all hosts except for controllers group, with the following content
```
I'm <HOSTNAME> and my operating system is <OS>
```
replace <HOSTNAME> and <OS> with the actual data for the specific host you are running on
The playbook to deploy the system_info file
```
---
- name: Deploy /tmp/system_info file
hosts: all:!controllers
tasks:
- name: Deploy /tmp/system_info
template:
src: system_info.j2
dest: /tmp/system_info
```
The content of the system_info.j2 template
```
# {{ ansible_managed }}
I'm {{ ansible_hostname }} and my operating system is {{ ansible_distribution }
2. Hold the result of the last executed expression or statement
3. As a general purpose "throwaway" variable name. For example: x, y, _ = get_data() (x and y are used but since we don't care about third variable, we "threw it away").
```
* Sort a list of lists by the second item of each nested list
```
li = [[1, 4], [2, 1], [3, 9], [4, 2], [4, 5]]
sorted(x, key=lambda l: l[1])
```
* You have the following lists: [{'name': 'Mario', 'food': ['mushrooms', 'goombas']}, {'name': 'Luigi', 'food': ['mushrooms', 'turtles']}]
Extract all type of foods. Final output should be: {'mushrooms', 'goombas', 'turtles'}
<summary>What is the difference between `git pull` and `git fetch`?</summary>
Shortly, git pull = git fetch + git merge
When you run git pull, it gets all the changes from the remote or central
repository and attaches it to your corresponding branch in your local reposistory.
git fetch gets all the changes from the remote repository, stores the changes in
a separate branch in your local repository
</details>
<details>
<summary>Explain the following: `git directory`, `working directory` and `staging area`
</summary>
The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
This answer taken from [git-scm.com](https://git-scm.com/book/en/v1/Getting-Started-Git-Basics#_the_three_states)
</details>
<details>
<summary>How do you resolve git conflicts?</summary>
</details>
<details>
<summary>What is the difference between `git reset` and `git reverse`?</summary>
</details>
<details>
<summary>In what situations are you using `git rebase`?</summary>
</details>
<details>
<summary>What branching strategies are you familiar with?</summary>
