Top Devops Interview Questions and Answers

DevOps is a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably. The concept of DevOps is founded on building a culture of collaboration between teams that historically functioned in relative siloes. The promised benefits include increased trust, faster software releases, and ability to solve critical issues quickly, and better manage unplanned work.

(Or)

Post a Question

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

Amazon Web Services (AWS) provide many tools and features to deploy and manage applications in AWS. As per DevOps, we treat infrastructure as code. We mainly use following two services from AWS for DevOps:

Cloud Formation: We use AWS Cloud Formation to create and deploy AWS resources by using templates. We can describe our dependencies and pass special parameters in these templates. Cloud Formation can read these templates and deploy the application and resources in AWS cloud.

OpsWorks: AWS provides another service called OpsWorks that is used for configuration management by utilizing Chef Framework. We can automate server configuration, deployment and management by using OpsWorks. It helps in managing EC2 instances in AWS as well as any on-premises servers.

The typical DevOps workflow in our organization is as follows:

• We use Atlassian Jira for writing requirements and tracking tasks.
• Based on the Jira tasks, developer’s check-in code into GIT version control system.
• The code checked into GIT is built by using Apache Maven.
• The build process is automated with Jenkins.
• During the build process, automated tests run to validate the code checked in by developer.
• Code built on Jenkins is sent to organization’s Artifactory.
• Jenkins automatically picks the libraries from Artifactory and deploys it to Production.
• During Production deployment Docker images are used to deploy same code on multiple hosts.
• Once code is deployed to Production, we use Nagios to monitor the health of production servers.
• Splunk based alerts inform us of any issues or exceptions in production.

DevOps is a very popular trend in Software Development. Some of the main benefits of DevOps are as follows:

Release Velocity: DevOps practices help in increasing the release velocity. We can release code to production more often and with more confidence.

Development Cycle: With DevOps, the complete Development cycle from initial design to production deployment becomes shorter.

Deployment Rollback: In DevOps, we plan for any failure in deployment rollback due to a bug in code or issue in production. This gives confidence in releasing feature without worrying about downtime for rollback.

Defect Detection: With DevOps approach, we can catch defects much earlier than releasing to production. It improves the quality of the software.

Recovery from Failure: In case of a failure, we can recover very fast with DevOps process.

Collaboration: With DevOps, collaboration between development and operations professionals increases.

Performance-oriented: With DevOps, organization follows performance-oriented culture in which teams become more productive and more innovative.

We use following tools for work in DevOps:

Jenkins: This is an open source automation server used as a continuous integration tool. We can build, deploy and run automated tests with Jenkins.

GIT: It is a version control tool used for tracking changes in files and software.

Docker: This is a popular tool for containerization of services. It is very useful in Cloud based deployments.

Nagios: We use Nagios for monitoring of IT infrastructure.

Splunk: This is a powerful tool for log search as well as monitoring production systems.

Puppet: We use Puppet to automate our DevOps work so that it is reusable.

Continuous Integration (CI) is the process of automating the build and testing of code every time a team member commits changes to version control. CI encourages developers to share their code and unit tests by merging their changes into a shared version control repository after every small task completion. Committing code triggers an automated build system to grab the latest code from the shared repository and to build, test, and validate the full master branch (also known as the trunk or main).

Continuous Delivery (CD) is the process to build, test, configure and deploy from a build to a production environment. Multiple testing or staging environments create a Release Pipeline to automate the creation of infrastructure and deployment of a new. Successive environments support progressively longer-running activities of integration, load, and user acceptance testing. Continuous Integration starts the CD process and the pipeline stages each successive environment the next upon successful completion of tests.

The benefits of Continuous Integration (CI) are as follows:

• CI makes the current build constantly available for testing, demo and release purpose.
• With CI, developers write modular code that works well with frequent code check-ins.
• In case of a unit test failure or bug, developer can easily revert back to the bug-free state of the code.
• There is drastic reduction in chaos on release day with CI practices.
• With CI, we can detect Integration issues much earlier in the process.
• Automated testing is one very useful side effect of implementing CI.
• All the stakeholders including business partners can see the small changes deployed into pre-production environment. This provides early feedback on the changes to software.
• Automated CI and testing generates metrics like code-coverage, code complexity that help in improving the development process.

