Explore topic-wise InterviewSolutions in .

Backup of Jenkins is needed in case of disaster recovery, retrieving old CONFIGURATION and for AUDITING.

$JENKINS_HOME folder keeps all the Jenkins metadata.

That includes: build logs, job configs, plugins, plugin configurations etc.

Install the ‘think backup’ plugin in Jenkins and enable the backup from settings tab.We have to specify the backup directory and what we want to backup.

Backup directory: $JENKINS_HOME/backup

Backup files generated with the timestamp in the filenames will be STORED under the PATH we specified.

FULL-2019-02-4_07-14 FULL-2019-02-11_13-07

It is a good PRACTICE to version control (using Git) this back-up and move it to cloud.

Restoring:

Backup files are in the tar+zip format.

Copy these over to another server; unzip and un-tar it on the server.

• Pipelines artifacts
• Jenkins has built-in artifacts to RECORD and CAPTURE the FAILURES for analysis and investigation.
• This needs to be mentioned in the JENKINSFILE pipeline:

Sample code:

This gives the artifacts path and the filename

Jenkins auto-builds the source code from Git(any VCS) at every check-in; tests the source code and deploy the code in a tomcat environment via docker.

WEBAPP source code is then DEPLOYED by tomcat server on a production environment.

Pre-requisite:

• Jenkins plugin: “Deploy to container” and “git plugin”
• Edit the ‘post-build’ actions to include the tomcat details.
• Under the SCM section add your git project repository url.

Git project structure:

Add a new project in Jenkins and TRACK your git project url under SCM section.Have a dockerfile with the instruction to connect to the tomcat docker and deploy the webapp folder.

--Add the build section to ‘execute shell’ as below:

Below is the screenshot of the output:

--CLICK on the link: http://localhost:8888/webapp

Jenkins stores the metadata of every PROJECT under $WORKSPACE path.

Two projects: 

• myProject and project_next can be chained to each other and they can share the same data.
• On SUCCESSFUL build of ‘myProject’, build of ‘project_next’ is triggered.

Below code SCREENSHOT is for project_next

This ACCESS the myProject/logs/db.log FILE and read it for a pattern :’prod’

• Step 1: Run the Docker container with puppet server INSTALLED.
• Step 2: Write a basic manifest file:

• Step 3: ADD the resources to install Apache, MySQL and PHP server

Save and exit.

• Step 4: Apply manifest

System resources are the key elements of a Puppet code that defines the architecture and manages the configuration of a system infrastructure.

• Puppet has its own DML (DECLARATIVE MODELLING Language) to write code.
• The main unit of code is called a resource.
• Puppet uses various types of resources to define the different definitions and parameters of a system.

Here is how a resource is written:

• Each resource has 3 items: Resource_type, resource_name and the attributes.

Example:

This code evaluates as:
Resource type ‘user’ with the resource parameter ‘Jack’ have the attributes: ‘ensure’, ‘owner’, ‘group’, ‘mode’ and ‘shell’.

These attributes have the respective values.

We can get a list of all the available resource types with the command:

• puppet describe --list

Some of the common resource types are:

• user
• PACKAGE
• exec
• file
• service

Example of resource_type: ‘service’. This resource ensures that the service: ‘network’ is RUNNING service 

The above failure happens when the ‘manager’ DOCKER machine is not active; as a result, the new node machine will not be ABLE to join the swarm cluster.

To fix this:

• Step 1: CHECK for the active machine hosts as:

• Step 2: Activate the ‘manager’ machine as:

• Step 3: Get the swarm join token as worker

• Step 4: Connect to the worker machine say: worker2 [ To create docker node machines as worker: join node as a worker ]

• Step 5: Run the swarm join token command; it will be SUCCESSFUL

As the number of docker machines increases, there needs to be a system to manage them all. Docker Orchestration is a virtual docker MANAGER and allows us to start, stop, pause, unpause or kill the docker nodes(machines).

Docker has an in-built utility called “docker swarm”.

Kubernetes is another popular and versatile docker orchestration system used. A CLUSTER of dockers is called a ‘swarm’. Swarm turns a collection of docker engines into a single virtual docker engine.

