1. What is Infrastructure as Code (IaC) and why is it important?

Question

What is Infrastructure as Code (IaC), and why is it essential in Cloud DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using code
instead of manual processes. It allows automation of resource creation, modification, and deletion in
a cloud environment. IaC helps achieve consistency, reduces human errors, enables version control,
and ensures rapid deployments.

What skills are required to prepare for this question?

●​ Understanding of cloud services (AWS, Azure, GCP)

●​ Knowledge of configuration management tools (Ansible, Chef, Puppet)
●​ Hands-on experience with IaC tools (Terraform, AWS CloudFormation)
●​ Version control knowledge (Git, GitHub, GitLab)
●​ Scripting knowledge (Python, Bash, YAML)

How to study this question?

●​ Read official documentation for Terraform, CloudFormation, or Ansible.

●​ Set up an AWS or GCP account and practice deploying infrastructure using IaC.
●​ Watch IaC tutorials and follow online courses (e.g., Udemy, Coursera).
●​ Work on GitHub projects related to IaC and analyze existing code.
●​ Practice writing Terraform or CloudFormation scripts and deploy resources.

Examples for this question

●​ Using Terraform to deploy an EC2 instance in AWS:

Unset
provider "aws" {
region = "us-west-2"
}

resource "aws_instance" "example" {

ami = "ami-0abcdef1234567890"
instance_type = "t2.micro"
}

●​ Writing an Ansible playbook to configure a web server:

 Unset
- name: Install and start Apache
hosts: web_servers
tasks:
- name: Install Apache
apt:
name: apache2
state: present

- name: Start Apache

service:
name: apache2
state: started

2. What is CI/CD, and how does it benefit DevOps?

Question

What is Continuous Integration/Continuous Deployment (CI/CD), and why is it important for DevOps?

Answer

CI/CD is a DevOps practice that automates software delivery through continuous integration,
continuous testing, and continuous deployment.

●​ Continuous Integration (CI) ensures code changes are merged and tested frequently.
●​ Continuous Deployment (CD) automates deployment to production after passing tests.
●​ Benefits include faster releases, fewer manual errors, consistent deployments, and improved
software quality.

What skills are required to prepare for this question?

●​ Understanding of CI/CD concepts and pipeline stages

●​ Hands-on experience with CI/CD tools (Jenkins, GitHub Actions, GitLab CI/CD, CircleCI)
●​ Scripting knowledge (Bash, Python)
●​ Knowledge of containerization (Docker, Kubernetes)
●​ Understanding of cloud-based CI/CD (AWS CodePipeline, Azure DevOps)

How to study this question?

●​ Learn how CI/CD works by reading blogs, watching YouTube tutorials, and taking DevOps
courses.
●​ Set up a Jenkins CI/CD pipeline locally or on AWS/GCP.
●​ Explore GitHub Actions and create workflows to automate testing and deployment.
●​ Work on open-source projects using Git and implement CI/CD pipelines.
Examples for this question

●​ Jenkins Pipeline Script for CI/CD:

Unset
pipeline {
agent any
stages {
stage('Build') {
steps {
sh 'mvn clean package'
}
}
stage('Test') {
steps {
sh 'mvn test'
}
}
stage('Deploy') {
steps {
sh 'scp target/myapp.jar user@server:/opt/app/'
}
}
}
}

●​ GitHub Actions Workflow for CI/CD:

Unset
name: CI/CD Pipeline
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Build application
run: mvn clean package
- name: Run tests
run: mvn test
3. What is the difference between Docker and Kubernetes?
Question

What is the difference between Docker and Kubernetes, and how do they complement each other?

Answer

Docker is a containerization platform that allows developers to package applications with all
dependencies into a container, ensuring consistency across environments.

Kubernetes is an orchestration tool that manages containerized applications at scale by handling

deployment, scaling, networking, and health monitoring.

Key Differences:

Feature Docker Kubernetes

Purpose Containerization Container orchestration

Scope Runs single containers Manages multiple containers

Networking Basic networking Advanced networking & service discovery

Scaling Manual scaling Auto-scaling of containers

Storage Limited support Persistent volumes & storage

management

How they complement each other:​

Docker creates and runs containers, while Kubernetes manages them in a production environment,
automating deployment, scaling, and monitoring.

What skills are required to prepare for this question?

●​ Understanding of containerization and microservices

●​ Hands-on experience with Docker (Docker CLI, Docker Compose)
 ●​ Knowledge of Kubernetes architecture (Pods, Deployments, Services)
●​ Understanding of networking and storage in Kubernetes
●​ Experience with cloud-based container services (AWS EKS, Azure AKS, GCP GKE)

How to study this question?

●​ Read Docker and Kubernetes documentation.

●​ Set up a local Kubernetes cluster using Minikube or Kind.
●​ Work with Docker Compose to run multi-container applications.
●​ Deploy a simple containerized app to Kubernetes and expose it via a service.
●​ Watch Kubernetes tutorials on platforms like KodeKloud, Udemy, or YouTube.

Examples for this question

●​ Dockerfile to containerize a Node.js app:

Unset
FROM node:14

WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

CMD ["node", "server.js"]

EXPOSE 3000

●​ Kubernetes deployment for the same Node.js app:

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: node-app

spec:

replicas: 2
 selector:

matchLabels:

app: node-app

template:

metadata:

labels:

app: node-app

spec:

containers:

- name: node-container

image: my-node-app:latest

ports:

- containerPort: 3000

4. What are the different types of Kubernetes services?

Question

What are the different types of Kubernetes services, and when should you use each?

Answer

Kubernetes services provide networking and connectivity to pods. There are four main types:

1.​ ClusterIP (Default) – Exposes the service only within the cluster. Used for internal
communication.
2.​ NodePort – Exposes the service on a static port on each node, making it accessible externally.
3.​ LoadBalancer – Creates an external load balancer (in cloud environments) to distribute traffic
to pods.
4.​ ExternalName – Maps a service to an external DNS name, without proxying traffic through
Kubernetes.
What skills are required to prepare for this question?

●​ Knowledge of Kubernetes networking concepts

●​ Hands-on experience with Kubernetes services (kubectl, YAML configurations)
●​ Understanding of cloud networking (AWS ELB, Azure Load Balancer, GCP Load Balancer)
●​ Experience deploying applications in Kubernetes clusters

How to study this question?

●​ Read Kubernetes documentation on services.

●​ Deploy sample applications and expose them using different service types.
●​ Experiment with Minikube or Kind to test different services.
●​ Work with cloud-based Kubernetes clusters (EKS, AKS, GKE) to understand LoadBalancer
services.

Examples for this question

●​ ClusterIP service for internal communication:

Unset
apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

selector:

app: my-app

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ NodePort service for external access:

 Unset
apiVersion: v1

kind: Service

metadata:

name: my-service

spec:

type: NodePort

selector:

app: my-app

ports:

- port: 80

targetPort: 8080

nodePort: 30000

5. What is the difference between Monolithic and Microservices Architecture?

Question

What is the difference between Monolithic and Microservices Architecture, and why is Microservices
preferred in DevOps?

Answer

Monolithic and Microservices architectures are two approaches to designing applications.

Feature Monolithic Architecture Microservices Architecture

 Structure Single codebase with tightly Small, independent services
coupled components communicating via APIs

Scalability Harder to scale as a whole Easily scalable per microservice

Deployment Entire application must be Each microservice can be deployed

redeployed independently

Flexibility Limited technology choice Each microservice can use different

technologies

Fault A failure can crash the whole app A failure in one service does not
Isolation affect others

Why Microservices in DevOps?

●​ Faster deployments and better CI/CD automation

●​ Independent scaling and development teams
●​ Easier integration with cloud services and Kubernetes
●​ Improved fault tolerance and system resilience

What skills are required to prepare for this question?

●​ Understanding of software architecture concepts

●​ Knowledge of microservices frameworks (Spring Boot, Express.js, Django, etc.)
●​ Experience with API communication (REST, gRPC, GraphQL)
●​ Hands-on experience with containers (Docker) and orchestration (Kubernetes)
●​ Familiarity with service discovery tools (Consul, Istio)

How to study this question?

●​ Read architectural guides on Monolithic vs. Microservices patterns.

●​ Practice breaking down a monolithic application into microservices.
●​ Deploy microservices using Kubernetes or Docker Compose.
●​ Study how cloud platforms support microservices (AWS Lambda, Azure Functions).
●​ Explore real-world case studies of companies migrating to microservices.

Examples for this question

●​ Monolithic Node.js app (all components in one file):

JavaScript
const express = require('express');

const app = express();

app.get('/users', (req, res) => {

res.send([{ id: 1, name: 'John Doe' }]);

});

app.get('/orders', (req, res) => {

res.send([{ id: 101, item: 'Laptop' }]);

});