Build Automation: In CI, we create such a build environment that even with one command build can be triggered. This automation is done all the way up to deployment to Production environment.

Main Code Repository: In CI, we maintain a main branch in code repository that stores all the Production ready code. This is the branch that we can deploy to Production any time.

Self-testing build: Every build in CI should be self-tested. It means with every build there is a set of tests that runs to ensure that changes are of high quality.

Every day commits to baseline: Developers will commit all of theirs changes to baseline every day. This ensures that there is no big pileup of code waiting for integration with the main repository for a long time.

Build every commit to baseline: With Automated Continuous Integration, every time a commit is made into baseline, a build is triggered. This helps in confirming that every change integrates correctly.

Fast Build Process: One of the requirements of CI is to keep the build process fast so that we can quickly identify any problem.

Production like environment testing: In CI, we maintain a production like environment also known as pre-production or staging environment, which is very close to Production environment. We perform testing in this environment to check for any integration issues.

Publish Build Results: We publish build results on a common site so that everyone can see these and take corrective actions.

Deployment Automation: The deployment process is automated to the extent that in a build process we can add the step of deploying the code to a test environment. On this test environment, all the stakeholders can access and test the latest delivery.

CICD stands for Continuous Integration and Continuous Delivery. These are two different concepts that are complementary to each other.

Continuous Integration (CI): In CI all the developer work is merged to main branch several times a day. This helps in reducing integration problems.

In CI we try to minimize the duration for which a branch remains checked out. A developer gets early feedback on the new code added to main repository by using CI.

Continuous Delivery (CD): In CD, a software team plans to deliver software in short cycles. They perform development, testing and release in such a short time that incremental changes can be easily delivered to production.

In CD, as a DevOps we create a repeatable deployment process that can help achieve the objective of Continuous Delivery.

Microservices describes the architectural pattern of composing a distributed application from separately deployable services that perform specific business functions and communicate over web interfaces. DevOps teams encapsulate individual pieces of functionality in micro services and build larger systems by composing the micro services like building blocks. Micro services apply an example of the open/closed principle: they are open for extension (using the interfaces they expose) and closed for modification (in that each is implemented and versioned independently).

Micro services provide many benefits over monolithic architectures. They can remove single points of failure (SPOFs) by ensuring issues in one service do not crash or impact other parts of an application.  Individual micro services can be scaled out independently to provide additional availability and capacity. DevOps teams can extend functionality by adding new micro services without unnecessarily affecting other parts of the application. Using micro services can increase team velocity. DevOps practices, such as Continuous Integration and Continuous Delivery, are used to drive micro service deployments.

AWS Cloud Formation is used for deploying AWS resources.

In Cloud Formation, we have to first create a template for a resource. A template is a simple text file that contains information about a stack on AWS. A stack is a collection of AWS resourced that we want to deploy together in an AWS as a group.

Once the template is ready and submitted to AWS, Cloud Formation will create all the resources in the template. This helps in automation of building new environments in AWS.

Some of the main features of AWS OpsWorks Stacks are as follows:

Server Support: AWS OpsWorks Stacks we can automate operational tasks on any server in AWS as well as our own data centre.

Scalable Automation: We get automated scaling support with AWS OpsWorks Stacks. Each new instance in AWS can read configuration from OpsWorks. It can even respond to system events in same way as other instances do.

Dashboard: We can create dashboards in OpsWorks to display the status of all the stacks in AWS.

Configuration as Code: AWS OpsWorks Stacks are built on the principle of “Configuration as Code”. We can define and maintain configurations like application source code. Same configuration can be replicated on multiple servers and environments.

Application Support: OpsQorks supports almost all kinds of applications. So it is universal in nature.

GIT provides the feature to execute custom scripts when certain event occurs in GIT. This feature is called hooks.

We can write two types of hooks.

• Client-side hooks
• Server-side hooks

For this case, we can write a Client-side post-commit hook. This hook will execute a custom script in which we can add the message and code that we want to run automatically with each commit.

Some of the popular use cases of Ansible are as follows:

App Deployment: With Ansible, we can deploy apps in a reliable and repeatable way.

Configuration Management: Ansible supports the automation of configuration management across multiple environments.

Continuous Delivery: We can release updates with zero downtime with Ansible.

Security: We can implement complex security policies with Ansible.

Compliance: Ansible helps in verifying and organization’s systems in comparison with the rules and regulations.

Provisioning: We can provide new systems and resources to other users with Ansible.

Orchestration: Ansible can be used in orchestration of complex deployment in a simple way.

Docker Hub is a cloud-based registry. We can use Docker Hub to link code repositories. We can even build images and store them in Docker Hub. It also provides links to Docker Cloud to deploy the images to our hosts.

Docker Hub is a central repository for container image discovery, distribution, change management, workflow automation and team collaboration.

In security implementation, we use Multi-factor authentication (MFA). In MFA, a user is authenticated by multiple means before giving access to a resource or service. It is different from simple user/password-based authentication.

The most popular implementation of MFA is Two-factor authentication. In most of the organizations, we use username/password and an RSA token as two factors for authentication.

With MFA, the system becomes more secure and it cannot be easily hacked.

Nagios is open source software to monitor systems, networks and infrastructure. The main benefits of Nagios are as follows:

Monitor: DevOps can configure Nagios to monitor IT infrastructure components, system metrics and network protocols.

Alert: Nagios will send alerts when a critical component in infrastructure fails.

Response: DevOps acknowledges alerts and takes corrective actions.

Report: Periodically Nagios can publish/send reports on outages, events and SLAs etc.

Maintenance: During maintenance windows, we can also disable alerts.

Planning: Based on past data, Nagios helps in infrastructure planning and upgrades.

In Jenkins, it is very important to make the system secure by setting user authentication and authorization. To do this we have to do following:

• First we have to set up the Security Realm. We can integrate Jenkins with LDAP server to create user authentication.
• Second part is to set the authorization for users. This determines which user has access to what resources.

In Jenkins, some of the options to setup security are as follows:

• We can use Jenkins’ own User Database.
• We can use LDAP plugin to integrate Jenkins with LDAP server.
• We can also setup Matrix based security on Jenkins.

In any organization, Recipe is the most fundamental configuration element.

It is written in Ruby language. It is a collection of resources defined by using patterns.

A Recipe is stored in a Cookbook and it may have dependency on another Recipe.

We can tag Recipe to create some kind of grouping.

We have to add a Recipe in run-list before using it by chef-client.

It always maintains the execution order specified in run-list.

Ansible is a powerful tool for IT Automation for large scale and complex deployments. It increases the productivity of team. Some of the main benefits of Ansible are as follows:

Productivity: It helps in delivering and deploying with speed. It increases productivity in an organization.

Automation: Ansible provides very good options for automation. With automation, people can focus on delivering smart solutions.

Large-scale: Ansible can be used in small as well as very large-scale organizations.

Simple DevOps: With Ansible, we can write automation in a human-readable language. This simplifies the task of DevOps.

Chaos Monkey is a concept made popular by Netflix. In Chaos Monkey, we intentionally try to shut down the services or create failures. By failing one or more services, we test the reliability and recovery mechanism of the Production architecture.

It checks whether our applications and deployment have survival strategy built into it or not.

We use Jenkins to create automated flows to run Automation tests. The first part of test automation is to develop test strategy and test cases. Once automation test cases are ready for an application, we have to plug these into each Build run.

In each Build we run Unit tests, Integration tests and Functional tests.

With a Jenkins job, we can automate all these tasks. Once all the automated tests pass, we consider the build as green. This helps in deployment and release processes to build confidence on the application software.

Puppet Enterprise is a DevOps software platform that is used for automation of infrastructure operations. It runs on UNIX as well as on Windows.

We can define system configuration by using Puppet’s language or Ruby DSL.

The system configuration described in Puppet’s language can be distributed to a target system by using REST API calls.

We use Kubernetes for automation of large-scale deployment of Containerized applications.

It is an open source system based on concepts similar to Google’s deployment process of millions of containers.

It can be used on cloud, on premise datacentre and hybrid infrastructure.