In a swarm orchestration arrangement, one machine acts as a swarm manager that controls all the other machines connected to the cluster that acts as swarm nodes.

This is how I created a swarm of dockers and managed them on my machine:

We need docker services and docker machines to run these services on.Finally, we need a docker swarm to manage the docker nodes/machines

• Commands we need:
• docker service
• docker-machine
• docker swarm
• Task
• Create docker machines(nodes) and services.

Create a docker swarm and manage the services on different nodes and port numbers.

• Step 1: Create docker machines as ‘manager’ and ‘worker’: manager, node1, node2, node3, node4
• Step 2: Create a docker swarm
• Step 3: ADD the nodes as workers(or another manager) to the swarm
• Step 4: From the manager create docker services
• Step 5: list the docker services created also use -PS flag to view the node machines these services are running on.
• Step 6: Open the <ip_address>:<port_number> in the BROWSER and confirm the services running.

Step 1: Create docker machines: manager, node1, node2, node3, node4

docker-machine create --driver virtualbox manager

Step 2: Create a docker swarm

--Initialize a swarm and add ‘manager’ to the swarm cluster using its ip address: 192.168.99.100

Step 3: Add the nodes as workers(or another manager) to the swarm

--Connect to each node and run the above swarm join command

There can be more than one ‘manager’ node in a swarm

--connect to node1 and join node1 to the swarm as a worker

docker-machine ssh node1

--List the nodes connected in the swarm

connect to manager node:

$docker-machine ssh manager

Step 4: From the ‘manager’ node create new docker services

docker-machine ssh manager

--Create service replicating them on more than 1 nodes and expose them on the mentioned port.

This command pulls the docker image from docker hub.

Step 5: list the docker services created also use -ps flag to view the node machines these services are running on.

--List the services that will be shared among different swarm nodes

Swarm randomly assigns nodes to the running services when we replicate the services.

--service ‘httpd’ running on 3 nodes: node1, node2 and node3

--service ‘couchbase’ is running on 2 nodes: node1 and manager at port: 8091

--’couchbase’ service can be accessed via ‘node1’ (ip: 192.168.99.101) and ‘manager’ (ip: 192.168.99.100) at port : 8091 as show below

• http://192.168.99.101:8091/
• http://192.168.99.100:8091
• --’httpd’ service
• http://192.168.99.101:80
• http://192.168.99.102:80
• http://192.168.99.103:80
• --’my_nginx’ service
• http://192.168.99.100:8080
• http://192.168.99.104:8080

Screenshots of the running services:

‘manager’ node can create/inspect/list/scale or remove a service.

Refer

docker service --help

Conclusion:

A number of services are balanced over different nodes(machines) in a swarm cluster.A node declared as a ‘manager’ controls the other nodes.Basic ‘docker commands’ works from within a ‘manager’ node.

Docker provides a system prune command to remove stopped containers and dangling IMAGES.Dangling images are the ones which are not attached to any CONTAINER.

Run the prune command as below:

docker system prune

WARNING! This will remove:

• all stopped containers
• all networks not used by at least one container
• all dangling images
• all dangling build cache

Are you SURE you want to CONTINUE? [y/N]

There is also a better and controlled way of removing containers and images using the command:

Step 1: Stop the containers

Step 2: Remove the stopped container

Step 3: Remove the images, first stop the container using those images and then

--GIVE image name and tag

--give the image id

Write instructions in a dockerfile.

• build the dockerfile and create an image in the registry

docker build -t learn_docker dockerFiles/

• Create a container by running this image

docker run -it learn_docker

• Push the container to the docker hub.

--Tag the local image as:

Examples:

--list the images for this container:

• Image: Screenshot from the Docker hub.
• Docker hub repository: learn_docker has DIFFERENT variations of images. Image names are tagged.
• We can pull the tags from this repository as PER the need.

Summarize:

Develop your application CODE and all other dependencies like the binaries, library files, downloadables required to run the application in the test environment. Bundle it all in a directory.

• Edit the dockerfile to Run the downloadables and replicate the desired production environment as test env.
• Copy the entire application bundle to the test env in the docker container.
• Build the dockerfile and create new docker image and tag it.
• Push this docker image to the docker hub, which is now downloaded by other users to test.

