Add a couple of questions
And switch some questions from docker to podman.
This commit is contained in:
parent
5ba0a0a4b5
commit
e16b2ecad7
92
README.md
92
README.md
@ -2,7 +2,7 @@
|
||||
|
||||
:information_source: This repo contains questions and exercises on various technical topics, sometimes related to DevOps and SRE :)
|
||||
|
||||
:bar_chart: There are currently **1380** questions
|
||||
:bar_chart: There are currently **1386** questions
|
||||
|
||||
:busts_in_silhouette: [Join](https://www.facebook.com/groups/538897960007080) our [Facebook group](https://www.facebook.com/groups/538897960007080) for additional exercises, articles and more resources on DevOps
|
||||
|
||||
@ -68,10 +68,11 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><a href="#certificates"><img src="images/certificates.png" width="75px;" height="75px;" alt="Certificates"/><br /><b>Certificates</b></a></td>
|
||||
<td align="center"><a href="#docker"><img src="images/docker.png" width="70px;" height="75px;" alt="Docker"/><br /><b>Docker</b></a></td>
|
||||
<td align="center"><a href="#containers"><img src="images/containers.png" width="70px;" height="75px;" alt="Containers"/><br /><b>Containers</b></a></td>
|
||||
<td align="center"><a href="#sql"><img src="images/sql.png" width="75px;" height="75px;" alt="sql"/><br /><b>SQL</b></a></td>
|
||||
<td align="center"><a href="#openshift"><img src="images/openshift.png" width="75px;" height="75px;" alt="OpenShift"/><br /><b>OpenShift</b></a></td>
|
||||
<td align="center"><a href="#storage"><img src="images/storage.png" width="75px;" height="75px;" alt="Storage"/><br /><b>Storage</b></a></td>
|
||||
<td align="center"><a href="#packer"><img src="images/packer.png" width="75px;" height="75px;" alt="Packer"/><br /><b>Packer</b></a></td>
|
||||
<td align="center"><a href="#HR"><img src="images/HR.png" width="110px;" height="75px;" alt="HR"/><br /><b>HR</b></a></td>
|
||||
<td align="center"><a href="#exercises"><img src="images/exercises.png" width="110px;" height="75px;" alt="Exercises"/><br /><b>Exercises</b></a></td>
|
||||
</tr>
|
||||
@ -114,9 +115,9 @@ Red Hat:
|
||||
<details>
|
||||
<summary>What are the anti-patterns of DevOps?</summary><br><b>
|
||||
|
||||
* Not allowing to push in production on Friday :)
|
||||
* One specific person is in charge of different tasks. For example there is only one person who is allowed to merge the code of everyone else
|
||||
* One person is in charge of different tasks. For example there is only one person who is allowed to merge the code of everyone else
|
||||
* Treating production differently from development environment. For example, not implementing security in development environment
|
||||
* Not allowing to push to production on Friday ;)
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -127,6 +128,26 @@ A development practice where developers integrate code into a shared repository
|
||||
Each piece of code (change/patch) is verified, to make the change is safe to merge. Today, it's a common practice to test the change using an automated build that makes sure the code can integrated. It can be one build which runs several tests in different levels (unit, functional, etc.) or several separate builds that all or some has to pass in order for the change to be merged into the repository.
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Can you describe an example of a CI (and/or CD) process starting the moment a developer submitted a change/PR to a repository?</summary><br><b>
|
||||
|
||||
There is no one answer for such question as CI processes vary depending on the technologies used and the type of the project to where the change was submitted.
|
||||
Such processes can include one or more of the following stages:
|
||||
|
||||
* Compile
|
||||
* Build
|
||||
* Install
|
||||
* Configure
|
||||
* Update
|
||||
* Test
|
||||
|
||||
For example:
|
||||
|
||||
A developer submitted a PR to a project. The PR triggered two jobs (or one combined job). One job for lint-testing the change and the second job for building a package using the submitted change and running multiple api/scenario tests. Once all tests passed and the change was approved by a maintainer/core, it's merged/pushed to the repository. If some of the tests failed, the change will not be allowed to merged/pushed to the repository.
|
||||
|
||||
A different process can describe how a developer pushes code to a repository, a workflow then triggered to build a container image and push it the registry. Once in the registry, the k8s cluster is applied with the new changes.
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What is Continuous Deployment?</summary><br><b>
|
||||
|
||||
@ -143,12 +164,16 @@ A development strategy used to frequently deliver code to QA and Ops for testing
|
||||
For more info please read [here](https://www.atlassian.com/continuous-delivery/continuous-deployment)
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Would you prefer a "configuration->deployment" model or "deployment->configuration"?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What CI/CD best practices are you familiar with? Or what do you consider as CI/CD best practice?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Where do you store CI/CD pipeline? (Application repository, one central repository, ...)? Why?</summary><br><b>
|
||||
<summary>Where do you store CI/CD pipelines? (Application repository, one central repository, ...)? Why?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -4343,11 +4368,10 @@ Output variables are named values that are sourced from the attributes of a modu
|
||||
It is also common in the community to use a tool called <code>terragrunt</code> to explicitly inject variables between modules.
|
||||
</b></details>
|
||||
|
||||
## Docker
|
||||
## Containers
|
||||
|
||||
<details>
|
||||
<summary>What is Docker? What is it used for?</summary><br><b>
|
||||
Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings.
|
||||
<summary>What is a Container? What is it used for?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
@ -4375,11 +4399,11 @@ You should choose containers when:
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Explain Docker architecture</summary><br><b>
|
||||
<summary>Explain Podman or Docker architecture</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Describe in detail what happens when you run `docker run hello-world`?</summary><br><b>
|
||||
<summary>Describe in detail what happens when you run `podman/docker run hello-world`?</summary><br><b>
|
||||
|
||||
Docker CLI passes your request to Docker daemon.
|
||||
Docker daemon downloads the image from Docker Hub
|
||||
@ -4446,11 +4470,11 @@ Applied tar sha256:514c3a3e64d4ebf15f482c9e8909d130bcd53bcc452f0225b0a04744de7b8
|
||||
<details>
|
||||
<summary>How do you run a container?</summary><br><b>
|
||||
|
||||
docker run
|
||||
`podman run` or `docker run`
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What `docker commit` does?. When will you use it?</summary><br><b>
|
||||
<summary>What `podman commit` does?. When will you use it?</summary><br><b>
|
||||
|
||||
Create a new image from a container’s changes
|
||||
</b></details>
|
||||
@ -9963,12 +9987,6 @@ A connection leak is a situation where database connection isn't closed after be
|
||||
"A data warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of organisation's decision-making process"
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What is a data lake?</summary><br><b>
|
||||
|
||||
A single data source (at least usually) which is stored in a raw format.
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Explain what is a time-series database</summary><br><b>
|
||||
</b></details>
|
||||
@ -10255,6 +10273,18 @@ As defined by Doug Laney:
|
||||
* Veracity or Variability: Inconsistent, sometimes inaccurate, varying data
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What is DataOps? How is it related to DevOps?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What is Data Architecture?</summary><br><b>
|
||||
|
||||
An answer from [talend.com](https://www.talend.com/resources/what-is-data-architecture):
|
||||
|
||||
"Data architecture is the process of standardizing how organizations collect, store, transform, distribute, and use data. The goal is to deliver relevant data to people who need it, when they need it, and help them make sense of it."
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Explain the different formats of data</summary><br><b>
|
||||
|
||||
@ -10276,6 +10306,14 @@ As defined by Doug Laney:
|
||||
[Data Lake - Wikipedia](https://en.wikipedia.org/wiki/Data_lake)
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Can you explain the difference between a data lake and a data warehouse?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>What is "Data Versioning"? What models of "Data Versioning" are there?</summary><br><b>
|
||||
</b></details>
|
||||
|
||||
#### Apache Hadoop
|
||||
|
||||
<details>
|
||||
@ -10318,6 +10356,24 @@ A programming model for large-scale data processing
|
||||
* Namenode controls all metadata
|
||||
</b></details>
|
||||
|
||||
## Packer
|
||||
|
||||
<details>
|
||||
<summary>What is Packer? What is it used for?</summary><br><b>
|
||||
|
||||
In general, Packer automates machine images creation.
|
||||
It allows you to focus on configuration prior to deployment while making the images. This allows you start the instances much faster in most cases.
|
||||
</b></details>
|
||||
|
||||
<details>
|
||||
<summary>Packer follows a "configuration->deployment" model or "deployment->configuration"?</summary><br><b>
|
||||
|
||||
A configuration->deployment which has some advantages like:
|
||||
|
||||
1. Deployment Speed - you configure once prior to deployment instead of configuring every time you deploy. This allows you to start instances/services much quicker.
|
||||
2. More immutable infrastructure - with configuration->deployment it's not likely to have very different deployments since most of the configuration is done prior to the deployment. Issues like dependencies errors are handled/discovered prior to deployment in this model.
|
||||
</b></details>
|
||||
|
||||
## Certificates
|
||||
|
||||
If you are looking for a way to prepare for a certain exam this is the section for you. Here you'll find a list of certificates, each references to a separate file with focused questions that will help you to prepare to the exam. Good luck :)
|
||||
|
Binary file not shown.
Before Width: | Height: | Size: 22 KiB |
Loading…
Reference in New Issue
Block a user