In Kubernetes we can create a cluster of servers that are connected to work as a single unit. We can deploy a containerized application to all the servers in a cluster without specifying the machine name.

We have to package applications in such a way that they do not depend on a specific host.

The architecture of Kubernetes consists of following components:

Master: There is a master node that is responsible for managing the cluster. Master performs following functions in a cluster.

• Scheduling Applications
• Maintaining desired state of application
• Scaling applications
• Applying updates to applications

Nodes: A Node in Kubernetes is responsible for running an application. The Node can be a Virtual Machine or a Computer in the cluster. There is software called Kubelet on each node. This software is used for managing the node and communicating with the Master node in cluster.

There is a Kubernetes API that is used by Nodes to communicate with the Master. When we deploy an application on Kubernetes, we request Master to start application containers on Nodes.

The First Way: Systems Thinking: In this principle we see the DevOps as a flow of work from left to right. This is the time taken from Code check in to the feature being released to End customer. In DevOps culture we try to identify the bottlenecks in this.

The Second Way: Feedback Loops: Whenever there is an issue in production it is a feedback about the whole development and deployment process. We try to make the feedback loop more efficient so that teams can get the feedback much faster. It is a way of catching defect much earlier in process than it being reported by customer.

The Third Way: Continuous Learning: We make use of first and second way principles to keep on making improvements in the overall process. This is the third principle in which over the time we make the process and our operations highly efficient, automated and error free by continuously improving them.

We use following main services of AWS in our environment:

EC2: This is the Elastic Compute Cloud by Amazon. It is used to for providing computing capability to a system. We can use it in places of our standalone servers. We can deploy different kinds of applications on EC2.

S3: We use S3 in Amazon for our storage needs.

DynamoDB: We use DynamoDB in AWS for storing data in NoSQL database form.

Amazon CloudWatch: We use CloudWatch to monitor our application in Cloud.

Amazon SNS: We use Simple Notification Service to inform users about any issues in Production environment.

GIT is a distributed system. In GIT, any person can create its own branch and start checking in the code. Once the code is tested, it is merged into main GIT repo. IN between, Dev, QA and product can validate the implementation of that code.

In CVS, there is a centralized system that maintains all the commits and changes.

GIT is open source software and there are plenty of extensions in GIT for use by our teams.

We need to select an Operating System (OS) to get a specific Virtual Machine (VM). VM provides full OS to an application for running in a virtualized environment.

A Container uses APIs of an Operating System (OS) to provide runtime environment to an application.

A Container is very lightweight in comparison with a VM.

VM provides higher level of security compared to a Container.

A Container just provides the APIs that are required by the application.

REST is also known as Representational State Transfer. A REST service is a simple software functionality that is available over HTTP protocol. It is a lightweight service that is widely available due to the popularity of HTTP protocol.

Sine REST is lightweight; it has very good performance in a software system. It is also one of the foundations for creating highly scalable systems that provide a service to large number of clients.

Another key feature of a REST service is that as long as the interface is kept same, we can change the underlying implementation. E.g. Clients of REST service can keep calling the same service while we change the implementation from php to Java.

Server less Architecture is a term that refers to following:

• An Application that depends on a third-party service.
• An Application in which Code is run on ephemeral containers.

In AWS, Lambda is a popular service to implement Server less architecture.

Another concept in Server less Architecture is to treat code as a service or Function as a Service (FAAS). We just write code that can be run on any environment or server without the need of specifying which server should be used to run this code.

DevOps is different from Technical Operations. It has following main principles:

Incremental: In DevOps we aim to incrementally release software to production. We do releases to production more often than Waterfall approach of one large release.

Automated: To enable use to make releases more often, we automate the operations from Code Check in to deployment in Production.

Collaborative: DevOps is not only responsibility of Operations team. It is a collaborative effort of Dev, QA, Release and DevOps teams.

Iterative: DevOps is based on Iterative principle of using a process that is repeatable. But with each iteration we aim to make the process more efficient and better.

Self-Service: In DevOps, we automate things and give self-service options to other teams so that they are empowered to deliver the work in their domain.