NOTE: This docker image has your application bundle = application code + dependencies + test run time environment exactly similar to your machine. Your application bundle is highly portable with no hassles.

• mkdir DOCKERFILES
• vi dockerfile

--Build an image from the dockerfile, tag the image name as ‘mydocker’

• View the images:
• docker image
• docker image --all
• docker run -it ubuntu (imageName)
• -i = interactive
• -t = Allocate a sudo-tty (i.e, PROVIDE a terminal for the remote container image)

Install a new package in a container

Commit the changes in the container to create a new image.

--List if the new image is listed

Git hooks are the instruction scripts that gets triggered before(pre) or post(after) certain actions or events such as a git command run.

• Git hooks can be implemented on both client(local machine) and server(remote) repositories.
• Hooks objects are stored under .git/hooks directory. Hooks scripts are written in shell script and made executable.
• --Code snippet of a ‘pre-commit’ script that stops the commit if a file has been deleted from the project:

Scenario how I implemented the hooks scripts to enforce certain pre-commit and post-commit test cases:

Step 1: Running .git/hooks/pre-commit script.

Step 2: Running .git/hooks/prepare-commit-msg script.

Step 3: Running .git/hooks/commit-msg script.

Step 4: Running .git/hooks/post-commit script.

New commit made:

• A ‘pre-rebase’ script to stop the rebase on a ‘master’ branch:
• Rebase ‘topic’ branch on ‘master’ branch

A code snippet demonstrating the use of a ‘pre-receive’ hook that is triggered just before a ‘push’ request on the Server, can be written to reject or allow the push operation.

git log --oneline <localBranch>..<origin/remoteBranch>

Your local git branch should be SET up to track a remote branch.

Reset ‘dev’ commit history to 3 commits behind using the command:

Compare and list the missing logs in local ‘dev’ branch that are present in ‘origin/dev’

Use ‘git pull’ to sync local ‘dev’ branch with the remote ‘origin/dev’ branch.

• ‘git MERGE’ takes the unique commits from the two BRANCHES, merge them together and CREATE another commit with the merged changes; whereas in a ‘git rebase’ the work on the current branch is replayed and placed at the tip of the other branch resulting in re-writing the commit objects.
• ‘git rebase’ is applied from the branch to be rebased, whereas ‘git merge’ is applied on the branch that needs to merge the feature branch.
• ‘git merge’ preserves the history and makes it easier to track the ownership or when a code was broken in the project history; UNLIKE ‘git rebase’ which changes the commit history by changing the commit objects (SHA-1) ids.
• ‘git rebase’ is often used locally for feature and quickfix and bug fix branches; however ‘git merge’ are used for long running STABLE branches.

A good BRANCHING strategy is the one that adapts to your PROJECT and business needs. Every organization has a set of its own defined SDLC processes.
An example branching STRUCTURAL strategy that I have used in my project:

• Diagram: Branching strategy
• Clone the project available at github:
• git clone http://github.com/divyabhushan/structuralStrategy.git structuralStrategy

 Guidelines: 

• “master-prod”: Accepts merges/code/commits only from the “prod” branch
• “prod”: Perform only a merge --squash from “release” branch.
• Merge only when approved by “QA”
• Tag every merge in the format: v1.0, v1.1 … v1.*
• “release”: merge from the branches “dev”, “uat”, “QA”.
• Every release commit/project code version has to be approved by “QA”.
• Tag every merge in the format: r1.0, r1.1 … r1.*
• “dev” and “uat” NEVER merge with each other.
• “hotfix” branch commits are shared among any feature branches such as “dev” and “uat”
• “feature” branch is private to “dev” alone and is dropped after merging.
• CI/CD DevOps tools can be used to automate the above development and deployment to master_prod.
• Every project release: r1.0 .. r1.x on the ‘release’ branch can be tracked by Jenkins CI TOOL and will trigger a build, on a successful build continuous testing suite 
• cases will be triggered on the code. If the test passes the release will be delivered to ‘prod’ branch.
• Every source code delivered to ‘prod’ branch will be automatically deployed to ‘master_prod’ branch.