app.listen(3000, () => console.log('Monolithic App Running on Port

3000'));

●​ Microservices approach (Separate services for users and orders):

○​ User Service (user-service.js)

JavaScript
const express = require('express');

const app = express();

app.get('/users', (req, res) => {

res.send([{ id: 1, name: 'John Doe' }]);

});
 app.listen(4000, () => console.log('User Service Running on Port
4000'));

○​ Order Service (order-service.js)

JavaScript
const express = require('express');

const app = express();

app.get('/orders', (req, res) => {

res.send([{ id: 101, item: 'Laptop' }]);

});

app.listen(5000, () => console.log('Order Service Running on Port

5000'));

6. What is GitOps and how does it improve DevOps workflows?

Question

What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps practice that uses Git as a single source of truth for managing infrastructure and
applications. It automates deployments using Git repositories and CI/CD pipelines.

How GitOps improves DevOps workflows:

●​ Version Control: Every infrastructure change is stored in Git, ensuring history tracking.
●​ Automation: Changes are automatically applied when pushed to Git.
●​ Consistency: Ensures that the actual infrastructure matches the desired state.
●​ Rollback & Recovery: Easy rollback to previous versions if issues arise.
●​ Security & Auditability: Every change is reviewed via pull requests before deployment.
What skills are required to prepare for this question?

●​ Git and GitHub/GitLab workflows

●​ CI/CD automation (ArgoCD, Flux, Jenkins, GitHub Actions)
●​ Infrastructure as Code (Terraform, Helm, Kubernetes)
●​ Experience with Kubernetes and cloud platforms
●​ Monitoring and alerting (Prometheus, Grafana)

How to study this question?

●​ Read documentation on GitOps tools like ArgoCD and Flux.

●​ Watch YouTube tutorials on setting up GitOps in Kubernetes.
●​ Create a Git repository for managing Kubernetes manifests.
●​ Deploy a simple application using GitOps workflows.
●​ Explore case studies of companies implementing GitOps.

Examples for this question

●​ GitOps workflow using ArgoCD and Kubernetes:

○​ 1. Store Kubernetes manifests in Git:

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: my-app

spec:

replicas: 3

selector:

matchLabels:

app: my-app

template:

metadata:

labels:

app: my-app
 spec:

containers:

- name: my-app

image: my-docker-repo/my-app:v1

○​ 2. ArgoCD automatically syncs and applies changes:

Unset
argocd app create my-app --repo https://github.com/user/repo.git --path
./k8s --dest-server https://kubernetes.default.svc --dest-namespace
default

○​ 3. Update the application by pushing changes to Git, triggering automatic

deployment.

7. What is the Shared Responsibility Model in Cloud Computing?

Question

What is the Shared Responsibility Model in cloud computing, and how does it impact security
management?

Answer

The Shared Responsibility Model defines the security responsibilities of cloud providers and
customers.

Responsibility Cloud Provider Customer

Infrastructure Manages physical security, N/A

Security networking, and data centers
 OS & Platform Manages underlying OS and Manages OS and software (for
Management software (for PaaS & SaaS) IaaS)

Application Security Provides secure cloud services Configures security settings and
protects applications

Data Protection Offers encryption and backup Responsible for securing and
tools managing access to data

Impact on security management:

●​ Customers must secure applications, data, and user access.

●​ Cloud providers ensure infrastructure and service security.
●​ Different cloud models (IaaS, PaaS, SaaS) have different levels of customer responsibility.

What skills are required to prepare for this question?

●​ Understanding of cloud security concepts

●​ Familiarity with AWS, Azure, or GCP security best practices
●​ Knowledge of identity & access management (IAM)
●​ Experience with encryption and compliance frameworks (SOC 2, GDPR, HIPAA)

How to study this question?

●​ Read cloud provider documentation on security responsibilities (AWS, Azure, GCP).

●​ Take cloud security courses on Udemy, Coursera, or AWS Training.
●​ Work with IAM policies and security groups in AWS or Azure.
●​ Explore security case studies and incidents to understand real-world applications.

Examples for this question

●​ AWS Shared Responsibility Model:

○​ AWS is responsible for: Physical security, compute infrastructure, storage security,
networking.
○​ Customer is responsible for: Data encryption, access controls, OS patches (for EC2),
IAM policies.
●​ Example AWS IAM policy restricting S3 access:

Unset
{

"Version": "2012-10-17",
 "Statement": [

"Effect": "Deny",

"Principal": "*",

"Action": "s3:*",

"Resource": "arn:aws:s3:::sensitive-data/*"

8. What is Blue-Green Deployment, and how does it improve release management?

Question

What is Blue-Green Deployment, and how does it help in release management?

Answer

Blue-Green Deployment is a release strategy where two identical environments (Blue & Green) exist:

●​ Blue (Current Live Environment): Running the existing stable version.

●​ Green (New Environment): Deploys the new application version.

Deployment Process:

1.​ Deploy the new version to the Green environment.

2.​ Test Green to ensure it works correctly.
3.​ Switch traffic from Blue to Green (instant rollback possible).
4.​ Blue remains idle and can be used for rollback if issues arise.

Advantages:

●​ Zero downtime deployments.

●​ Instant rollback in case of failure.
●​ Reduces risks of deploying new changes.
●​ Improves testing before making changes live.
What skills are required to prepare for this question?

●​ Knowledge of CI/CD pipelines

●​ Experience with cloud-based deployments (AWS Elastic Beanstalk, Kubernetes, Azure App
Services)
●​ Familiarity with load balancers and traffic routing
●​ Hands-on experience with deployment strategies (Rolling Updates, Canary Releases)

How to study this question?

●​ Read cloud documentation on Blue-Green Deployments (AWS, Azure, GCP).

●​ Watch DevOps deployment strategy tutorials on YouTube.
●​ Set up a Blue-Green deployment using Kubernetes or AWS Elastic Load Balancer.
●​ Experiment with CI/CD tools like Jenkins, GitHub Actions, and AWS CodeDeploy.

Examples for this question

●​ Blue-Green Deployment using AWS Elastic Beanstalk:

Unset
aws elasticbeanstalk swap-environment-cnames --source-environment-name
blue-env --destination-environment-name green-env

●​ Blue-Green Deployment with Kubernetes (Traffic shifting example):

Unset
apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: blue-green-ingress

spec:

rules:

- host: myapp.com

http:

paths:

- path: /
 backend:

service:

name: green-service

port:

number: 80

9. What is Infrastructure as Code (IaC), and how does it benefit DevOps?

Question

What is Infrastructure as Code (IaC), and how does it benefit DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure (servers,
networks, databases) using code instead of manual processes. IaC tools automate infrastructure
deployment, ensuring consistency and repeatability.

Benefits of IaC in DevOps:

●​ Automation: Eliminates manual configurations, reducing human errors.

●​ Consistency: Ensures that all environments (dev, test, prod) are identical.
●​ Scalability: Enables quick infrastructure provisioning and scaling.
●​ Version Control: Infrastructure changes are tracked and audited in Git.
●​ Faster Deployments: Reduces setup time with automated scripts.

What skills are required to prepare for this question?

●​ Knowledge of IaC tools (Terraform, AWS CloudFormation, Ansible, Pulumi)

●​ Experience with cloud infrastructure (AWS, Azure, GCP)
●​ Understanding of CI/CD pipelines for infrastructure automation
●​ Hands-on experience writing and deploying IaC scripts

How to study this question?

●​ Read Terraform, CloudFormation, or Ansible documentation.

●​ Set up and deploy infrastructure using Terraform.
●​ Watch IaC tutorials on YouTube and take online courses.
●​ Work with real-world cloud projects to gain hands-on experience.
Examples for this question

●​ Terraform script to create an AWS EC2 instance:

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "web" {

ami = "ami-0c55b159cbfafe1f0"

instance_type = "t2.micro"

tags = {

Name = "WebServer"

●​ Ansible playbook to install Nginx on a server:

Unset
- name: Install Nginx

hosts: webservers

tasks:

- name: Install Nginx

apt:

name: nginx

state: present
10. What is Continuous Integration and Continuous Deployment (CI/CD) in DevOps?
Question

What is Continuous Integration and Continuous Deployment (CI/CD), and why is it important in
DevOps?

Answer

CI/CD is a DevOps practice that automates software integration, testing, and deployment.

●​ Continuous Integration (CI): Developers frequently merge code into a shared repository,
triggering automated builds and tests.
●​ Continuous Deployment (CD): Code changes are automatically deployed to production if tests
pass, ensuring faster releases.

Why CI/CD is important in DevOps?

●​ Automates build, test, and deployment processes.

●​ Reduces manual errors and improves software quality.
●​ Enables faster feedback loops and rapid software releases.
●​ Supports rollback mechanisms for safer deployments.

What skills are required to prepare for this question?

●​ Experience with CI/CD tools (Jenkins, GitHub Actions, GitLab CI, CircleCI)
●​ Knowledge of Docker and Kubernetes for containerized deployments
●​ Understanding of source control (Git, branching strategies)
●​ Familiarity with automated testing frameworks (Selenium, JUnit)

How to study this question?

●​ Read CI/CD documentation from Jenkins, GitHub Actions, or GitLab CI.

●​ Set up a simple CI/CD pipeline using Jenkins or GitHub Actions.
●​ Deploy a containerized app with Kubernetes and integrate it into a CI/CD workflow.
●​ Study real-world CI/CD case studies to understand best practices.

Examples for this question

●​ GitHub Actions CI/CD pipeline for a Node.js app:

Unset
name: CI/CD Pipeline

on:
 push:

branches:

- main

jobs:

build:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v2

- name: Install dependencies

run: npm install

- name: Run tests

run: npm test

●​ Jenkins pipeline script for CI/CD:

Unset
pipeline {

agent any

stages {

stage('Build') {

steps {

sh 'npm install'

}
 stage('Test') {

steps {

sh 'npm test'

stage('Deploy') {

steps {

sh 'echo Deploying to production...'

11. What is Containerization, and how does it differ from Virtualization?

Question

What is containerization, and how does it differ from virtualization?

Answer

Containerization is a lightweight virtualization technology that packages applications and their

dependencies into isolated environments called containers. Unlike traditional virtual machines (VMs),
containers share the host OS kernel but remain independent from each other.

Feature Containers (Docker) Virtual Machines (VMs)

 Isolation Process-level isolation Full OS isolation

Startup Time Fast (seconds) Slow (minutes)

Resource Usage Lightweight, shares OS kernel Heavy, each VM has its own OS

Portability Easily portable across Less portable, OS-dependent

environments

Scalability Highly scalable and dynamic More resource-intensive

Why use Containers in DevOps?

●​ Faster deployment and consistent environments.

●​ Lightweight compared to VMs.
●​ Supports microservices architecture.
●​ Compatible with orchestration tools like Kubernetes.

What skills are required to prepare for this question?

●​ Understanding of Docker and container fundamentals.

●​ Knowledge of virtualization technologies (VMware, Hyper-V).
●​ Experience with container orchestration tools (Kubernetes).
●​ Hands-on experience with Dockerfile and container networking.

How to study this question?

●​ Read Docker and Kubernetes documentation.

●​ Practice building and running Docker containers.
●​ Compare performance differences between containers and VMs.
●​ Deploy a multi-container application using Docker Compose.

Examples for this question

●​ Basic Dockerfile for a Node.js app:

Unset
FROM node:14
 WORKDIR /app

COPY package.json .

RUN npm install

COPY . .

CMD ["node", "server.js"]

EXPOSE 3000

●​ Run a container from an image:

Unset
docker build -t my-node-app .

docker run -p 3000:3000 my-node-app

●​ Virtualization example (Creating a VM using VirtualBox CLI):

Unset
VBoxManage createvm --name "UbuntuVM" --register

VBoxManage modifyvm "UbuntuVM" --memory 2048 --cpus 2

12. What is Kubernetes, and why is it important in DevOps?

Question

What is Kubernetes, and why is it important in DevOps?

Answer

Kubernetes (K8s) is an open-source container orchestration platform that automates deployment,

scaling, and management of containerized applications.

Why is Kubernetes important in DevOps?

●​ Automated Scaling: Scales containers based on demand.

 ●​ Self-healing: Restarts failed containers automatically.
●​ Load Balancing: Distributes traffic efficiently.
●​ Declarative Configuration: Uses YAML files for infrastructure management.
●​ Works with CI/CD: Integrates with DevOps pipelines for seamless deployments.

What skills are required to prepare for this question?

●​ Understanding of Kubernetes components (Pods, Nodes, Services, Deployments).

●​ Experience with kubectl commands and YAML configurations.
●​ Knowledge of containerization (Docker) and networking.
●​ Familiarity with Helm charts and Kubernetes monitoring tools.

How to study this question?

●​ Read Kubernetes documentation and tutorials.

●​ Practice deploying applications on Kubernetes.
●​ Set up Minikube or a cloud Kubernetes cluster (AWS EKS, Azure AKS, GCP GKE).
●​ Learn about Kubernetes security and troubleshooting.

Examples for this question

●​ Kubernetes Deployment YAML for a web app:

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: my-app

spec:

replicas: 3

selector:

matchLabels:

app: my-app

template:

metadata:

labels:
 app: my-app

spec:

containers:

- name: my-app

image: my-app-image:latest

ports:

- containerPort: 80

●​ Kubernetes command to deploy the application:

Unset
kubectl apply -f deployment.yaml

●​ Scaling up the deployment:

Unset
kubectl scale deployment my-app --replicas=5

13. What is a Service Mesh, and how does it help in Microservices?

Question

What is a Service Mesh, and how does it help in managing microservices?

Answer

A Service Mesh is a dedicated infrastructure layer that handles communication between

microservices in a distributed system. It provides advanced networking capabilities like traffic
control, security, and observability.

Key features of a Service Mesh:

●​ Traffic Management: Load balancing, retries, and circuit breaking.

●​ Security: Mutual TLS (mTLS) encryption and authentication between services.
 ●​ Observability: Tracing, logging, and monitoring service interactions.
●​ Service Discovery: Automatically finds and routes requests to services.

Why is a Service Mesh important in DevOps?

●​ Improves reliability and performance of microservices.

●​ Reduces operational complexity by managing communication centrally.
●​ Enhances security through encryption and authentication.
●​ Works well with Kubernetes for managing large-scale deployments.

What skills are required to prepare for this question?

●​ Understanding of microservices and API communication.

●​ Experience with Kubernetes networking concepts.
●​ Knowledge of service mesh tools (Istio, Linkerd, Consul).
●​ Familiarity with monitoring and tracing tools (Prometheus, Grafana, Jaeger).

How to study this question?

●​ Read documentation on Istio, Linkerd, and Consul service meshes.

●​ Deploy a simple microservices architecture with a service mesh.
●​ Study case studies on how companies use service meshes in production.
●​ Set up tracing with Jaeger or distributed logging with Fluentd.

Examples for this question

●​ Deploy Istio on a Kubernetes cluster:

Unset
istioctl install --set profile=demo -y

●​ Apply an Istio service mesh configuration to a microservice:

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: my-service

spec:

hosts:
 - my-service

http:

- route:

- destination:

host: my-service

subset: v1

●​ Enable mutual TLS encryption in Istio:

Unset
apiVersion: security.istio.io/v1beta1

kind: PeerAuthentication

metadata:

name: default

spec:

mtls:

mode: STRICT

14. What is Canary Deployment, and how does it minimize deployment risks?
Question

What is Canary Deployment, and how does it help reduce risks in software releases?

Answer

Canary Deployment is a DevOps strategy where a new version of an application is gradually rolled out
to a small subset of users before a full release.

How Canary Deployment Works:

 1.​ Deploy a new version (canary) alongside the stable version.
2.​ Route a small percentage of traffic to the canary version.
3.​ Monitor performance and error rates.
4.​ If stable, increase traffic gradually until 100% rollout.
5.​ If issues arise, rollback to the previous version.

Why Canary Deployment is useful in DevOps?

●​ Reduces the risk of full-scale failures.

●​ Allows monitoring real-world performance before full rollout.
●​ Provides an easy rollback mechanism.
●​ Works well with Kubernetes, cloud services, and feature flagging.

What skills are required to prepare for this question?

●​ Experience with CI/CD and deployment strategies.

●​ Knowledge of traffic routing (NGINX, Kubernetes Ingress, AWS ALB).
●​ Familiarity with observability tools (Datadog, Prometheus, New Relic).
●​ Hands-on experience with cloud-based canary deployment services (AWS CodeDeploy, Istio,
Argo Rollouts).

How to study this question?

●​ Read about Canary Deployment in Kubernetes and AWS CodeDeploy.

●​ Set up a simple canary deployment using Istio or Argo Rollouts.
●​ Analyze real-world cases where canary releases prevented failures.
●​ Practice rollback strategies in a cloud environment.

Examples for this question

●​ Kubernetes Canary Deployment using Istio:

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: my-service

spec:

hosts:

- my-service

http:
 - route:

- destination:

host: my-service

subset: stable

weight: 90

- destination:

host: my-service

subset: canary

weight: 10

●​ Route traffic dynamically using AWS ALB and CodeDeploy:

Unset
aws deploy create-deployment \

--application-name MyApp \

--deployment-group-name CanaryDeploymentGroup \

--revision location={S3Bucket="my-bucket",S3Key="my-app.zip"} \

--deployment-config-name CodeDeployDefault.OneAtATime

●​ Using feature flags for canary releases in a Node.js app:

JavaScript
const featureFlag = process.env.FEATURE_FLAG === 'true';

app.get('/feature', (req, res) => {

if (featureFlag) {
 res.send('New feature enabled!');

} else {

res.send('Old version');

});

15. What is Blue-Green Deployment, and how does it ensure zero downtime?
Question

What is Blue-Green Deployment, and how does it ensure zero downtime during releases?

Answer

Blue-Green Deployment is a DevOps deployment strategy that runs two identical production
environments—Blue (current/live version) and Green (new version).

How Blue-Green Deployment Works:

1.​ The Blue environment (current version) is serving live traffic.

2.​ The Green environment (new version) is deployed but not yet receiving traffic.
3.​ Traffic is gradually switched from Blue to Green once the new version is tested.
4.​ If issues occur, traffic is quickly reverted to Blue for instant rollback.

Why Blue-Green Deployment is useful in DevOps?

●​ Ensures zero downtime during deployments.

●​ Allows easy rollback in case of failures.
●​ Reduces risks by testing in production-like conditions.
●​ Works well with containerized applications and cloud environments.

What skills are required to prepare for this question?

●​ Experience with deployment strategies and CI/CD pipelines.

●​ Understanding of traffic routing (Load Balancers, DNS switching).
●​ Familiarity with cloud-based deployment tools (AWS CodeDeploy, Kubernetes, Nginx, Istio).
●​ Hands-on experience setting up Blue-Green Deployments in Kubernetes or cloud platforms.

How to study this question?

●​ Read about Blue-Green Deployment in AWS, Kubernetes, and CI/CD.

 ●​ Implement a Blue-Green strategy using Nginx or AWS ALB.
●​ Work with Kubernetes services to route traffic between versions.
●​ Analyze real-world cases of companies using Blue-Green Deployments.

Examples for this question

●​ Using Kubernetes Services for Blue-Green Deployment:

Unset
apiVersion: v1

kind: Service

metadata:

name: my-app

spec:

selector:

app: my-app-blue # Initially routing to Blue

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ To switch to Green:

Unset
apiVersion: v1

kind: Service

metadata:

name: my-app

spec:

selector:
 app: my-app-green # Now routing to Green

●​ Blue-Green Deployment using AWS CodeDeploy:

Unset
aws deploy create-deployment \

--application-name MyApp \

--deployment-group-name BlueGreenGroup \

--revision location={S3Bucket="my-bucket",S3Key="app.zip"} \

--deployment-config-name CodeDeployDefault.BlueGreen

●​ Nginx Configuration for Blue-Green Traffic Routing:

Unset
upstream blue {

server blue-app:8080;

upstream green {

server green-app:8080;

server {

listen 80;

location / {

proxy_pass http://blue; # Change to 'green' when switching

versions

}
 }

16. What is GitOps, and how does it improve DevOps workflows?

Question

What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps approach where Git is the single source of truth for infrastructure and
application deployments. It automates provisioning and updates by applying Git-based version control
principles to infrastructure management.

Key principles of GitOps:

●​ Declarative Configuration: Uses YAML/JSON files for defining infrastructure and applications.
●​ Version Control: All changes are tracked in Git, ensuring traceability.
●​ Automated Deployments: Continuous deployment is triggered by Git commits.
●​ Self-Healing Systems: Drift detection ensures environments match Git state.

Why GitOps is important in DevOps?

●​ Improves deployment consistency and reduces manual errors.

●​ Provides auditability and rollback capabilities using Git history.
●​ Enhances collaboration between DevOps and developers.
●​ Works well with Kubernetes and cloud-native environments.

What skills are required to prepare for this question?

●​ Strong knowledge of Git workflows (branching, merging, PRs).

●​ Experience with Infrastructure as Code (IaC) tools like Terraform or Helm.
●​ Hands-on experience with GitOps tools (ArgoCD, Flux, Jenkins X).
●​ Understanding of Kubernetes CI/CD pipelines.

How to study this question?

●​ Read documentation on GitOps best practices.

●​ Set up a GitOps pipeline using ArgoCD or Flux.
●​ Deploy applications using Git-based automation.
●​ Analyze real-world case studies of GitOps adoption.

Examples for this question

●​ GitOps workflow using ArgoCD:​

1.​ Define a Kubernetes Deployment in Git:

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: my-app

spec:

replicas: 2

selector:

matchLabels:

app: my-app

template:

metadata:

labels:

app: my-app

spec:

containers:

- name: my-app

image: my-app:v1.0

2.​ Use ArgoCD to apply changes from Git automatically:

Unset
argocd app create my-app \
 --repo https://github.com/my-org/my-repo.git \

--path k8s \

--dest-server https://kubernetes.default.svc \

--dest-namespace default

3.​ Any updates committed to Git (e.g., changing the image version) trigger automatic
deployments.
●​ Using Flux to sync Kubernetes with Git:​

Unset
flux bootstrap github \

--owner=my-org \

--repository=my-repo \

--branch=main \

--path=./clusters/my-cluster

17. What is Infrastructure as Code (IaC), and why is it important in DevOps?

Question

What is Infrastructure as Code (IaC), and why is it important in DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using
machine-readable configuration files instead of manual processes. IaC enables automation,
consistency, and scalability in DevOps.

Key benefits of IaC:

●​ Automation: Reduces manual work by automating provisioning.

●​ Consistency: Prevents configuration drift by enforcing standardized infrastructure.
 ●​ Version Control: Tracks infrastructure changes using Git.
●​ Scalability: Easily scales infrastructure using code templates.
●​ Faster Deployments: Reduces the time required to provision environments.

Popular IaC Tools:

●​ Terraform (cloud-agnostic)
●​ AWS CloudFormation (AWS-specific)
●​ Ansible (configuration management)
●​ Pulumi (code-based IaC with Python, TypeScript, etc.)

What skills are required to prepare for this question?

●​ Understanding of cloud platforms (AWS, Azure, GCP).

●​ Hands-on experience with Terraform, CloudFormation, or Ansible.
●​ Knowledge of YAML/JSON for defining infrastructure.
●​ Experience with Git and CI/CD pipelines.

How to study this question?

●​ Read Terraform and CloudFormation documentation.

●​ Practice writing Terraform scripts to deploy cloud infrastructure.
●​ Experiment with Ansible playbooks for configuration management.
●​ Set up a Git-based IaC workflow.

Examples for this question

●​ Terraform script to provision an AWS EC2 instance:

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "web" {

ami = "ami-12345678"

instance_type = "t2.micro"

tags = {
 Name = "MyServer"

●​ Run Terraform commands:

Unset
terraform init

terraform apply

●​ Ansible Playbook to install Nginx on a server:

Unset
- name: Install Nginx

hosts: webserver

tasks:

- name: Install Nginx

apt:

name: nginx

state: present

●​ Run the playbook:

Unset
ansible-playbook nginx.yml

●​ AWS CloudFormation template to create an S3 bucket:

 Unset
Resources:

MyS3Bucket:

Type: AWS::S3::Bucket

Properties:

BucketName: my-unique-bucket-name

18. What is Immutable Infrastructure, and how does it benefit DevOps?

Question

What is Immutable Infrastructure, and how does it benefit DevOps?

Answer

Immutable Infrastructure is a DevOps practice where servers and infrastructure components are
never modified after deployment. Instead of updating an existing system, a new one is created, and
the old one is decommissioned.

Why use Immutable Infrastructure?

●​ Eliminates Configuration Drift: No unexpected changes over time.

●​ Ensures Consistency: Every deployment is identical and tested.
●​ Improves Security: Reduces risk of unpatched systems.
●​ Enhances Rollbacks: Quickly revert to a previous version if needed.

Common Immutable Infrastructure Tools:

●​ Docker (for containerized applications)

●​ Packer (to create immutable VM images)
●​ Kubernetes (to manage immutable deployments)
●​ Terraform (to provision immutable infrastructure)

What skills are required to prepare for this question?

●​ Understanding of immutable infrastructure concepts.

●​ Experience with containerization (Docker, Kubernetes).
●​ Knowledge of Packer for building VM images.
●​ Hands-on experience with Terraform or CloudFormation.

How to study this question?

 ●​ Read about immutable infrastructure best practices.
●​ Create immutable server images using Packer.
●​ Deploy immutable containers using Kubernetes.
●​ Test rolling updates and rollback strategies.

Examples for this question

●​ Using Packer to create an immutable AWS AMI:

Unset
{

"builders": [{

"type": "amazon-ebs",

"region": "us-east-1",

"source_ami": "ami-12345678",

"instance_type": "t2.micro",

"ssh_username": "ec2-user",

"ami_name": "my-immutable-image"

}]

●​ Build the AMI:

Unset
packer build template.json

●​ Deploying an immutable container with Kubernetes:

Unset
apiVersion: apps/v1

kind: Deployment

metadata:
 name: my-app

spec:

replicas: 3

selector:

matchLabels:

app: my-app

template:

metadata:

labels:

app: my-app

spec:

containers:

- name: my-app

image: my-app:v1.0 # Never modify in place, always update

the version

ports:

- containerPort: 80

●​ Rolling update strategy in Kubernetes for immutability:

Unset
kubectl set image deployment/my-app my-app=my-app:v1.1

19. What is Chaos Engineering, and why is it important in DevOps?

Question

What is Chaos Engineering, and why is it important in DevOps?

Answer

Chaos Engineering is the practice of intentionally introducing failures in a system to test its
resilience and ability to recover. It helps teams proactively identify weaknesses before they cause
real outages.

Why Chaos Engineering is important in DevOps?

●​ Helps teams understand system behavior under failure conditions.

●​ Identifies weak points before they cause major disruptions.
●​ Improves system reliability and incident response preparedness.
●​ Supports high availability and fault tolerance in distributed systems.

Common Chaos Engineering Tools:

●​ Chaos Monkey (Netflix) – Randomly shuts down instances.

●​ Gremlin – Injects various types of failures.
●​ LitmusChaos – Kubernetes-native chaos testing.
●​ AWS Fault Injection Simulator – Cloud-based chaos testing.

What skills are required to prepare for this question?

●​ Understanding of distributed systems and microservices.

●​ Experience with Kubernetes and cloud infrastructure.
●​ Knowledge of resilience patterns (circuit breakers, retries, failover).
●​ Hands-on experience with Chaos Engineering tools (Gremlin, LitmusChaos).

How to study this question?

●​ Read Principles of Chaos Engineering from Netflix’s Chaos Engineering team.

●​ Experiment with Gremlin or LitmusChaos to inject failures.
●​ Simulate real-world outages in Kubernetes or AWS.
●​ Study post-mortems of real incidents (AWS, Google, Netflix).

Examples for this question

●​ Using Gremlin to simulate CPU stress on a server:

Unset
gremlin attack cpu --cores 2 --length 60

●​ Injecting a pod failure in Kubernetes using LitmusChaos:

Unset
apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

name: pod-delete-experiment

spec:

appinfo:

appns: "default"

applabel: "app=my-app"

experiments:

- name: pod-delete

spec:

components:

env:

- name: TOTAL_CHAOS_DURATION

value: "60" # 60 seconds

●​ Apply the chaos experiment:

Unset
kubectl apply -f chaos-experiment.yaml

●​ Using AWS Fault Injection Simulator to introduce latency:

Unset
aws fis start-experiment --experiment-template-id my-template-id
20. What is a Feature Flag, and how does it help in DevOps?
Question

What is a Feature Flag, and how does it help in DevOps?

Answer

A Feature Flag (or Feature Toggle) is a technique used to enable or disable features in an
application without deploying new code. It allows controlled feature rollouts and experimentation.

Why Feature Flags are useful in DevOps?

●​ Safe Rollouts: Gradually release new features to a subset of users.

●​ Instant Rollback: Disable a faulty feature instantly without redeploying.
●​ A/B Testing: Experiment with different versions of a feature.
●​ Continuous Deployment: Deploy incomplete features without exposing them.

Feature Flagging Tools:

●​ LaunchDarkly – Cloud-based feature flagging.

●​ Unleash – Open-source feature flagging.
●​ Flagsmith – Self-hosted or cloud feature management.
●​ Flipt – Lightweight feature flag management.

What skills are required to prepare for this question?

●​ Understanding of feature toggle strategies.

●​ Experience with CI/CD pipelines for controlled rollouts.
●​ Knowledge of A/B testing and canary deployments.
●​ Hands-on experience with feature flagging tools (LaunchDarkly, Unleash).

How to study this question?

●​ Read about Feature Flagging best practices.

●​ Implement feature flags in a CI/CD pipeline.
●​ Study real-world cases (Netflix, Facebook, Google use feature flags extensively).
●​ Experiment with LaunchDarkly or Unleash for feature rollouts.

Examples for this question

●​ Using a feature flag in a Node.js application:

JavaScript
const featureFlag = process.env.NEW_FEATURE === 'true';
app.get('/new-feature', (req, res) => {

if (featureFlag) {

res.send('New feature is enabled!');

} else {

res.send('This feature is not available yet.');

});

●​ Feature flag configuration in Unleash (JSON format):

Unset
{

"version": 1,

"features": [

"name": "new-feature",

"enabled": true,

"strategies": [

"name": "gradualRollout",

"parameters": {

"percentage": "50"

}
 ]

●​ Using LaunchDarkly SDK in Python:

Python
import ldclient

from ldclient.config import Config

ldclient.set_config(Config("YOUR_SDK_KEY"))

client = ldclient.get()

user = {"key": "user123"}

if client.variation("new-feature", user, False):

print("New feature enabled!")

else:

print("New feature disabled.")

21. What is Canary Deployment, and how does it improve software releases?
Question

What is Canary Deployment, and how does it improve software releases?

Answer
Canary Deployment is a progressive release strategy where a new version of an application is
gradually rolled out to a small subset of users before making it available to everyone.

How Canary Deployment Works:

1.​ Deploy the new version (canary) alongside the current production version.
2.​ Route a small percentage of traffic to the new version.
3.​ Monitor logs, metrics, and errors for issues.
4.​ If the new version is stable, gradually increase traffic.
5.​ If issues arise, roll back instantly to the old version.

Why Canary Deployment is important?

●​ Reduces risk: Problems are detected before full rollout.

●​ Instant rollback: If issues arise, revert to the stable version.
●​ Performance testing: Collects real-world usage data.
●​ Minimizes downtime: Unlike blue-green, it doesn’t require full duplication.

What skills are required to prepare for this question?

●​ Experience with CI/CD pipelines.

●​ Understanding of traffic routing and load balancing.
●​ Hands-on with Kubernetes, AWS ALB, Istio, or Nginx.
●​ Familiarity with monitoring tools (Prometheus, Datadog).

How to study this question?

●​ Study Canary Deployment strategies in Kubernetes.

●​ Learn traffic shaping with Istio or Nginx.
●​ Implement progressive rollout in a cloud environment.
●​ Analyze case studies from Netflix, Google, and AWS.

Examples for this question

●​ Kubernetes Canary Deployment with Istio:​

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: my-app

spec:
 hosts:

- my-app.example.com

http:

- route:

- destination:

host: my-app

subset: stable

weight: 90

- destination:

host: my-app

subset: canary

weight: 10

●​ ​
This sends 90% of traffic to the stable version and 10% to the canary.​

●​ Canary Deployment in AWS with ALB Weighting:​

Unset
aws elbv2 modify-target-group-attributes \

--target-group-arn arn:aws:elasticloadbalancing:region:target-group \

--attributes Key=stickiness.enabled,Value=true

●​ ​
Using Argo Rollouts for Canary Deployment:​
 Unset
apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

name: my-app

spec:

strategy:

canary:

steps:

- setWeight: 20

- pause: {duration: 10m}

- setWeight: 50

- pause: {duration: 10m}

22. What is a Service Mesh, and why is it used in DevOps?

Question

What is a Service Mesh, and why is it used in DevOps?

Answer

A Service Mesh is an infrastructure layer that manages service-to-service communication in a

microservices architecture. It provides features like load balancing, security, observability, and
traffic control without changing application code.

Why use a Service Mesh?

●​ Traffic control: Manages routing, retries, and timeouts.

●​ Security: Enables mTLS (mutual TLS) encryption between services.
●​ Observability: Provides tracing, logging, and metrics.
●​ Resilience: Implements circuit breakers and fault injection.

Popular Service Meshes:

 ●​ Istio – Most widely used, integrates with Kubernetes.
●​ Linkerd – Lightweight and Kubernetes-native.
●​ Consul – Focuses on multi-cloud and service discovery.
●​ AWS App Mesh – Managed service for AWS environments.

What skills are required to prepare for this question?

●​ Understanding of microservices and networking.

●​ Hands-on experience with Kubernetes and Istio.
●​ Knowledge of service-to-service communication.
●​ Experience with monitoring tools (Prometheus, Grafana, Jaeger).

How to study this question?

●​ Learn Istio and Linkerd basics.

●​ Set up mTLS and traffic control with a Service Mesh.
●​ Experiment with distributed tracing (Jaeger, Zipkin).
●​ Read case studies on Netflix, Lyft, and Google’s use of Service Mesh.

Examples for this question

●​ Istio Service Mesh configuration for traffic splitting:

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: my-service

spec:

hosts:

- my-service.default.svc.cluster.local

http:

- route:

- destination:

host: my-service

subset: v1
 weight: 80

- destination:

host: my-service

subset: v2

weight: 20

●​ Enabling mTLS in Istio for secure communication:

Unset
apiVersion: security.istio.io/v1beta1

kind: PeerAuthentication

metadata:

name: default

spec:

mtls:

mode: STRICT

●​ Observability with Istio and Prometheus:

Unset
kubectl apply -f
https://github.com/istio/istio/blob/master/samples/addons/prometheus.ya
ml

23. What is GitOps, and how does it improve DevOps workflows?

Question
What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps practice that uses Git as the single source of truth for infrastructure and
application deployment. It ensures that infrastructure is managed declaratively and automatically
synced with the desired state in Git.

How GitOps Works:

1.​ Declare the desired state (e.g., Kubernetes manifests, Terraform configurations).
2.​ Store everything in Git, including infrastructure and application configurations.
3.​ Automate deployments using Git triggers (e.g., ArgoCD, Flux).
4.​ Continuously monitor and reconcile the actual state with the Git repository.

Benefits of GitOps:

●​ Version-controlled infrastructure – Everything is stored in Git.

●​ Automated deployments – Ensures consistency across environments.
●​ Improved security – No manual changes in production.
●​ Fast rollback – Revert to a previous version instantly.

Popular GitOps Tools:

●​ ArgoCD – Kubernetes-native GitOps controller.

●​ FluxCD – Lightweight GitOps tool for Kubernetes.
●​ Terraform Cloud – GitOps for infrastructure as code.
●​ Jenkins X – GitOps-driven CI/CD for Kubernetes.

What skills are required to prepare for this question?

●​ Knowledge of Git and version control.

●​ Experience with Kubernetes and CI/CD pipelines.
●​ Familiarity with ArgoCD or FluxCD.
●​ Understanding of Infrastructure as Code (Terraform, Helm).

How to study this question?

●​ Read about GitOps principles from Weaveworks.

●​ Practice using ArgoCD or FluxCD for Kubernetes deployments.
●​ Implement a Git-based CI/CD pipeline.
●​ Experiment with Terraform Cloud and GitOps workflows.

Examples for this question

●​ Using ArgoCD to deploy a Kubernetes application:​

Unset
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: my-app

spec:

destination:

server: https://kubernetes.default.svc

namespace: default

source:

repoURL: https://github.com/my-org/my-app.git

targetRevision: main

path: k8s

syncPolicy:

automated:

prune: true

selfHeal: true

●​ ​
Apply the configuration:​

Unset
kubectl apply -f argocd-application.yaml

●​ ​
FluxCD setup for automatic deployments:​
 Unset
flux bootstrap github \

--owner=my-org \

--repository=my-app \

--branch=main \

--path=./clusters/my-cluster

24. What is Infrastructure as Code (IaC), and why is it important in DevOps?

Question

What is Infrastructure as Code (IaC), and why is it important in DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using code,
rather than manual processes. It enables automation, consistency, and version control for
infrastructure deployment.

Why IaC is important in DevOps?

●​ Automation – Eliminates manual infrastructure setup.

●​ Consistency – Ensures identical environments across dev, test, and production.
●​ Version Control – Infrastructure configurations are stored in Git.
●​ Scalability – Allows rapid provisioning of infrastructure.
●​ Faster Disaster Recovery – Quickly recreate infrastructure in case of failure.

Popular IaC Tools:

●​ Terraform – Cloud-agnostic IaC tool.

●​ AWS CloudFormation – AWS-native IaC service.
●​ Ansible – Configuration management and provisioning.
●​ Pulumi – IaC with support for multiple programming languages.

What skills are required to prepare for this question?

●​ Understanding of cloud services (AWS, Azure, GCP).

●​ Hands-on experience with Terraform or CloudFormation.
●​ Familiarity with YAML, JSON, or HCL (HashiCorp Configuration Language).
●​ Knowledge of CI/CD pipelines integrating with IaC.
How to study this question?

●​ Learn Terraform basics and write simple scripts.

●​ Deploy infrastructure using AWS CloudFormation or Terraform.
●​ Use GitOps to manage IaC configurations.
●​ Study real-world case studies of IaC adoption (Netflix, Uber, Spotify).

Examples for this question

●​ Terraform script to deploy an AWS EC2 instance:​

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "example" {

ami = "ami-0c55b159cbfafe1f0"

instance_type = "t2.micro"

●​ ​
Deploy the infrastructure:​

Unset
terraform init

terraform apply

●​ ​
AWS CloudFormation YAML template for an S3 bucket:​
 Unset
Resources:

MyS3Bucket:

Type: "AWS::S3::Bucket"

Properties:

BucketName: "my-cloudformation-bucket"

●​ ​
Ansible playbook to install Nginx on a server:​

Unset
- hosts: webservers

tasks:

- name: Install Nginx

apt:

name: nginx

state: present

25. What is the difference between Immutable and Mutable Infrastructure?

Question

What is the difference between Immutable and Mutable Infrastructure?

Answer

Immutable and Mutable Infrastructure are two approaches to managing infrastructure.

●​ Immutable Infrastructure:​

○​ Once provisioned, it cannot be changed.

○​ Any updates require creating a new instance and replacing the old one.
○​ Ensures consistency and eliminates configuration drift.
 ○​ Examples: Docker Containers, Kubernetes Pods, Serverless (AWS Lambda, Azure
Functions).
●​ Mutable Infrastructure:​

○​ Can be modified after deployment.

○​ Changes are made in place (e.g., installing software, updating configurations).
○​ Can lead to inconsistencies across environments.
○​ Examples: Traditional VMs, manually managed servers.

Key Differences:

Feature Immutable Infrastructure Mutable Infrastructure

Changeability Cannot be changed after deployment Can be modified after

deployment

Updates Requires replacing instances Allows in-place changes

Consistency Highly consistent (no drift) Prone to configuration drift

Deployment Tools Terraform, Packer, Kubernetes, AWS Chef, Ansible, Puppet

AMIs

Why Immutable Infrastructure is preferred in DevOps?

●​ Reduces configuration drift and inconsistencies.

●​ Enables faster rollbacks by replacing faulty instances.
●​ Works well with CI/CD pipelines and containerized environments.

What skills are required to prepare for this question?

●​ Understanding of infrastructure management.

●​ Knowledge of Terraform, Kubernetes, or AWS AMIs.
●​ Experience with CI/CD pipelines for infrastructure updates.
●​ Familiarity with containerization (Docker, Kubernetes, AWS Fargate).

How to study this question?

●​ Learn the basics of Immutable Infrastructure.

●​ Deploy immutable infrastructure using Terraform and Kubernetes.
●​ Understand how AWS AMIs and container images enable immutability.
 ●​ Study case studies (Netflix, Google, Uber use immutable infrastructure).

Examples for this question

●​ Immutable Infrastructure using Terraform to deploy a new AWS EC2 instance instead of
modifying the old one:​

Unset
resource "aws_instance" "example" {

ami = "ami-12345678"

instance_type = "t2.micro"

●​ ​
Instead of updating the instance, create a new one with a new AMI.​

●​ Docker-based Immutable Infrastructure:​

Unset
FROM nginx:latest

COPY index.html /usr/share/nginx/html/index.html

CMD ["nginx", "-g", "daemon off;"]

●​ ​
Any change requires building a new Docker image instead of modifying the existing container.​

●​ Using Kubernetes Deployments to ensure immutability:​

Unset
apiVersion: apps/v1

kind: Deployment

metadata:
 name: my-app

spec:

replicas: 3

template:

spec:

containers:

- name: my-app

image: my-app:v2 # New image replaces old version

●​ ​
Instead of modifying running pods, Kubernetes replaces them with new ones.​

26. What is Blue-Green Deployment, and how does it compare to Canary

Deployment?
Question

What is Blue-Green Deployment, and how does it compare to Canary Deployment?

Answer

Blue-Green Deployment is a deployment strategy where two identical environments (Blue and
Green) are maintained. The current production version (Blue) runs while the new version (Green) is
deployed and tested. Once verified, traffic is switched from Blue to Green, making it live. If issues
arise, rollback is instant by switching traffic back to Blue.

How Blue-Green Deployment Works:

1.​ Deploy the new version (Green) alongside the existing (Blue) version.
2.​ Test the Green environment for stability and correctness.
3.​ Switch traffic from Blue to Green once testing is complete.
4.​ Keep the old version (Blue) temporarily for rollback if needed.

Comparison: Blue-Green vs. Canary Deployment

 Feature Blue-Green Deployment Canary Deployment

Rollout Strategy Entire traffic shifts at once Gradual traffic shift

Risk Reduction Quick rollback possible Detects issues

progressively

Downtime Minimal if automated No downtime

Infrastructure Requires two full Uses partial traffic shift

Cost environments

What skills are required to prepare for this question?

●​ Understanding of CI/CD deployment strategies.

●​ Experience with Kubernetes, AWS Elastic Load Balancer (ALB), or Nginx.
●​ Hands-on with traffic routing and load balancing.
●​ Knowledge of rollback strategies and monitoring tools.

How to study this question?

●​ Learn deployment strategies in Kubernetes and cloud platforms.

●​ Practice Blue-Green Deployment using AWS Elastic Beanstalk or Kubernetes.
●​ Understand how load balancers manage traffic switching.
●​ Study real-world case studies from Netflix, Spotify, and Amazon.

Examples for this question

●​ Blue-Green Deployment using Kubernetes Services:​

Unset
apiVersion: v1

kind: Service

metadata:

name: my-app
spec:

selector:

app: my-app-green # Switch from "my-app-blue" to "my-app-green"

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ ​
When switching, update the selector from my-app-blue to my-app-green.​

●​ Blue-Green Deployment with AWS ALB:​

Unset
aws elbv2 modify-listener --listener-arn <listener-arn> \

--default-actions Type=forward,TargetGroupArn=<new-target-group-arn>

●​ ​
This command switches traffic from the old target group (Blue) to the new one (Green).​

●​ Using Nginx for Blue-Green traffic switching:​

Unset
upstream blue {

server blue-app:8080;

upstream green {

server green-app:8080;
 }

server {

listen 80;

location / {

proxy_pass http://green; # Change from "blue" to "green" for

switching

27. What is Chaos Engineering, and why is it important in DevOps?

Question

What is Chaos Engineering, and why is it important in DevOps?

Answer

Chaos Engineering is the practice of intentionally introducing failures into a system to test its
resilience and fault tolerance. The goal is to proactively identify weaknesses before they cause
real-world outages.

Why is Chaos Engineering important in DevOps?

●​ Helps teams identify hidden failures before they happen.

●​ Improves system resilience and reliability.
●​ Ensures applications can handle unexpected disruptions (e.g., server crashes, network
failures).
●​ Reduces downtime and enhances incident response.

How Chaos Engineering Works:

1.​ Define the system’s normal behavior.

2.​ Introduce controlled failures (e.g., shutting down servers, simulating high CPU usage).
3.​ Observe system response and measure impact.
4.​ Improve the system based on the findings.

Popular Chaos Engineering Tools:

 ●​ Chaos Monkey (Netflix) – Randomly shuts down servers.
●​ Gremlin – Injects faults in infrastructure, networks, and applications.
●​ LitmusChaos – Kubernetes-native chaos testing.
●​ AWS Fault Injection Simulator (FIS) – Simulates cloud service failures.

What skills are required to prepare for this question?

●​ Understanding of high availability (HA) and fault tolerance.

●​ Knowledge of Kubernetes, AWS, or cloud-based architectures.
●​ Experience with monitoring tools (Prometheus, Grafana, Datadog).
●​ Hands-on with Chaos Engineering tools (Gremlin, LitmusChaos, Chaos Monkey).

How to study this question?

●​ Learn Chaos Engineering principles from Netflix’s Chaos Monkey.

●​ Experiment with Gremlin’s free chaos engineering labs.
●​ Deploy LitmusChaos in Kubernetes and run failure tests.
●​ Study real-world case studies from Netflix, LinkedIn, and Uber.

Examples for this question

●​ Using Chaos Monkey to randomly terminate AWS EC2 instances:​

Unset
chaos-monkey terminate-instance --region us-east-1 --instance-id
i-1234567890abcdef

●​ ​
This command simulates instance failures to test how the system recovers.​

●​ Simulating high CPU load with Gremlin:​

Unset
gremlin attack cpu --cores 2 --length 60

●​ ​
This spikes CPU usage for 60 seconds on 2 cores.​

●​ Injecting network latency in Kubernetes with LitmusChaos:​

 Unset
apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

name: pod-network-latency

spec:

experiments:

- name: pod-network-latency

spec:

components:

env:

- name: NETWORK_LATENCY

value: "5000" # Simulates 5s network delay

●​ ​
This test adds network latency to a Kubernetes pod to measure impact.​

28. What is Site Reliability Engineering (SRE), and how does it differ from DevOps?
Question

What is Site Reliability Engineering (SRE), and how does it differ from DevOps?

Answer

Site Reliability Engineering (SRE) is a discipline that applies software engineering principles to IT
operations to improve system reliability, scalability, and efficiency. It was pioneered by Google to
ensure highly available services.

Key Responsibilities of SREs:

●​ Automate operational tasks (e.g., deployments, monitoring).

●​ Maintain Service Level Objectives (SLOs) and Service Level Indicators (SLIs).
●​ Improve incident response and postmortems.
●​ Optimize performance, scalability, and cost-efficiency.
How SRE Differs from DevOps

Aspect DevOps SRE

Focus Development & Operations Reliability & Automation

Collaboration

Approach Process & culture shift Engineering & automation

Key Metrics CI/CD speed, deployment SLOs, SLIs, Error Budgets

frequency

Tools Used Jenkins, GitOps, Kubernetes Prometheus, SLO tracking, Chaos

Engineering

Role in Helps improve release process Ensures service reliability & handles
Incidents failures

Key Concept: Error Budgets

●​ SRE teams use error budgets to balance innovation vs. reliability.

●​ Example: If an SLA guarantees 99.9% uptime, the system can fail for 43 minutes per month
before development is paused to focus on stability.

What skills are required to prepare for this question?

●​ Knowledge of SLOs, SLIs, and SLAs.

●​ Experience with monitoring and observability tools (Prometheus, Grafana, Datadog).
●​ Strong background in automation and scripting (Python, Bash, Terraform).
●​ Understanding of incident response and reliability best practices.

How to study this question?

●​ Read Google’s SRE Handbook.

●​ Set up monitoring and alerting using Prometheus and Grafana.
●​ Learn error budget policies and their impact on deployments.
●​ Practice automating incident response with runbooks.

Examples for this question

 ●​ Defining an SLO in Prometheus for HTTP request latency:​

Unset
- alert: HighRequestLatency

expr: histogram_quantile(0.95,
rate(http_request_duration_seconds_bucket[5m])) > 0.5

for: 10m

labels:

severity: warning

annotations:

summary: "High Request Latency"

●​ ​
This rule triggers an alert if 95% of HTTP requests take longer than 0.5 seconds.​

●​ Using an error budget policy:​

○​ SLA: 99.9% uptime (43 minutes/month allowed downtime).

○​ If downtime exceeds 43 minutes, new feature releases pause until stability improves.

29. What is GitOps, and how does it improve DevOps workflows?

Question

What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps practice that uses Git as the single source of truth for managing infrastructure
and application deployments. It applies declarative configurations and automated workflows to
ensure consistency and reliability.

How GitOps Works:

1.​ Store infrastructure and application configurations in Git (e.g., Kubernetes manifests,
Terraform scripts).
2.​ Monitor Git repositories for changes using automation tools (ArgoCD, FluxCD).
3.​ Sync changes automatically to the production environment.
 4.​ Rollback easily using Git history in case of failures.

Why GitOps is important?

●​ Version Control & Auditability – Every change is tracked in Git.

●​ Automation – Reduces manual intervention in deployments.
●​ Consistency – Ensures all environments (dev, test, prod) are identical.
●​ Faster Rollbacks – Reverting to a previous state is as simple as a git revert.

Popular GitOps Tools:

●​ ArgoCD – Kubernetes-native GitOps tool for continuous deployment.

●​ FluxCD – Automates Kubernetes deployment using GitOps principles.
●​ Jenkins X – CI/CD automation for Kubernetes with GitOps support.

What skills are required to prepare for this question?

●​ Understanding of Git and version control workflows.

●​ Knowledge of Kubernetes deployments and Helm charts.
●​ Experience with CI/CD tools and automation (ArgoCD, FluxCD, Jenkins X).
●​ Familiarity with Infrastructure as Code (Terraform, Kubernetes YAML).

How to study this question?

●​ Set up ArgoCD or FluxCD to deploy a Kubernetes app.

●​ Learn how to store and manage Kubernetes manifests in Git.
●​ Understand declarative infrastructure management using Terraform.
●​ Study real-world case studies of GitOps adoption (Weaveworks, Intuit, Alibaba Cloud).

Examples for this question

●​ Using ArgoCD to deploy a Kubernetes application from a Git repo:​

Unset
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: my-app

spec:

destination:

namespace: my-namespace
 server: https://kubernetes.default.svc

source:

repoURL: https://github.com/myorg/my-repo.git

path: k8s-manifests

targetRevision: main

●​ ​
This setup syncs Kubernetes manifests from a Git repository.​

●​ Automating deployments with FluxCD:​

Unset
flux bootstrap github \

--owner=myorg \

--repository=my-gitops-repo \

--branch=main \

--path=clusters/my-cluster

●​ ​
This command sets up FluxCD to manage Kubernetes deployments from Git.​

30. What is Infrastructure as Code (IaC), and how does it benefit DevOps?
Question

What is Infrastructure as Code (IaC), and how does it benefit DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using
declarative code instead of manual processes. It enables automation, version control, and
consistency in infrastructure deployment.
Types of IaC:

1.​ Declarative (What to achieve) – Defines the desired state (e.g., Terraform, CloudFormation).
2.​ Imperative (How to achieve it) – Uses step-by-step commands (e.g., Ansible, Chef, Puppet).

Key Benefits of IaC in DevOps:

●​ Automation – Reduces manual work and speeds up infrastructure provisioning.

●​ Consistency – Eliminates configuration drift across environments.
●​ Version Control – Enables rollbacks and collaboration using Git.
●​ Scalability – Quickly provisions new infrastructure on demand.

Popular IaC Tools:

●​ Terraform – Declarative, cloud-agnostic infrastructure management.

●​ AWS CloudFormation – Automates AWS resource provisioning.
●​ Ansible – Automates configuration management and deployments.
●​ Pulumi – Uses programming languages (Python, Go, etc.) for IaC.

What skills are required to prepare for this question?

●​ Knowledge of Terraform, CloudFormation, or Ansible.

●​ Understanding of declarative vs. imperative IaC.
●​ Hands-on experience with cloud platforms (AWS, Azure, GCP).
●​ Familiarity with CI/CD pipelines for IaC automation.

How to study this question?

●​ Learn Terraform basics and deploy resources on AWS/Azure.

●​ Experiment with CloudFormation stacks for AWS infrastructure.
●​ Automate server configurations with Ansible playbooks.
●​ Read case studies on how companies use IaC for large-scale deployments.

Examples for this question

●​ Terraform code to deploy an AWS EC2 instance:​

Unset
resource "aws_instance" "web" {

ami = "ami-12345678"

instance_type = "t2.micro"

tags = {

Name = "TerraformInstance"
 }

●​ ​
This automates EC2 provisioning instead of manual setup.​

●​ Ansible playbook to install Nginx on a server:​

Unset
- hosts: webservers

tasks:

- name: Install Nginx

apt:

name: nginx

state: present

●​ ​
This ensures Nginx is always installed on the target servers.​

●​ AWS CloudFormation template to create an S3 bucket:​

Unset
Resources:

MyS3Bucket:

Type: "AWS::S3::Bucket"

Properties:

BucketName: "my-iac-bucket"
 ●​ ​
This creates an S3 bucket using CloudFormation.​

31. What are the different types of Kubernetes services, and when should you use
them?
Question

What are the different types of Kubernetes services, and when should you use them?

Answer

In Kubernetes, Services expose applications running in pods to the network (internally or externally).
There are four main types of Kubernetes services:

1.​ ClusterIP (Default)​

○​ Use Case: Internal communication between pods.

○​ Example: Microservices talking to each other within the cluster.
○​ Access: Only within the cluster (no external access).
2.​ NodePort​

○​ Use Case: Exposes the service on a static port of each node.

○​ Example: Quick debugging or exposing services without a load balancer.
○​ Access: <NodeIP>:<NodePort>.
3.​ LoadBalancer​

○​ Use Case: Exposes service using a cloud provider’s load balancer.

○​ Example: Public-facing web applications in AWS, GCP, or Azure.
○​ Access: External IP provided by cloud provider.
4.​ ExternalName​

○​ Use Case: Maps a Kubernetes service to an external DNS name.

○​ Example: Redirecting traffic to external databases (e.g., Amazon RDS).
○​ Access: Resolves to the external service’s DNS name.

What skills are required to prepare for this question?

●​ Understanding Kubernetes networking concepts.

●​ Knowledge of Ingress, Load Balancers, and DNS resolution.
●​ Experience deploying applications with Kubernetes services.
●​ Familiarity with cloud-managed Kubernetes (EKS, AKS, GKE).

How to study this question?

●​ Deploy different types of services in a Kubernetes cluster.

●​ Use Minikube or Kind to test service behaviors locally.
 ●​ Learn how cloud load balancers integrate with Kubernetes.
●​ Read Kubernetes documentation on networking and services.

Examples for this question

●​ ClusterIP Service (Internal Only):​

Unset
apiVersion: v1

kind: Service

metadata:

name: my-internal-service

spec:

selector:

app: my-app

ports:

- protocol: TCP

port: 80

targetPort: 8080

type: ClusterIP # Default service type

●​ ​
This allows pods within the cluster to communicate with my-internal-service.​

●​ NodePort Service (Exposes on a static port):​

Unset
apiVersion: v1

kind: Service

metadata:
 name: my-nodeport-service

spec:

selector:

app: my-app

ports:

- protocol: TCP

port: 80

targetPort: 8080

nodePort: 30000 # Static external port

type: NodePort

●​ ​
Access the service via <NodeIP>:30000.​

●​ LoadBalancer Service (Cloud Provider Integration):​

Unset
apiVersion: v1

kind: Service

metadata:

name: my-loadbalancer-service

spec:

selector:

app: my-app

ports:
 - protocol: TCP

port: 80

targetPort: 8080

type: LoadBalancer

●​ ​
In AWS, Azure, or GCP, this automatically provisions a public IP address.​

●​ ExternalName Service (Redirects to external service):​

Unset
apiVersion: v1

kind: Service

metadata:

name: external-db

spec:

type: ExternalName

externalName: mydb.example.com

●​ ​
This redirects traffic to mydb.example.com instead of an internal pod.​

32. What is Blue-Green Deployment, and how does it work in DevOps?

Question

What is Blue-Green Deployment, and how does it work in DevOps?

Answer
Blue-Green Deployment is a release management strategy that reduces downtime and risk by
running two separate environments:

●​ Blue (Current Production Environment) – The live system handling real traffic.
●​ Green (New Version Environment) – The updated version of the application.

How it works:

1.​ Deploy the new version in the Green environment.

2.​ Run tests in the Green environment to ensure stability.
3.​ Switch traffic from Blue to Green (usually via load balancer or DNS update).
4.​ If an issue occurs, rollback by switching traffic back to Blue.

Benefits of Blue-Green Deployment:

●​ Zero downtime – No interruption to users during deployment.

●​ Easy rollback – Switch back to the stable version instantly.
●​ Safe testing in production – Verify the new version before exposing it to users.

Challenges:

●​ Infrastructure cost – Requires two running environments.

●​ Database synchronization – Ensuring schema compatibility between versions.

What skills are required to prepare for this question?

●​ Understanding CI/CD pipelines and deployment strategies.

●​ Experience with load balancers (Nginx, AWS ALB, Kubernetes Ingress).
●​ Familiarity with Kubernetes rolling updates and canary deployments.
●​ Knowledge of database versioning and schema migrations.

How to study this question?

●​ Implement Blue-Green Deployment in Kubernetes using Ingress.

●​ Use AWS ALB, Nginx, or Istio to control traffic switching.
●​ Study real-world Blue-Green Deployment case studies (Netflix, Amazon, Facebook).
●​ Practice using Terraform, ArgoCD, or Jenkins to automate deployment switching.

Examples for this question

●​ Using Nginx to switch between Blue and Green versions:​

Unset
upstream blue {

server blue-app:8080;

}
upstream green {

server green-app:8080;

server {

listen 80;

location / {

proxy_pass http://green; # Switch to "blue" for rollback

●​ ​
This configuration routes traffic to the Green environment.​

●​ AWS Elastic Load Balancer (ALB) Target Group Switching:​

Unset
aws elbv2 modify-listener \

--listener-arn arn:aws:elasticloadbalancing:region:listener-id \

--default-actions '[{"Type": "forward",

"TargetGroupArn":"green-target-group-arn"}]'

●​ ​
This command updates the AWS ALB to route traffic to the Green environment.​

●​ Kubernetes Blue-Green Deployment using a Service and two Deployments:​

 Unset
apiVersion: v1

kind: Service

metadata:

name: my-app

spec:

selector:

app: green # Change to "blue" for rollback

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ ​
The service selector determines which deployment (Blue or Green) is active.​

33. What is Canary Deployment, and how does it improve release management?
Question

What is Canary Deployment, and how does it improve release management?

Answer

Canary Deployment is a deployment strategy that gradually rolls out new versions of an application
to a small subset of users before a full release. It minimizes risk by testing changes in production with
real traffic.

How Canary Deployment Works:

1.​ Deploy the new version to a small percentage (e.g., 5%) of users.
2.​ Monitor performance, error rates, and user feedback.
3.​ If successful, gradually increase traffic to the new version.
4.​ If issues arise, rollback to the stable version immediately.
Benefits of Canary Deployment:

●​ Reduces risk – New releases affect only a small user base at first.
●​ Real-time validation – Detects issues in a live environment.
●​ Fast rollback – Stops bad releases before full impact.
●​ A/B testing – Can be used to test features on select users.

Challenges:

●​ Traffic routing complexity – Requires feature flags or load balancers.

●​ Monitoring and automation – Needs tools like Prometheus, Istio, or Argo Rollouts.

What skills are required to prepare for this question?

●​ Experience with Kubernetes deployment strategies.

●​ Understanding of traffic splitting with Istio, Nginx, or AWS ALB.
●​ Knowledge of monitoring tools (Datadog, Prometheus, Grafana).
●​ Familiarity with CI/CD tools like ArgoCD, Spinnaker, or Jenkins.

How to study this question?

●​ Deploy a Canary release in Kubernetes with Argo Rollouts.

●​ Use Istio or Nginx to gradually route traffic to a new version.
●​ Study real-world use cases (Google, Netflix, LinkedIn).
●​ Learn feature flagging with LaunchDarkly or Flagger.

Examples for this question

●​ Kubernetes Canary Deployment with Istio:​

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: canary-route

spec:

hosts:

- my-app.example.com

http:
 - route:

- destination:

host: my-app

subset: stable

weight: 90

- destination:

host: my-app

subset: canary

weight: 10

●​ ​
This routes 90% of traffic to the stable version and 10% to the new version.​

●​ Feature Flag Canary Release with Flagger:​

Unset
apiVersion: flagger.app/v1beta1

kind: Canary

metadata:

name: my-app

spec:

targetRef:

apiVersion: apps/v1

kind: Deployment

name: my-app
 progressDeadlineSeconds: 60

canaryAnalysis:

interval: 1m

threshold: 5

maxWeight: 50

stepWeight: 10

●​ ​
This gradually shifts traffic in 10% increments until 50% of traffic is on the new version.​

34. What is Chaos Engineering, and why is it important in DevOps?

Question

What is Chaos Engineering, and why is it important in DevOps?

Answer

Chaos Engineering is the practice of intentionally injecting failures into a system to test its
resilience and improve reliability. The goal is to identify weaknesses before they cause real-world
outages.

How Chaos Engineering Works:

1.​ Define steady-state behavior – Measure normal system performance.

2.​ Hypothesize impact of failures – Predict how the system should react.
3.​ Introduce controlled failures – Inject network latency, CPU spikes, or crashes.
4.​ Observe and analyze – Monitor logs, metrics, and alerts.
5.​ Fix weaknesses – Improve system resilience based on findings.

Common Chaos Engineering Experiments:

●​ Shutting down random servers (Simulating EC2 instance failure).

●​ Inducing network latency or packet loss.
●​ Killing Kubernetes pods unexpectedly.
●​ Increasing CPU or memory usage on nodes.

Why Chaos Engineering is important in DevOps?

 ●​ Improves system resilience – Identifies weak points proactively.
●​ Prepares teams for real failures – Helps engineers practice incident response.
●​ Validates auto-scaling and failover mechanisms.
●​ Reduces downtime and improves customer experience.

Popular Chaos Engineering Tools:

●​ Chaos Monkey (Netflix) – Randomly shuts down cloud instances.

●​ Gremlin – Enterprise tool for controlled chaos testing.
●​ LitmusChaos – Kubernetes-native chaos testing framework.
●​ AWS Fault Injection Simulator (FIS) – Injects failures into AWS infrastructure.

What skills are required to prepare for this question?

●​ Understanding of high availability (HA) and failover mechanisms.

●​ Experience with Kubernetes resilience testing (LitmusChaos, KubeMonkey).
●​ Familiarity with monitoring tools (Prometheus, Grafana, Datadog).
●​ Hands-on knowledge of cloud resilience strategies (AWS Auto Scaling, GCP SRE practices).

How to study this question?

●​ Set up Chaos Monkey on AWS or Kubernetes and observe impact.

●​ Run LitmusChaos experiments on Kubernetes clusters.
●​ Study real-world case studies from Netflix, LinkedIn, and Uber.
●​ Read Google’s Site Reliability Engineering (SRE) book.

Examples for this question

●​ Killing a random Kubernetes pod with LitmusChaos:​

Unset
apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

name: pod-delete-chaos

spec:

appinfo:

appns: "default"

applabel: "app=my-app"
 appkind: "deployment"

chaosServiceAccount: litmus-admin

experiments:

- name: pod-delete

spec:

components:

env:

- name: TOTAL_CHAOS_DURATION

value: "60"

- name: CHAOS_INTERVAL

value: "10"

●​ ​
This randomly deletes pods in a Kubernetes cluster every 10 seconds for 60 seconds.​

●​ Simulating high CPU usage on an AWS EC2 instance using Gremlin:​

Unset
gremlin attack cpu --target "my-instance" --length 300 --cores 2

●​ ​
This causes a high CPU spike for 5 minutes on a selected instance.​

●​ Introducing 500ms network latency using Chaos Mesh:​

Unset
kubectl apply -f - <<EOF

apiVersion: chaos-mesh.org/v1alpha1
 kind: NetworkChaos

metadata:

name: delay-traffic

spec:

action: delay

duration: "60s"

mode: all

selector:

namespaces:

- default

delay:

latency: "500ms"

EOF

●​ ​
This delays all network traffic by 500ms for 60 seconds in a Kubernetes namespace.​

35. What is Infrastructure as Code (IaC), and how does it benefit DevOps?
Question

What is Infrastructure as Code (IaC), and how does it benefit DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using code
instead of manual processes. It allows developers to define, deploy, and manage cloud resources in a
repeatable and automated manner.

How IaC Works:

 1.​ Write infrastructure definitions in a declarative or imperative format.
2.​ Version control infrastructure using Git.
3.​ Automate deployments using CI/CD pipelines.
4.​ Apply changes consistently across environments (dev, staging, production).

Types of IaC Approaches:

●​ Declarative (What to achieve) – Example: Terraform, CloudFormation.

●​ Imperative (How to achieve it) – Example: Ansible, Pulumi.

Benefits of IaC in DevOps:

●​ Automation – Eliminates manual configuration errors.

●​ Consistency – Ensures identical environments across deployments.
●​ Scalability – Quickly spin up or destroy resources.
●​ Version Control – Infrastructure is stored in Git, enabling tracking and rollback.
●​ Faster Recovery – Easily recreate infrastructure after failures.

Popular IaC Tools:

●​ Terraform – Cloud-agnostic declarative IaC tool.

●​ AWS CloudFormation – AWS-native IaC for managing AWS resources.
●​ Ansible – Imperative tool for configuration management and deployment.
●​ Pulumi – Uses real programming languages (Python, Go, JavaScript) for IaC.

What skills are required to prepare for this question?

●​ Understanding cloud infrastructure (AWS, Azure, GCP).

●​ Hands-on experience with Terraform, CloudFormation, or Ansible.
●​ Familiarity with CI/CD pipelines (GitHub Actions, Jenkins, GitLab CI).
●​ Knowledge of state management, modules, and secrets handling in IaC.

How to study this question?

●​ Deploy infrastructure using Terraform and CloudFormation.

●​ Learn state management in Terraform (e.g., backend storage like S3).
●​ Experiment with Ansible playbooks for configuration management.
●​ Study real-world IaC case studies (Netflix, Spotify, AWS best practices).

Examples for this question

●​ Terraform example: Creating an AWS EC2 instance​

Unset
provider "aws" {

region = "us-east-1"
}

resource "aws_instance" "web" {

ami = "ami-0abcdef1234567890"

instance_type = "t2.micro"

tags = {

Name = "MyTerraformInstance"

●​ ​
This Terraform script provisions an EC2 instance in AWS.​

●​ AWS CloudFormation YAML example: Creating an S3 bucket​

Unset
Resources:

MyS3Bucket:

Type: "AWS::S3::Bucket"

Properties:

BucketName: "my-cloudformation-bucket"

●​ ​
This CloudFormation template creates an S3 bucket in AWS.​

●​ Ansible example: Installing Nginx on a remote server​

 Unset
- hosts: web_servers

tasks:

- name: Install Nginx

apt:

name: nginx

state: present

●​ ​
This Ansible playbook installs Nginx on all servers in the web_servers group.​

36. What is GitOps, and how does it improve DevOps workflows?

Question

What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps practice that uses Git as the single source of truth for managing infrastructure
and application deployments. It enables declarative infrastructure management, automated
deployments, and version-controlled operations.

How GitOps Works:

1.​ Declare infrastructure and application configurations in a Git repository (using

YAML/Terraform/Helm).
2.​ Monitor repository changes using GitOps tools (ArgoCD, Flux).
3.​ Automatically reconcile infrastructure whenever changes are committed.
4.​ Rollback easily by reverting to a previous Git commit.

Key Principles of GitOps:

●​ Declarative – Everything (infra + app) is defined in code.

●​ Version-controlled – All changes are stored in Git with history.
●​ Automated – Deployments are triggered automatically on Git commits.
●​ Continuous Reconciliation – GitOps tools ensure the actual state matches the desired state.
Benefits of GitOps in DevOps:

●​ Improved reliability – Git history enables easy rollbacks.

●​ Better collaboration – Developers use Git pull requests for deployments.
●​ Enhanced security – No need for direct access to production environments.
●​ Faster deployments – Automation reduces human intervention and errors.

Popular GitOps Tools:

●​ ArgoCD – Kubernetes-native continuous delivery tool.

●​ FluxCD – GitOps controller for Kubernetes.
●​ Terraform Cloud – Enables GitOps for infrastructure.
●​ Jenkins X – GitOps-powered CI/CD solution.

What skills are required to prepare for this question?

●​ Understanding CI/CD pipelines and infrastructure as code (IaC).

●​ Hands-on experience with Kubernetes and GitOps tools (ArgoCD, FluxCD).
●​ Familiarity with Git workflows (branching, pull requests, merges).
●​ Knowledge of cloud-native applications and Helm charts.

How to study this question?

●​ Deploy ArgoCD on Kubernetes and set up automated app deployment.

●​ Learn how FluxCD syncs Kubernetes manifests from Git repositories.
●​ Implement GitOps workflows for Terraform and Kubernetes apps.
●​ Study GitOps case studies from Weaveworks, Intuit, and Red Hat.

Examples for this question

●​ ArgoCD Example: Deploying an Application from Git​

Unset
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: my-app

spec:

destination:

namespace: default
 server: https://kubernetes.default.svc

source:

repoURL: https://github.com/my-org/my-app.git

path: manifests

targetRevision: main

syncPolicy:

automated:

prune: true

selfHeal: true

●​ ​
This configuration automatically syncs Kubernetes manifests from a Git repo.​

●​ FluxCD Example: Setting up a GitOps Pipeline​

Unset
flux bootstrap github \

--owner=my-org \

--repository=my-gitops-repo \

--path=clusters/my-cluster \

--personal

●​ ​
This command initializes FluxCD and syncs a repository for Kubernetes deployments.​

37. What is Blue-Green Deployment, and how does it reduce downtime?

Question
What is Blue-Green Deployment, and how does it reduce downtime?

Answer

Blue-Green Deployment is a zero-downtime release strategy where two identical environments

(Blue and Green) are used to switch traffic between an old and a new version of an application.

How Blue-Green Deployment Works:

1.​ Blue environment (current production) is serving live traffic.

2.​ Green environment (new version) is deployed and tested.
3.​ Once Green is stable, traffic is switched from Blue to Green.
4.​ If issues occur, rollback to Blue instantly by switching traffic back.

Benefits of Blue-Green Deployment:

●​ Zero downtime – Users don’t experience service interruptions.

●​ Quick rollback – If issues arise, instantly switch back to Blue.
●​ Safe testing – New version runs in production-like conditions.
●​ No impact on live users – Deployment occurs behind the scenes.

Challenges:

●​ Costly infrastructure – Requires duplicate environments.

●​ Database migrations – Needs careful handling to avoid data inconsistencies.

Popular Tools for Blue-Green Deployment:

●​ AWS Elastic Load Balancer (ELB) – Switches traffic between two environments.
●​ Kubernetes Services & Istio – Routes traffic dynamically.
●​ Nginx/HAProxy – Acts as a traffic switcher.
●​ Spinnaker/ArgoCD – Automates Blue-Green rollouts.

What skills are required to prepare for this question?

●​ Understanding of deployment strategies (Blue-Green, Canary, Rolling Updates).

●​ Experience with traffic routing in AWS (ALB, Route 53) or Kubernetes (Istio, Nginx).
●​ Hands-on with CI/CD pipelines for Blue-Green deployments (ArgoCD, Spinnaker, Jenkins).
●​ Knowledge of database migration strategies for schema changes.

How to study this question?

●​ Set up a Blue-Green Deployment on AWS (EC2 or ECS) with ALB.

●​ Deploy a Kubernetes-based Blue-Green setup using Istio or Nginx.
●​ Practice database versioning strategies with Flyway or Liquibase.
●​ Read case studies from Netflix, Spotify, and Uber on Blue-Green strategies.

Examples for this question

●​ AWS ALB-based Blue-Green Deployment Example:​

Unset
resources:

TargetGroupBlue:

Type: AWS::ElasticLoadBalancingV2::TargetGroup

Properties:

Name: BlueTG

Port: 80

Protocol: HTTP

VpcId: vpc-123456

TargetGroupGreen:

Type: AWS::ElasticLoadBalancingV2::TargetGroup

Properties:

Name: GreenTG

Port: 80

Protocol: HTTP

VpcId: vpc-123456

ListenerRuleSwitch:

Type: AWS::ElasticLoadBalancingV2::ListenerRule

Properties:

ListenerArn: !Ref LoadBalancerListener

Priority: 1

Conditions:
 - Field: path-pattern

Values: ["/"]

Actions:

- Type: forward

TargetGroupArn: !Ref TargetGroupGreen

●​ ​
This CloudFormation config switches ALB traffic to the Green environment.​

●​ Kubernetes Blue-Green Deployment with Nginx Ingress:​

Unset
apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: my-app

spec:

rules:

- host: my-app.example.com

http:

paths:

- path: /

backend:

service:

name: my-app-green
 port:

number: 80

●​ ​
This routes traffic to the Green version of the app in Kubernetes.​

38. What is a Canary Deployment, and how does it differ from Blue-Green
Deployment?
Question

What is a Canary Deployment, and how does it differ from Blue-Green Deployment?

Answer

Canary Deployment is a progressive rollout strategy where a new version of an application is

released to a small subset of users before gradually expanding to the entire user base.

How Canary Deployment Works:

1.​ Deploy a small percentage (e.g., 5%) of traffic to the new version.
2.​ Monitor performance and logs for errors, latency, or crashes.
3.​ If everything is stable, gradually increase traffic to 25%, 50%, and finally 100%.
4.​ If issues arise, rollback quickly to the old version.

Difference Between Canary and Blue-Green Deployment:

Feature Canary Deployment Blue-Green Deployment

Traffic Distribution Gradual rollout (small % first) Instant switch (100% at once)

Risk Level Lower (only a few users Higher (full traffic shift)
affected)

Rollback Easier (affects fewer users) Faster (switch back instantly)

 Use Case Feature testing, API changes Major version upgrades, infra
changes

Benefits of Canary Deployment:

●​ Lower risk – Only a small portion of users are affected by potential failures.
●​ Faster feedback loop – Bugs can be caught early before full rollout.
●​ Better performance testing – Allows gradual scaling based on real traffic.

Challenges:

●​ Requires monitoring & observability – Need tools like Prometheus, Datadog, or AWS
CloudWatch.
●​ Traffic routing complexity – Must configure load balancers or service meshes (Istio, Linkerd).
●​ Takes longer than Blue-Green – Since rollout happens in stages.

Popular Tools for Canary Deployment:

●​ Kubernetes & Istio – Intelligent traffic shifting based on weights.

●​ AWS ALB Weighted Target Groups – Routes specific % of traffic to a new version.
●​ NGINX & HAProxy – Manually configure traffic percentages.
●​ Argo Rollouts & Flagger – Automate Canary deployments in Kubernetes.

What skills are required to prepare for this question?

●​ Understanding progressive delivery strategies (Canary, Blue-Green, Rolling Updates).

●​ Hands-on experience with Kubernetes traffic routing (Istio, Nginx, Flagger).
●​ Knowledge of observability tools (Datadog, Prometheus, CloudWatch).
●​ Experience with feature flags & A/B testing tools.

How to study this question?

●​ Deploy a Canary Release in Kubernetes using Argo Rollouts.

●​ Set up AWS ALB Weighted Target Groups for gradual traffic shifting.
●​ Study real-world Canary Deployments from Netflix, Google, and Spotify.
●​ Learn Istio Canary traffic splitting with Helm charts.

Examples for this question

●​ Kubernetes Canary Deployment using Istio:​

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService
metadata:

name: my-app

spec:

hosts:

- my-app.example.com

http:

- route:

- destination:

host: my-app-v1

weight: 80

- destination:

host: my-app-v2

weight: 20

●​ ​
This routes 80% of traffic to the stable version (my-app-v1) and 20% to the Canary version
(my-app-v2).​

●​ AWS ALB Canary Deployment using Weighted Target Groups:​

Unset
{

"TargetGroups": [

"TargetGroupArn":
"arn:aws:elasticloadbalancing:us-east-1:1234567890:targetgroup/my-app-v
1",
 "Weight": 80

},

"TargetGroupArn":
"arn:aws:elasticloadbalancing:us-east-1:1234567890:targetgroup/my-app-v
2",

"Weight": 20

●​ ​
This gradually shifts traffic to the new version using AWS ALB weighted target groups.​

39. What is a Rolling Deployment, and how does it compare to Blue-Green and
Canary Deployments?
Question

What is a Rolling Deployment, and how does it compare to Blue-Green and Canary Deployments?

Answer

Rolling Deployment is a deployment strategy where a new version of an application is gradually

released one instance at a time, replacing old instances incrementally until all are updated.

How Rolling Deployment Works:

1.​ Start with multiple running instances of the old version.

2.​ Deploy the new version to one instance at a time.
3.​ Monitor the new instance for stability and performance.
4.​ Continue rolling out updates across the fleet until all instances are replaced.

Comparison: Rolling vs. Blue-Green vs. Canary Deployments

 Feature Rolling Deployment Blue-Green Canary Deployment
Deployment

Traffic Gradually updates Switches all traffic Routes small % first, then
Handling instances at once increases

Risk Level Medium Higher (big bang Lower (affects small %

switch) first)

Rollback Medium complexity Instant rollback Easier (affects fewer

(partially updated) users)

Time to Longer (depends on fleet Fast (all at once) Medium (staged rollout)
Deploy size)

Best for Large distributed systems Major version Feature testing, API
upgrades changes

Benefits of Rolling Deployment:

●​ Minimizes downtime – No need to take down the entire application.

●​ Better resource utilization – No need for extra infrastructure like in Blue-Green.
●​ More gradual rollout – Reduces risk compared to full replacements.

Challenges:

●​ Slower deployment time – Updates happen incrementally.

●​ Rollback complexity – If a bad version is detected mid-rollout, some instances are already
updated.
●​ Temporary version mismatches – Some users may get different versions at the same time.

Popular Tools for Rolling Deployment:

●​ Kubernetes Deployment Strategy – Manages pod updates incrementally.

●​ AWS ECS Rolling Updates – Updates EC2 or Fargate tasks gradually.
●​ Jenkins Pipelines with Rolling Deployment – Automates incremental rollouts.
●​ Spinnaker, Argo Rollouts – Provides progressive delivery features.

What skills are required to prepare for this question?

 ●​ Understanding deployment strategies (Rolling, Canary, Blue-Green).
●​ Experience with Kubernetes rolling updates (kubectl, Helm, ArgoCD).
●​ Familiarity with load balancers and traffic routing (AWS ALB, Nginx, Istio).
●​ Knowledge of CI/CD pipeline automation tools.

How to study this question?

●​ Deploy a Rolling Deployment on Kubernetes using kubectl rollout.

●​ Set up AWS ECS Rolling Updates with Fargate or EC2.
●​ Use Jenkins, ArgoCD, or Spinnaker to automate Rolling Deployments.
●​ Read case studies from Netflix, Google, and Uber on progressive rollouts.

Examples for this question

●​ Kubernetes Rolling Deployment Example:​

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: my-app

spec:

replicas: 5

strategy:

type: RollingUpdate

rollingUpdate:

maxSurge: 1

maxUnavailable: 1

template:

spec:

containers:

- name: my-app
 image: my-app:v2

●​ ​
This configuration updates one instance at a time, ensuring a rolling update strategy.​

●​ AWS ECS Rolling Update with Fargate:​

Unset
{

"deploymentConfiguration": {

"minimumHealthyPercent": 50,

"maximumPercent": 200

●​ ​
This setting ensures at least 50% of tasks remain running while rolling out new updates.​

40. What is Infrastructure as Code (IaC), and why is it important in DevOps?

Question

What is Infrastructure as Code (IaC), and why is it important in DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure (servers,
networks, databases) using machine-readable configuration files instead of manual processes. IaC
enables automation, consistency, and scalability in cloud and DevOps environments.

Key Concepts of IaC

1.​ Declarative vs. Imperative​
 ○​ Declarative (Desired State) – Defines the end state, and the system figures out how to
get there (e.g., Terraform, CloudFormation).
○​ Imperative (Step-by-Step) – Specifies exact steps to provision infrastructure (e.g.,
Ansible, Bash scripts).
2.​ Mutable vs. Immutable Infrastructure​

○​ Mutable – Servers are updated in place (e.g., traditional sysadmin tasks).

○​ Immutable – Servers are replaced with new instances on updates (e.g., Terraform,
Packer).
3.​ Idempotency​

○​ Running the same configuration multiple times results in the same state, preventing
drift.

Why is IaC Important in DevOps?

●​ Automation – Eliminates manual provisioning and human errors.
●​ Consistency – Ensures environments (Dev, QA, Prod) are identical.
●​ Scalability – Makes it easy to create and destroy resources on demand.
●​ Version Control – Tracks infrastructure changes in Git (just like application code).
●​ Faster Recovery – Infrastructure can be recreated quickly in case of failure.

Popular IaC Tools

Tool Type Use Case

Terraform Declarative Multi-cloud, Kubernetes

AWS CloudFormation Declarative AWS-specific IaC

Ansible Imperative Configuration management

Pulumi Declarative Multi-cloud, uses real programming

languages

Chef/Puppet Imperative Traditional config management

What skills are required to prepare for this question?

 ●​ Understanding IaC principles (Declarative vs. Imperative, Idempotency).
●​ Hands-on experience with Terraform, AWS CloudFormation, Ansible, or Pulumi.
●​ Knowledge of CI/CD pipeline integration with IaC (GitOps, Jenkins, GitHub Actions).
●​ Experience with state management and remote backends (Terraform State, S3, Consul).

How to study this question?

●​ Deploy an AWS EC2 instance using Terraform and CloudFormation.

●​ Automate Kubernetes cluster deployment using Terraform and Helm.
●​ Learn Ansible playbooks for configuration management.
●​ Read case studies on how Netflix, Uber, and Google use IaC in production.

Examples for this question

●​ Terraform Example: Deploying an EC2 Instance​

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "web" {

ami = "ami-12345678"

instance_type = "t2.micro"

tags = {

Name = "MyTerraformInstance"

●​ ​
This code provisions an EC2 instance on AWS using Terraform.​

●​ AWS CloudFormation Example: Creating an S3 Bucket​

 Unset
Resources:

MyS3Bucket:

Type: AWS::S3::Bucket

Properties:

BucketName: my-cloudformation-bucket

●​ ​
This defines an S3 bucket using AWS CloudFormation.​

41. What is GitOps, and how does it improve DevOps workflows?

Question

What is GitOps, and how does it improve DevOps workflows?

Answer

GitOps is a DevOps methodology that uses Git as the single source of truth for managing
infrastructure and application deployments. It automates deployments by continuously synchronizing
Git repositories with the desired infrastructure state using CI/CD pipelines and Kubernetes
controllers.

How GitOps Works

1.​ Declarative Configuration: Infrastructure and application configurations are stored in Git
using YAML or HCL files.
2.​ Version Control & Change Management: Every infrastructure or app change is committed to
Git, ensuring a full history of modifications.
3.​ Automated Syncing & Reconciliation: Tools like ArgoCD or Flux continuously monitor Git and
apply changes automatically to the cluster.
4.​ Continuous Monitoring & Drift Detection: If the actual state deviates from the Git repository,
GitOps tools correct it automatically.

How GitOps Improves DevOps Workflows

Feature Traditional DevOps GitOps

 Source of Truth Mix of scripts, manual Git repository
changes

Deployments CI/CD pipelines push changes Pull-based automation

Rollback Manual intervention Revert Git commit

Drift Detection Requires manual checks Auto-sync to correct drift

Security & Compliance Prone to config drift Auditable & version-controlled

Key Benefits of GitOps

✅ Increased Automation: No manual infrastructure changes—Git commits trigger updates

✅
automatically.​

✅ Better Collaboration: Developers, ops, and security teams can work together in Git.​

✅ Rollback & Disaster Recovery: Just revert a Git commit to restore a previous version.​

✅ Security & Compliance: All changes are logged and auditable in Git.​
Improved Deployment Speed: Declarative definitions eliminate inconsistencies.

Popular GitOps Tools

Tool Description

ArgoCD Continuous deployment for Kubernetes with

GitOps

FluxCD Lightweight GitOps tool for Kubernetes

Jenkins X Kubernetes-native CI/CD with GitOps

 Weave GitOps Enterprise GitOps with policy enforcement

Terraform with GitOps Uses Git as a state manager for infrastructure

What skills are required to prepare for this question?

●​ Understanding GitOps principles (Declarative state, Pull-based automation).

●​ Experience with Kubernetes and GitOps tools like ArgoCD, FluxCD.
●​ Knowledge of CI/CD pipelines (GitHub Actions, GitLab CI/CD, Jenkins).
●​ Hands-on with Terraform, Helm, and Kubernetes manifests.

How to study this question?

●​ Set up ArgoCD for deploying a Kubernetes application using GitOps.

●​ Deploy FluxCD to automate configuration changes in Kubernetes.
●​ Integrate GitHub Actions with GitOps workflows.
●​ Read case studies on how GitOps is used in Netflix, Weaveworks, and Microsoft.

Examples for this question

●​ GitOps with ArgoCD: Kubernetes Deployment from Git​

Unset
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: my-app

namespace: argocd

spec:

destination:

namespace: default

server: https://kubernetes.default.svc

source:
 repoURL: https://github.com/my-org/my-repo.git

targetRevision: main

path: k8s-manifests

syncPolicy:

automated:

prune: true

selfHeal: true

●​ ​
This ArgoCD configuration deploys and auto-syncs Kubernetes manifests from a Git
repository.​

●​ GitOps Workflow for Terraform with GitHub Actions​

Unset
name: Terraform GitOps

on:

push:

branches:

- main

jobs:

terraform-apply:

runs-on: ubuntu-latest

steps:
 - name: Checkout code

uses: actions/checkout@v2

- name: Setup Terraform

uses: hashicorp/setup-terraform@v1

- name: Terraform Apply

run: |

terraform init

terraform apply -auto-approve

●​ ​
This GitHub Actions workflow automates Terraform deployments using GitOps.​

42. What is Immutable Infrastructure, and how does it compare to Mutable

Infrastructure?
Question

What is Immutable Infrastructure, and how does it compare to Mutable Infrastructure?

Answer

Immutable Infrastructure is an approach where infrastructure components (such as servers,

containers, and virtual machines) are never modified after deployment. Instead of updating existing
resources, a new version is created, and the old one is completely replaced.

In contrast, Mutable Infrastructure allows modifications (such as software updates, patches, or

configuration changes) on existing resources.

Immutable vs. Mutable Infrastructure

 Feature Immutable Infrastructure Mutable Infrastructure

Configuration Never modified after deployment Updated in place

Changes

Risk Level Lower (ensures consistency) Higher (config drift possible)

Rollback Easy (redeploy previous version) Complex (requires undoing

changes)

Security Higher (no manual changes) Lower (prone to

misconfigurations)

Deployment Method New instances replace old ones Updates applied to live systems

Example Tools Docker, Kubernetes, Terraform, Ansible, Chef, Puppet

Packer

Why is Immutable Infrastructure Important in DevOps?

✅✅Prevents Configuration Drift – Ensures all environments are identical.​

✅
✅
Faster Rollbacks – If an update fails, deploy the previous version instantly.​
Improved Security – Reduces risks from unauthorized or untracked changes.​

✅ Better Scalability – Easily spin up new instances instead of modifying old ones.​
Easier CI/CD Pipelines – Works well with containers and Kubernetes.

Challenges of Immutable Infrastructure

●​ Requires re-deployments for every change – Even small updates need a new version.
●​ Higher storage costs – Old instances remain until completely removed.
●​ More reliance on automation – Requires tools like Terraform, Packer, and Kubernetes.

Popular Tools for Immutable Infrastructure

Tool Purpose
 Docker Containerization

Kubernetes Orchestration of immutable

containers

Terraform Infrastructure as Code (IaC)

Packer Automates VM image creation

AWS Auto Scaling Replaces old instances with new ones

What skills are required to prepare for this question?

●​ Understanding Immutable vs. Mutable Infrastructure principles.

●​ Hands-on experience with Docker, Kubernetes, Terraform, or AWS Auto Scaling.
●​ Knowledge of CI/CD automation for immutable deployments.
●​ Experience with image creation using Packer.

How to study this question?

●​ Deploy an immutable EC2 instance using Packer and Terraform.

●​ Set up Kubernetes Deployments with rolling updates.
●​ Automate Docker image creation with CI/CD pipelines.
●​ Read case studies on how Google, Netflix, and AWS use immutable infrastructure.

Examples for this question

●​ Immutable Infrastructure with Terraform and Packer​

Unset
provider "aws" {

region = "us-east-1"

}
resource "aws_instance" "web" {

ami = "ami-12345678" # AMI built with Packer

instance_type = "t3.micro"

lifecycle {

create_before_destroy = true

●​ ​
This Terraform code ensures instances are replaced instead of modified.​

●​ Kubernetes Deployment for Immutable Containers​

Unset
apiVersion: apps/v1

kind: Deployment

metadata:

name: my-app

spec:

replicas: 3

strategy:

type: RollingUpdate

template:

spec:
 containers:

- name: my-app

image: my-app:v2 # New image replaces old one

●​ ​
Kubernetes ensures immutable container deployments with rolling updates.​

43. What is Blue-Green Deployment, and how does it compare to Canary

Deployment?
Question

What is Blue-Green Deployment, and how does it compare to Canary Deployment?

Answer

Blue-Green Deployment is a zero-downtime deployment strategy where two identical

environments, Blue (current/live version) and Green (new version), are maintained. Once the new
version (Green) is fully tested and validated, traffic is switched from Blue to Green, making Green
the new production environment.

In contrast, Canary Deployment gradually rolls out the new version to a small percentage of users
before full release.

How Blue-Green Deployment Works

1.​ Blue environment (current live version) serves users.
2.​ Green environment (new version) is deployed and tested.
3.​ Traffic is switched from Blue to Green (via Load Balancer or DNS update).
4.​ If issues occur, revert back to Blue instantly.

Blue-Green Deployment vs. Canary Deployment

Feature Blue-Green Deployment Canary Deployment

Traffic Handling Switches all traffic at once Routes small % of traffic first
 Risk Level Higher (if Green has issues) Lower (affects fewer users)

Rollback Instant switch to Blue Gradual rollback possible

Infrastructure Cost Requires duplicate infra Can use same infra with
routing

Deployment Speed Fast (one switch) Slower (gradual rollout)

Best for Large-scale deployments Feature testing, API updates

Advantages of Blue-Green Deployment

✅✅Instant Rollback – If issues occur, switching back is immediate.​

✅ Zero Downtime – Users experience no service interruption.​

✅ Simple Traffic Management – A single DNS or Load Balancer switch updates traffic.​
Easy Testing – The Green environment is fully tested before switching.

Challenges of Blue-Green Deployment

●​ Requires duplicate infrastructure, which increases cost.
●​ Not ideal for database changes, as switching back can be complex.
●​ Sudden full switch can be risky, as all users get the new version instantly.

Popular Tools for Blue-Green Deployment

Tool Purpose

AWS Elastic Load Balancer (ELB) Directs traffic between Blue and Green

Kubernetes Service Updates Switches between Blue (old pods) and Green (new
pods)
 Terraform & AWS Route 53 Automates DNS switching for Blue-Green

NGINX & HAProxy Manages traffic between environments

What skills are required to prepare for this question?

●​ Understanding deployment strategies (Blue-Green vs. Canary).

●​ Experience with Load Balancers (AWS ELB, NGINX, Istio).
●​ Hands-on experience with Kubernetes rolling updates and traffic routing.
●​ Knowledge of CI/CD pipelines that automate Blue-Green Deployment.

How to study this question?

●​ Deploy a Blue-Green environment in AWS using Route 53 and ELB.

●​ Implement Blue-Green Deployment in Kubernetes using Services and Ingress.
●​ Set up CI/CD with Jenkins or GitHub Actions to automate Blue-Green switching.
●​ Read case studies from Netflix, Spotify, and Uber on Blue-Green deployments.

Examples for this question

●​ AWS Blue-Green Deployment using Route 53​

Unset
resource "aws_route53_record" "blue_green" {

zone_id = "Z123456789"

name = "app.example.com"

type = "A"

alias {

name = aws_lb.green_lb.dns_name

zone_id = aws_lb.green_lb.zone_id

evaluate_target_health = true

}
 }

●​ ​
This Terraform setup switches traffic from Blue to Green using Route 53.​

●​ Kubernetes Blue-Green Deployment using Services​

Unset
apiVersion: v1

kind: Service

metadata:

name: my-app

spec:

selector:

app: my-app-green # Switch from my-app-blue to my-app-green

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ ​
This updates Kubernetes Service to direct traffic to the Green environment.​

44. What is a Service Mesh, and why is it important in Kubernetes?

Question

What is a Service Mesh, and why is it important in Kubernetes?

Answer
A Service Mesh is a dedicated infrastructure layer that manages service-to-service communication
in a microservices architecture. It provides observability, security, and traffic control without
changing application code.

In Kubernetes, a service mesh helps manage complex microservices by handling service discovery,
load balancing, security policies, retries, and observability at the network layer.

How a Service Mesh Works

●​ Uses a sidecar proxy (like Envoy) deployed alongside each service pod.
●​ Controls traffic between microservices (e.g., retries, failovers, rate limiting).
●​ Provides mTLS encryption for secure service communication.
●​ Collects metrics, logs, and traces for better observability.

Why is a Service Mesh Important?

✅✅Better Security – Encrypts service-to-service traffic with mTLS (Mutual TLS).​

✅
✅
Traffic Management – Enables circuit breaking, retries, and rate limiting.​
Observability & Monitoring – Provides distributed tracing, logging, and metrics.​

✅ Canary & Blue-Green Deployments – Enables progressive traffic shifting.

Load Balancing & Failover – Automatically routes traffic to healthy instances.​

Popular Service Mesh Tools

Tool Features

Istio Most popular, uses Envoy proxy

Linkerd Lightweight, simple to use

Consul Supports multi-cloud, service discovery

Kuma Built on Envoy, supports Kubernetes and VMs

AWS App Mesh Native AWS service mesh solution

Service Mesh vs. API Gateway

 Feature Service Mesh API Gateway

Traffic Control Manages service-to-service Manages traffic from clients to backend

traffic services

Security Enforces mTLS, service Provides authentication, rate limiting

authentication

Load Balancing Built-in (per-service) Manages incoming traffic load

Observability Distributed tracing, logging Request logging, analytics

What skills are required to prepare for this question?

●​ Understanding microservices communication challenges.

●​ Experience with Kubernetes networking (Ingress, Services, Sidecars).
●​ Hands-on experience with Istio, Linkerd, or Consul.
●​ Knowledge of mTLS, circuit breaking, retries, and observability tools.

How to study this question?

●​ Deploy Istio in a Kubernetes cluster and secure traffic with mTLS.

●​ Implement traffic shifting for Canary Deployments using a service mesh.
●​ Use Prometheus and Grafana for monitoring service-to-service traffic.
●​ Read case studies on how service mesh is used in large-scale systems (Google, Lyft,
Airbnb).

Examples for this question

●​ Istio Service Mesh Deployment​

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:
 name: my-app

spec:

hosts:

- my-app.default.svc.cluster.local

http:

- route:

- destination:

host: my-app

subset: v1

weight: 80

- destination:

host: my-app

subset: v2

weight: 20

●​ ​
This routes 80% of traffic to v1 and 20% to v2, enabling Canary Deployment.​

●​ Linkerd Service Mesh Installation (Lightweight Alternative to Istio)​

Unset
linkerd install | kubectl apply -f -

linkerd check

linkerd dashboard
 ●​ ​
This installs Linkerd on Kubernetes for lightweight service-to-service communication.​

45. What is Infrastructure as Code (IaC), and how does it benefit DevOps?
Question

What is Infrastructure as Code (IaC), and how does it benefit DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure (servers,
networks, databases) using declarative or script-based configuration files instead of manual
processes. IaC ensures consistent, repeatable, and automated infrastructure management.

Key Benefits of IaC in DevOps

✅✅Automation & Consistency – Eliminates manual configurations, reducing human errors.​

✅
✅
Faster Deployments – Automates provisioning, reducing setup time from hours to minutes.​
Version Control & Auditing – Infrastructure changes are stored in Git, enabling rollback.​

✅ Scalability – Easily replicate infrastructure across multiple environments (Dev, Staging, Prod).​
Cost Efficiency – Optimizes resource usage by automating infrastructure provisioning and scaling.

Types of IaC Approaches

Approach Description Example Tools

Declarative Defines the desired state of infrastructure, and Terraform, AWS

the tool ensures it CloudFormation

Imperative Specifies step-by-step commands to configure Ansible, Chef, Puppet

infrastructure

Popular IaC Tools

Tool Features
 Terraform Cloud-agnostic, declarative syntax

AWS CloudFormation AWS-native, manages AWS resources

Ansible Agentless, imperative & declarative support

Puppet Configuration management for large

infrastructures

Chef Uses Ruby-based recipes for automation

IaC vs. Traditional Infrastructure Management

Feature IaC Traditional Approach

Provisioning Automated, script-based Manual configuration

Consistency Ensures identical Prone to drift &

environments inconsistencies

Scalability Easy replication & scaling Time-consuming manual setup

Rollback Version-controlled & trackable Difficult to undo changes

What skills are required to prepare for this question?

●​ Understanding IaC principles (Declarative vs. Imperative).

●​ Hands-on experience with Terraform, Ansible, or AWS CloudFormation.
●​ Knowledge of CI/CD integration for infrastructure automation.
●​ Familiarity with GitOps workflows for IaC versioning.

How to study this question?

 ●​ Deploy an EC2 instance using Terraform and Ansible.
●​ Implement AWS CloudFormation for automated infrastructure provisioning.
●​ Set up CI/CD pipelines for infrastructure updates using GitHub Actions or Jenkins.
●​ Read case studies from Netflix, Uber, and Google on IaC adoption.

Examples for this question

●​ Terraform Code for Deploying an EC2 Instance​

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "web" {

ami = "ami-12345678"

instance_type = "t2.micro"

tags = {

Name = "Terraform-Server"

●​ ​
This automates EC2 instance provisioning with Terraform.​

●​ Ansible Playbook for Configuring a Web Server​

Unset
- name: Install Apache

hosts: webservers
 tasks:

- name: Install Apache package

yum:

name: httpd

state: present

- name: Start Apache service

service:

name: httpd

state: started

●​ ​
This automates web server setup using Ansible.​

46. What is GitOps, and how does it enhance DevOps workflows?

Question

What is GitOps, and how does it enhance DevOps workflows?

Answer

GitOps is a DevOps practice that uses Git as the single source of truth for managing infrastructure
and application deployments. It enables declarative, version-controlled, and automated
deployments using pull-based workflows.

Instead of manually applying changes, GitOps tools (like ArgoCD or Flux) continuously monitor Git
repositories and apply changes automatically to the infrastructure or Kubernetes cluster.

Key Principles of GitOps

✅✅Declarative Configuration – Infrastructure and application states are defined in code.​

✅ Version Control – All changes are tracked in Git, enabling rollback and auditability.​

✅ Pull-Based Deployment – Agents running inside Kubernetes or cloud environments pull changes,
Automated Syncing – GitOps tools detect changes in Git and apply them automatically.​

reducing security risks.

GitOps vs. Traditional CI/CD

Feature GitOps Traditional CI/CD

Change Controlled via Git commits & PRs Manual pipeline triggers
Management

Deployment Pull-based (automated sync) Push-based (manual

Strategy triggers)

Security Git controls access, reduces external Requires external CI/CD

writes access

Rollback Easy rollback using git revert Requires manual

intervention

Best for Kubernetes, IaC (Terraform, Helm) Traditional app deployments

Popular GitOps Tools

Tool Features

ArgoCD Kubernetes-native, UI dashboard

FluxCD Lightweight, integrates with Helm

Jenkins X CI/CD automation with GitOps

Weave GitOps Enterprise-focused GitOps

platform
GitOps Workflow
1.​ Developers commit infrastructure/app changes to Git.
2.​ GitOps tool (e.g., ArgoCD) detects changes and syncs them with the cluster.
3.​ If drift is detected, GitOps reconciles state to match the Git repo.
4.​ Rollback is easy – just revert to a previous Git commit.

What skills are required to prepare for this question?

●​ Understanding GitOps principles and workflows.

●​ Hands-on experience with ArgoCD, FluxCD, or Jenkins X.
●​ Knowledge of Kubernetes, Helm, and Terraform for GitOps automation.
●​ Experience with CI/CD integration and Git branching strategies.

How to study this question?

●​ Deploy a Kubernetes application using ArgoCD and GitOps principles.

●​ Set up FluxCD to automate Helm chart deployments.
●​ Integrate GitOps with Terraform for infrastructure management.
●​ Read case studies on how GitOps improves DevOps workflows at scale.

Examples for this question

●​ ArgoCD GitOps Deployment for Kubernetes

Unset
apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: my-app

namespace: argocd

spec:

destination:

namespace: default

server: https://kubernetes.default.svc

source:

repoURL: https://github.com/my-org/my-repo.git
 targetRevision: main

path: k8s-manifests

syncPolicy:

automated:

prune: true

selfHeal: true

●​ This automates Kubernetes deployments using ArgoCD and GitOps.

47. What is Chaos Engineering, and why is it important in DevOps?

Question

What is Chaos Engineering, and why is it important in DevOps?

Answer

Chaos Engineering is the practice of intentionally injecting failures into a system to test its
resilience and identify weaknesses before they cause real outages. It helps teams build highly
available, fault-tolerant systems by simulating unexpected failures.

Chaos Engineering follows the principle:​

"If you don’t break your system intentionally, it will break unexpectedly."

Why is Chaos Engineering Important?

✅✅Identifies Weak Points – Exposes hidden failures before they occur in production.​

✅
✅
Improves System Resilience – Helps applications recover automatically from failures.​
Reduces Downtime Costs – Prevents expensive outages by testing failure scenarios early.​

✅ Enhances Monitoring & Observability – Ensures logging and alerts work as expected.​
Validates Auto-Healing & Redundancy – Tests failover strategies in a controlled way.

Common Chaos Engineering Experiments

Type of Failure Description

Pod/Instance Failure Kill random Kubernetes pods or EC2 instances

Network Latency Introduce delays in network communication

CPU/Memory Overload Simulate high resource consumption

Dependency Failures Block access to external services (e.g., databases,

APIs)

Regional Outages Disable an entire cloud region and test failover

Popular Chaos Engineering Tools

Tool Features

Gremlin Enterprise chaos testing platform

Chaos Monkey Netflix's open-source tool for killing random

instances

LitmusChaos Kubernetes-native chaos testing

AWS Fault Injection Simulator (FIS) AWS-native chaos testing for EC2, RDS, and
Lambda

Chaos Mesh Kubernetes-focused chaos testing framework

Chaos Engineering vs. Traditional Testing

 Feature Chaos Engineering Traditional Testing

Purpose Test real-world failures Test code functionality

Scope System-wide resilience Individual components

Execution Injects controlled failures Runs predefined test

cases

Automation Runs continuously in production Mostly pre-release

testing

Outcome Ensures fault tolerance Ensures correct behavior

What skills are required to prepare for this question?

●​ Understanding distributed systems and failure scenarios.

●​ Experience with Kubernetes, cloud infrastructure, and service dependencies.
●​ Hands-on knowledge of Chaos Engineering tools like Chaos Monkey, Gremlin, or
LitmusChaos.
●​ Familiarity with monitoring and logging (Prometheus, Grafana, ELK, AWS CloudWatch).

How to study this question?

●​ Implement Chaos Monkey on an AWS or Kubernetes cluster.

●​ Use LitmusChaos to inject failures into Kubernetes deployments.
●​ Test auto-scaling, failover, and self-healing strategies.
●​ Read case studies from Netflix, Google, and Uber on Chaos Engineering.

Examples for this question

●​ Injecting Pod Failures in Kubernetes using LitmusChaos​

Unset
apiVersion: litmuschaos.io/v1alpha1
 kind: ChaosExperiment

metadata:

name: pod-delete

namespace: litmus

spec:

definition:

scope: Namespaced

level: pod

selector:

apps: my-app

duration: "30s"

●​ ​
This randomly deletes a Kubernetes pod to test resilience.​

●​ Simulating High CPU Load Using Gremlin​

Unset
gremlin attack cpu --cores 2 --length 60

●​ ​
This stresses 2 CPU cores for 60 seconds to test system behavior.​

48. What is Blue-Green Deployment, and how does it work?

Question

What is Blue-Green Deployment, and how does it work?

Answer
Blue-Green Deployment is a zero-downtime deployment strategy where two identical environments
(Blue and Green) run simultaneously. One environment serves live traffic while the other is updated
with the new release. After successful testing, traffic is switched to the new environment, ensuring
seamless rollouts and instant rollbacks.

How Blue-Green Deployment Works

1.​ Blue Environment (Active) – Runs the current stable version.
2.​ Green Environment (Inactive) – Deploy the new version here.
3.​ Testing Phase – Run tests in the Green environment.
4.​ Traffic Switch – Route traffic from Blue to Green after successful validation.
5.​ Rollback (if needed) – If issues arise, instantly switch back to Blue.

Key Benefits of Blue-Green Deployment

✅✅Zero Downtime – No interruptions for end-users during deployment.​

✅ Instant Rollback – Quickly revert to the previous version if issues occur.​

✅ Isolated Testing – New version is tested in a production-like environment.​

Reduced Deployment Risks – Ensures a smooth transition without impacting users.

Blue-Green Deployment vs. Rolling Deployment

Feature Blue-Green Deployment Rolling Deployment

Traffic Cutover Switches 100% at once Gradual rollout

Rollback Instant (switch back) Slower rollback

Downtime Risk No downtime Minimal downtime

Complexity Requires extra resources Less

resource-intensive

Blue-Green Deployment in Kubernetes

Method 1: Using Kubernetes Services

●​ Deploy two versions (Blue & Green) as separate Deployments.

●​ Route traffic using a Kubernetes Service (switch between Deployments).

Method 2: Using Ingress Controllers

 ●​ Use an Ingress controller (like Nginx, Traefik) to manage traffic switching.

Popular Tools for Blue-Green Deployment

Tool Features

Kubernetes Service-based traffic switching

NGINX Ingress Load balancing between versions

AWS Elastic Load Balancer (ELB) Routes traffic between instances

Istio/Linkerd Service mesh for traffic shifting

Argo Rollouts Advanced Kubernetes deployment

strategies

What skills are required to prepare for this question?

●​ Understanding zero-downtime deployment strategies.

●​ Experience with Kubernetes, Ingress, and traffic routing.
●​ Hands-on experience with CI/CD tools (Jenkins, GitHub Actions, ArgoCD).
●​ Knowledge of load balancing and DNS switching.

How to study this question?

●​ Implement a Blue-Green deployment using Kubernetes Services.

●​ Test rollback strategies in a live Kubernetes cluster.
●​ Experiment with Argo Rollouts for traffic splitting.
●​ Read case studies from Netflix, Uber, and Google on Blue-Green strategies.

Examples for this question

●​ Blue-Green Deployment Using Kubernetes Services​

 Unset
apiVersion: v1

kind: Service

metadata:

name: my-app

spec:

selector:

app: my-app-green # Switch to "my-app-blue" for rollback

ports:

- protocol: TCP

port: 80

targetPort: 8080

●​ ​
This switches traffic between Blue and Green versions instantly.​

●​ Traffic Switching in AWS Using Route 53​

Unset
aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID \

--change-batch file://switch_to_green.json

●​ ​
This updates the DNS record to point to the Green environment.​

49. What is Canary Deployment, and how does it work?

Question

What is Canary Deployment, and how does it work?

Answer

Canary Deployment is a progressive deployment strategy where a new version of an application is

released to a small subset of users before rolling it out to everyone. This helps detect issues early
and minimizes risk.

Instead of deploying the update to all users at once, a small percentage (e.g., 5%) gets the new
version first. If everything works well, the rollout is gradually expanded.

How Canary Deployment Works

1.​ Deploy new version (Canary) alongside the old version (Stable).
2.​ Route a small percentage (e.g., 5%) of traffic to Canary.
3.​ Monitor performance, logs, and error rates.
4.​ Gradually increase Canary traffic if no issues are found.
5.​ Roll back instantly if failures occur or promote Canary to full production.

Key Benefits of Canary Deployment

✅✅Minimized Risk – Limits the impact of potential issues.​

✅ Faster Rollbacks – If issues occur, rollback affects only a small group.​

✅ Better User Experience – Reduces downtime and disruptions.​

Data-Driven Decisions – Monitors real-world impact before full rollout.

Canary Deployment vs. Blue-Green Deployment

Feature Canary Deployment Blue-Green Deployment

Traffic Strategy Gradual rollout (5%, 10%, 50%, 100%) Switches 100% instantly

Risk Level Low – minimal users affected Medium – entire switchover

Rollback Immediate, minimal impact Immediate, full rollback

Resource Usage Requires partial duplication Requires full duplication

Canary Deployment in Kubernetes

Method 1: Using Kubernetes Deployments

●​ Deploy two versions (Stable & Canary) as separate deployments.

 ●​ Use a Kubernetes Service to split traffic between them.

Method 2: Using Istio or Linkerd Service Mesh

●​ Route a percentage of traffic to the Canary version dynamically.

●​ Gradually increase Canary traffic based on success metrics.

Popular Tools for Canary Deployment

Tool Features

Argo Rollouts Kubernetes-native canary automation

Istio Service mesh with traffic splitting

NGINX Ingress Canary routing via weighted traffic

AWS ALB Weighted target group distribution

Flagger Automated Canary releases with Prometheus

monitoring

What skills are required to prepare for this question?

●​ Understanding progressive delivery strategies.

●​ Experience with Kubernetes, Ingress Controllers, and Service Meshes.
●​ Hands-on knowledge of Argo Rollouts, Istio, or Flagger.
●​ Familiarity with CI/CD tools for automated Canary releases.

How to study this question?

●​ Implement a Canary Deployment using Argo Rollouts in Kubernetes.

●​ Set up Istio or Linkerd for traffic percentage-based routing.
●​ Test rollback strategies and monitor Prometheus and Grafana metrics.
●​ Read case studies from Netflix, Spotify, and Google on Canary Deployments.

Examples for this question

●​ Canary Deployment Using Kubernetes and Istio​

Unset
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: my-app

spec:

hosts:

- my-app.example.com

http:

- route:

- destination:

host: my-app

subset: stable

weight: 90

- destination:

host: my-app

subset: canary

weight: 10

●​ ​
This routes 10% of traffic to the Canary version and 90% to Stable.​

●​ Canary Deployment in AWS Using Weighted ALB Target Groups​

Unset
aws elbv2 modify-target-group-attributes \
 --target-group-arn TARGET_GROUP_ARN \

--attributes Key=canary-weight,Value=10

●​ ​
This routes 10% of traffic to the Canary version using AWS ALB.​

50. What is Infrastructure as Code (IaC), and why is it important in DevOps?

Question

What is Infrastructure as Code (IaC), and why is it important in DevOps?

Answer

Infrastructure as Code (IaC) is the practice of managing and provisioning infrastructure using
declarative code instead of manual processes. With IaC, infrastructure resources (servers, databases,
networks) are defined in code, version-controlled, and deployed automatically.

IaC eliminates manual configuration, reduces human errors, and enables fast, consistent, and
scalable infrastructure management.

Types of IaC Approaches

Approach Description

Declarative Defines what the final infrastructure state should be (e.g., Terraform,
CloudFormation)

Imperative Defines how to achieve the desired infrastructure state (e.g., Ansible,
Python scripts)

Why is IaC Important?

✅✅Consistency – Ensures environments are identical across development, testing, and production.​

✅ Scalability – Quickly deploy and scale resources across cloud providers.​

Automation – Eliminates manual setup by automatically provisioning infrastructure.​
✅
✅ Version Control – Infrastructure configurations are stored in Git, enabling rollback.​
Faster Deployments – Reduces time to set up infrastructure from days to minutes.

Popular IaC Tools

Tool Type Features

Terraform Declarative Multi-cloud support, state

management

AWS CloudFormation Declarative AWS-native IaC tool

Pulumi Declarative + Uses programming languages for IaC

Imperative

Ansible Imperative Automates configuration management

Chef/Puppet Imperative Enforces configuration states

IaC vs. Traditional Infrastructure Management

Feature Infrastructure as Code (IaC) Traditional Infrastructure

Provisioning Speed Fast (automated) Slow (manual)

Configuration Drift Eliminated via version control High risk of misconfigurations

Scalability Easily scales using scripts Manual, error-prone scaling

 Reproducibility Identical environments every Hard to maintain consistency
time

Example of Infrastructure as Code Using Terraform

Terraform configuration for provisioning an AWS EC2 instance:

Unset
provider "aws" {

region = "us-east-1"

resource "aws_instance" "example" {

ami = "ami-0abcdef1234567890"

instance_type = "t2.micro"

tags = {

Name = "Terraform-Instance"

●​ Run terraform apply to deploy the infrastructure automatically.

●​ Easily modify or destroy infrastructure by updating the code.

What skills are required to prepare for this question?

●​ Understanding IaC concepts and benefits.

●​ Hands-on experience with Terraform, CloudFormation, or Ansible.
●​ Knowledge of cloud providers (AWS, Azure, GCP).
●​ Experience with CI/CD pipelines for automating IaC deployments.

How to study this question?

●​ Deploy infrastructure using Terraform or CloudFormation in AWS/GCP.

●​ Automate server configuration using Ansible or Chef.
 ●​ Implement IaC within a CI/CD pipeline (GitHub Actions, Jenkins).
●​ Read case studies from Netflix, Spotify, and Google on IaC adoption.

Examples for this question

●​ Using Ansible to Install and Configure Apache on a Server​

Unset
- name: Install Apache

hosts: webservers

become: yes

tasks:

- name: Install Apache

apt:

name: apache2

state: present

●​ ​
This playbook automates Apache installation on multiple servers.​

●​ Creating an S3 Bucket Using AWS CloudFormation​

Unset
Resources:

MyS3Bucket:

Type: AWS::S3::Bucket

Properties:

BucketName: my-iac-bucket

●​ ​
This provisions an S3 bucket automatically in AWS.​