In a Kubernetes cluster, there is a Deployment Controller. This controller monitors the instances created by Kubernetes in a cluster. Once a node or the machine hosting the node goes down, Deployment Controller will replace the node.

It is a self-healing mechanism in Kubernetes to provide high availability of applications.

Therefore, in Kubernetes cluster, Kubernetes Deployment Controller is responsible for starting the instances as well as replacing the instances in case of a failure.

A Deployment Pipeline is an important concept in Continuous Delivery. In Deployment Pipeline we break the build process into distinct stages. In each stage we get the feedback to move onto the next stage.

• It is a collaborative effort between various groups involved in delivering software development.
• Often the first stage in Deployment Pipeline is compiling the code and converting into binaries.
• After that we run the automated tests. Depending on the scenario, there are stages like performance testing, security check, usability testing etc in a Deployment Pipeline.
• In DevOps, our aim is to automate all the stages of Deployment Pipeline. With a smooth-running Deployment Pipeline, we can achieve the goal of Continuous Delivery.

Self-testing Code is an important feature of DevOps culture. In DevOps culture, development team members are expected to write self-testing code. It means we have to write code along with the tests that can test this code. Once the test passes, we feel confident to release the code.

If we get an issue in production, we first write an automation test to validate that the issue happens in current release. Once the issue in release code is fixed, we run the same test to validate that the defect is not there. With each release we keep running these tests so that the issue does not appear anymore.

One of the techniques of writing Self-testing code is Test Driven Development (TDD).

Some of the common use cases of Docker are as follows:

Setting up Development Environment: We can use Docker to set the development environment with the applications on which our code is dependent.

Testing Automation Setup: Docker can also help in creating the Testing Automation setup. We can setup different services and apps with Docker to create the automation-testing environment.

Production Deployment: Docker also helps in implementing the Production deployment for an application. We can use it to create the exact environment and process that will be used for doing the production deployment.

We can use docker rmi command to delete an image from our local system.

Exact command is:

% docker rmi

If we want to find IDs of all the Docker images in our local system, we can user docker images command.

% docker images

If we want to remove a docker container then we use docker rm command.

% docker rm

A Docker Container is a lightweight system that can be run on a Linux operating system or a virtual machine. It is a package of an application and related dependencies that can be run independently.

Since Docker Container is very lightweight, multiple containers can be run simultaneously on a single server or virtual machine.

With a Docker Container we can create an isolated system with restricted services and processes. A Container has private view of the operating system. It has its own process ID space, file system, and network interface.

Multiple Docker Containers can share same Kernel.

There can be any number of heads in a GIT repository.

By default, there is one head known as HEAD in each repository in GIT.

Some of the main security benefits of using a Container based system are as follows:

Segregation: In a Container based system we segregate the applications on different containers. Each application may be running on same host but in a separate container. Each application has access to ports, files and other resources that are provided to it by the container.

Transient: In a Container based system, each application is considered as a transient system. It is better than a static system that has fixed environment which can be exposed overtime.

Control: We use repeatable scripts to create the containers. This provides us tight control over the software application that we want to deploy and run. It also reduces the risk of unwanted changes in setup that can cause security loopholes.

Security Patch: In a Container based system; we can deploy security patches on multiple containers in a uniform way. Also, it is easier to patch a Container with an application update.

Docker Hub provides following main features:

Image Repositories: In Docker Hub we can push, pull, find and manage Docker Images. It is a big library that has images from community, official as well as private sources.

Automated Builds: We can use Docker Hub to create new images by making changes to source code repository of the image.

Webhooks: With Webhooks in Docker Hub we can trigger actions that can create and build new images by pushing a change to repository.

GitHub/Bitbucket integration: Docker Hub also provides integration with GitHub and Bit bucket systems.

A Docker Container has its own file-system. In an application running on Docker Container we can write to this file-system. When the container exits, data written to file-system still remains. When we restart the container, same data can be accessed again.

Only when we delete the container, related data will be deleted.

SSH is a Secure Shell which provides users with a secure, encrypted mechanism to log into systems and transfer files.

To log out a remote machine and work on command line.

To secure encrypted communications between two hosts over an insecure network.