All the steps will be mentioned in a Jenkins file on a branch ‘name’ condition.

By default, git does not allow you to delete a branch whose work has not yet been MERGED into the main branch.

 To see the list of branches not merged with the CHECKED out branch run:

 --If you TRY to delete this branch, git displays a warning:

--If it is still deleted using the -D flag as:

--See the references log information

b834dc2 is the commit id when we jumped to ‘dev’ branch
Create a branch named ‘dev’ from this commit id again.

Continuous Integration is a development practice wherein developers regularly merge or integrate their code changes into a common shared repository very frequently (*).EVERY code check-in is then verified by automated build and automated test cases.

This approach helps to detect and fix the bugs early, IMPROVE software quality,reduce the validation and feedback loop time; hence increasing the overall product quality and speedy product releases.

• (*) Unlike traditional SDLC process wherein a developer would wait until the completion of the code before he/she shares the work on the shared repository.
• Git becomes the best VCS tool with its strong, easy and RELIABLE branching and merging architecture for Continuous Integration in a DevOps environment.
• Continuous Delivery is a software practice where every code check-in is automatically built, tested and ready for a release(delivery) to production.
• Every code check-in should be release/deployment ready.
• CD is an extension to CI.
• CD phase delivers the code to a production like environment such as dev, uat, preprod etc and run automated tests.
• On successful IMPLEMENTATION of continuous delivery in the prod-like environment the code is ready to be DEPLOYED to the main production server.

We can mention some test conditions to run post the completion of stages in a PIPELINE.

Code snippet

Here are the post conditions reserved for jenkinsfile:

• always:

Run the steps in the post section REGARDLESS of the completion status of the Pipeline’s or stage’s run.

• unstable:

Only run the steps in post if the current Pipeline’s or stage’s run has an "unstable" status, usually caused by test FAILURES, code violations, etc.

• aborted:

Only run the steps in post if the current Pipeline’s or stage’s run has an “aborted” status.

• success:

Only run the steps in post if the current Pipeline’s or stage’s run has a "success" status.

• failure:

Only run the steps in post if the current Pipeline’s or stage’s run has a "failed" status.

• changed:

Only run the steps in post if the current Pipeline’s or stage’s run has a different completion status from its previous run.

• cleanup:

Run the steps in this post condition after every other post condition has been evaluated, regardless of the Pipeline or stage’s status.

• Continuous Integration using Jenkins and Git plugin
• Create a new Jenkins item as a ‘Pipeline’.
• Add ‘Git’ as BRANCH source and give the Project repository url.
• Every time source code is pushed to the remote git repository from the local git repo;
• Jenkins job gets started(triggered).
• Jenkins build the code and the output is available under “CONSOLE output”
• In the git repository add a ‘jenkinsfile’ COMMIT and push the code to git repository.
• Add a Jenkinsfile in the git repository

Jenkins is a self-contained, open source automation server(tool) for continuous development.

Jenkins aids and AUTOMATES CI/CD process.

It gets the checked in CODE from VCS like Git using a ‘git plugin’, build the source code, run test cases in a production-like environment and make the code release ready using ‘deploy’ plugin.

• These continuous DELIVERY pipelines are written in a ‘Jenkinsfile’ which is also checked into project’s source code and version controlled by Git.
• Pipelines are a continuous set of jobs that are run for continuous delivery and these jobs are integrated at every section of the workflow.
• Jenkins pipelines easily connect to Docker images and containers to run inside.
• Pipelines easily provide the desired test environment without having to configure the various system tools and dependencies.

Sample Jenkins file

• Jenkins will start the container- ubuntu with the latest image and execute the test case steps inside it.
• agent directive SAYS where and how to execute the pipeline
• jenkinsfile (declarative pipeline)
• pipeline
• Jenkins saves US the trouble of debugging after a huge commit history if there was a code break.

Entire SERVER Infrastructure setup configurations are written in TERMS of codes and re-used on all the Puppet Server agent’s NODES(machines) that are connected VIA a Puppet master Server.

This is achieved by the use of code snippets called ‘manifests’; that are configuration files for every Server agent node.

• Each manifest (program files with *.pp extension) consists of the resources and the codes.
• We can REVIEW, deploy and test the environment configuration for development, testing and production environments.
• Puppet manifests written once are deployed on any environment to build up the same infrastructure.

Puppet is a Configuration Management and deployment tool for administrative tasks.

This tool helps in automating the PROVISIONING, configuration, and management of INFRASTRUCTURE and Systems.

In simple words:

• Puppet helps administrators to automate the process of MANUALLY creating and configuring Virtual machines.
• Say, you have to bring up ‘n’ number of SERVERS with ‘x’ number of VMs(Virtual machines) on them. Each VM needs to be configured for certain users, groups, services, applications, and databases etc.
• The entire infrastructure can be loaded up with the help of Puppet programs re-using the codes on multiple servers.
• Key feature: Idempotency
• The same set of configurations can be run multiple times to build a machine on a server, as puppet would allow only UNIQUE configurations to be run.

--Get docker images from docker hub or your docker REPOSITORY

--List the docker images

--Create a docker container by running the docker image

--pass a shell argument  : `uname -a`

--Docker images can be built by reading a dockerfile

--build a new image : ‘newrepo’ with tag:1.0 from the dockerFiles/dockerfile

docker build -t newrepo:1.1 dockerFiles/

--Now create a container from the above image:

--List all the containers

--start the container

--List only the running containers

A developer writes code instructions to define all the applications and its dependencies in a file CALLED a “Dockerfile”.Dockerfile is used to create a ‘Docker image’ using the ‘docker build <directory>’ command.The build command is run by the docker daemon.

When you run a Docker image “Containers” are created. Containers are runtime instances of a Docker image.

• A Container can have MANY images.
• Docker containers are stored in a docker registry on docker host.
• Docker has a client-Server architecture.
• Docker registry is generally pushed and shared on a Docker hub (REMOTE server).

Image CREDIT: docs.docker.com

• Other developers ‘Docker pull’ these registry images and create containers in their own environment.
• Developers can run their applications in the same docker container as their peers.
• This way you can get the same test environment on different servers with the same applications and dependencies.

Every source code DEPLOYMENT needs to be PORTABLE and compatible on every device and environment.

Applications and their RUN time environment such as libraries and other dependencies like binaries, jar files, configuration files etc.. are bundled up(packaged) in a Container.

Containers as a whole are portable, consistent and compatible with any environment.

In development words, a developer can run its application in any environment: dev, uat, preprod and production WITHOUT worrying about the run-time dependencies of the application.

• Docker is a container platform.
• Docker is a FRAMEWORK that provides an abstraction layer to manage containers.
• Docker is a containerization engine, which automates packaging, shipping, and deployment of any software applications or Containers.
• Docker also lets us test the code and then deploy it in production.
• Docker along with Jenkins (a Continuous Integration tool) and Git plugin contributes in CI/CD process.

There are scenarios wherein one would like to merge a quickfix or feature branch with not a huge commit history into another ‘dev’ or ‘uat’ branch and yet maintain a linear history.

A non-fast forward ‘GIT merge’ would result in a diverged history. Also when one wants the feature merged commits to be the latest commits; ‘git rebase’ is an appropriate way of merging the two BRANCHES.

‘git rebase’ replays the commits on the current branch and place them over the tip of the rebased branch.Since it replays the commit ids, rebase rewrites commit objects and create a new object id(SHA-1). Word of caution: Do not use it if the history is on release/production branch and being shared on the central server. Limit the rebase on your local repository only to rebase quickfix or feature branches.

Steps:

Say there is a ‘dev’ branch that needs a quick feature to be added along with the TEST cases from ‘uat’ branch.

• Step 1: Branch out ‘new-feature’ branch from ‘dev’.

Develop the new feature and make commits in ‘new-feature’ branch.

• Step 2: Merge ‘uat’ branch into ‘dev’

• Step 3: Rebase ‘new-feature’ on ‘dev’

• Step 4: Switch to ‘dev’ branch and merge ‘new-feature’ branch, this is going to be a fast-forward merge as ‘new-feature’ has already incorporated ‘dev’+’uat’ commits.

this will result in linear history with ‘new-feature’ results being at the top and ‘dev’ commits being pushed later.

• Step 5: View the history of ‘dev’ after merging ‘uat’ and ‘new-feature’ (rebase)

NOTE: ‘dev’ will SHOW a diverged commit history for ‘uat’ merge and a linear history for ‘new-feature’ merge.

• git revert is used to record some new commits to reverse the effect of some earlier commits/snapshot of a project.
• Instead of REMOVING the commit from the project history, it figures out how to undo the changes introduced by the commit & appends a new commit with the resulting content in the current branch.

• Usage: git revert <commit_id>
• USE: To undo an ENTIRE commit from your project history; removing a bug introduced by a commit.

Reset VS Revert

• git “reset”: resets the project to a previous snapshot ERASING the changes.
• git “revert” does not change the project history unlike git “reset”
• Git “revert” undoes the commit id changes and applies the undo work as a new commit id object.

When a project repository is initialized to be a git repository, git stores all its metadata in a hidden folder “.git” under the project root directory.
Git repository is a collection of objects. 

Git has 4 types of objects – blobs, trees, tags, and commits.

Every commit creates a new commit object with a unique SHA-1 hash_id.
Each commit object has a pointer reference to the tree object, its parent object, author, COMMITTER and the commit message.

Diagram: Single Commit object

To see the commit log message along with the textual diff of the code, run:
git show <commit_id>

To read a commit object git has ‘git cat-file’ utility.

A tree object is LIKE an OS directory that stores references to other directories and FILES (blob type).

Git is a Distributed Version Control System; USED to logically store and backup the entire history of how your project source code has developed, keeping a track of every version change of the code.

Git facilitates very flexible and efficient branching and merging of your code with other collaborators.Being distributed git is EXTREMELY fast and more RELIABLE as every developer has his own local copy of the entire repository.

Git allows you to undo the mistakes in the source code at different tiers of its architecture namely- Working directory, Staging (Index) area, Local repository, and Remote repository.

Using Git we can always get an older version of our source code and work on it.Git tracks every bit of data as it checksums every file into unique hash codes referring to them via pointers.

To summarize Git is the most efficient and widely used VCS, used by major companies like Linux, Google, Facebook, Microsoft, Twitter, LINKEDIN, Netflix, Android, Amazon, IBM, Apple IOS to name a few…

Considering DevOps to be an ideology towards ACHIEVING a quality product, every organization has its own guidelines and approach towards it.
Some of the popular tools I have USED are:

• Git as a Distributed VCS to manage the source code.
• Jenkins to achieve CI/CD (CONTINUOUS Integration and Continuous Delivery) +plugins
• Puppet for Configuration Management and Deployment tool
• Nagios for Continuous Monitoring; and
• Docker for containerization.

DevOps is an approach to COLLABORATE the development and operations teams for a better, bug-free continuous DELIVERY and integration of the source code.
DevOps is about automating the entire SDLC (Software Development Life Cycle) process with the implementation of CI/CD practices.

CI/CD are the Continuous integration and continuous deployment methodologies.
Every source code check-in will automatically BUILD and unit TEST the entire code against a
production like environment and continuously deployed to production environment after it passes its automated tests.
That eliminates the long feedback, bug-fix, and product enhancements loops between every
Release.

Every team takes the accountability of the entire product right from the requirement ANALYSIS to documentation to coding, testing in development environments, code deployment and continuous improvements in terms of bugs and feedback from reviewers and the customers.

How does the Service Management process of ITIL Service Transition PHASE map in a DevOps organization?
Choose the correct option from below LIST
(1)Maintaining stable and fixed teams to avoid resource switching between projects.
(2)Managing changes through the same mechanisms used for aligning the business with IT
(3)Bringing NEW software live in a matter of minutes through automation
(4)Aligning IT with the needs of business following Agile practices.

Answer:-(4)Aligning IT with the needs of business following Agile practices.

Which DEVOPS principle appreciates measuring processes, people and TOOLS?
CHOOSE the correct option from below list
(1)People RESPONSIBILITY
(2)Create with the end in mind
(3)Cross-functional autonomous teams
(4)Continuous improvement

Answer:-(4)Continuous improvement

Which of these STATEMENTS are true
Choose the correct option from below list
(1)DEVOPS looks to EXTEND Dev into Production
(2)DevOps looks to EMBED DEVELOPMENT into IT Operations
(3)DevOps looks to embed IT Operations into Development
(4)All of the above

Answer:-(4)All of the above

What is NOT an aspect related to governing WORK in an organization?
Choose the correct OPTION from below LIST
(1)SCRUM of scrums
(2)Feature Switches
(3)Scrum board
(4)Test Automation

Answer:-(4)Test Automation

What is the difference between Continuous Delivery and Continuous Deployment?
Choose the correct option from below list
(1)Continuous Delivery is a manual task, while Continuous Deployment is an AUTOMATED task
(2)Continuous Delivery has a manual release to a production decision, while Continuous Deployment has releases automatically pushed to production.
(3)Continuous Delivery INCLUDES all steps of the software development life CYCLE, Continuous deployment may skip a few steps such as validation and testing.
(4)Continuous Delivery means complete delivery of the application to the customer, Continuous Deployment includes the only deployment of the application in a customer environment.

Answer:-(2)Continuous Delivery has a manual release to a production decision, while Continuous Deployment has releases automatically pushed to production.

The DEVOPS movement has evolved to solve which problem?
Choose the correct option from below list
(1)Increasingly complex, virtualized IT environments
(2)The need for multiple rapidly times software RELEASES, sometimes MANY in one DAY.
(3)The tradition siloed approach to app development and deployment
(4)All of the above

Answer:-(4)All of the above

DevOps is a
Choose the CORRECT option from below list
(1)Culture
(2)Role
(3)Team
(4)All of the above

Answer:-(1)Culture

The ORIGINS of the DevOps trace back to when
Choose the CORRECT option from below LIST
(1)2010
(2)2009
(3)2008
(4)2006

Answer:-(2)2009

What is NOT an appropriate PREDICTOR of IT performance in a DevOps environment?
Choose the CORRECT option from below list
(1)Changes approved by an external team members
(2)High-trust organizational CULTURE
(3)Proactive monitoring
(4)Version control of all artifacts

Answer:-(4)Version control of all artifacts

One of the most common difference between DevOps and Agile SDLC?
One of the MAIN difference between DevOps and Agile SDLC is
(1)Agile software devlopment methodology mainly focuses on the devlopment of software.
(2)On the other hand DevOps is RESPONSIBLE for both DEVELOPMENT and deployment of the software. And this will also take CARE the both the transaction are done in safest and most reliable way possible.

The DevOps MOVEMENT is an outgrowth of which SOFTWARE development methodology?
Choose the correct option from below list
(1)AGILE
(2)WATERFALL
(3)Promise based algorithms
(4)Test-driven development and model-driven development

Answer:-(1)Agile

What is not a challenge between the DEVELOPMENT and Operations TEAMS in a traditional organization
Choose the CORRECT option from below list
(1)The blame game between Dev and Ops
(2)Different tools used between Dev and Ops
(3)No feedback LOOP between Dev and Ops
(4)Development and Operations is not maintained by the same person

Answer:-(4)Development and Operations is not maintained by the same person

What type of TASKS are characterized by LOW TASK variability and high tasks analyzibility?
Choose the correct option from below list
(1)CRAFT
(2)Engineering
(3)Routine
(4)Non-Routine

Answer:-(3)Routine

What type of mindset is the core of a DevOps culture?
Choose the CORRECT OPTION from below list
(1)Service Mindset
(2)SKILL Mindset
(3)PEOPLE Mindset
(4)Process Mindset

Answer:-(1)Service Mindset

The goal of DevOps is not just to increase the rate of change but to SUCCESSFULLY deploy features into production without causing CHAOS and disrupting other services
Choose the CORRECT OPTION from below list
(1)True
(2)False

Answer:-(1)True

Which of these tools is not ASSOCIATED with DEVOPS?
CHOOSE the correct option from below LIST
(1)Chef
(2)Liebert MPX
(3)Juju
(4)Puppet

Answer:-(2)Liebert MPX