ETE Practice Questions

DevOps is a culture, movement, and practice that emphasizes the collaboration and communication of both software developers and IT professionals while automating the process of software delivery and infrastructure changes.

To understand DevOps, one must understand the CAMS model:

• Culture: The most critical aspect involves breaking down silos between Dev and Ops, fostering open communication, and creating a "blameless post-mortem" environment.
• Automation: Removing manual, repetitive tasks (e.g., testing, deployment) to increase speed and consistency.
• Measurement: Using data (metrics) to monitor system health, deployment frequency, and failure rates to drive improvement.
• Sharing: Knowledge, tools, and successes are shared across teams to create collective intelligence.

• Waterfall: A linear and sequential model where Operations is involved only at the end. It carries a high risk of failure during deployment due to the "big bang" release approach.
• Agile: Focuses on software iteration and development speed. However, it often ignores the operational aspect (deployment and maintenance), leading to a bottleneck at the release stage.
• DevOps: Extends Agile principles beyond "code complete" to production deployment and monitoring. It bridges the gap between development and operations to ensure continuous delivery.

The Left Side of the infinite loop represents the development phase:

1. Plan: Defining business value and requirements. Tools: Jira, Trello.
2. Code: Software design and coding where code is pushed to a repository. Tools: Git, VS Code.
3. Build: Compiling code into an executable format. Tools: Maven, Gradle.
4. Test: Automated testing (Unit, Integration, UAT) to ensure quality. Tools: Selenium, JUnit.

The Right Side of the infinite loop represents the operations phase:

1. Release: Managing, scheduling, and controlling build updates to production. Tools: Jenkins, GitLab CI.
2. Deploy: Provisioning infrastructure and moving software to production. Tools: Ansible, Terraform, Docker.
3. Operate: Application maintenance and configuration management. Tools: Kubernetes, Chef.
4. Monitor: Tracking system health and user experience to provide feedback to the Plan phase. Tools: Nagios, Prometheus, Splunk.

The Wall of Confusion arises from conflicting goals:

• Dev Goal: Introduce change (new features) as fast as possible.
• Ops Goal: Maintain stability (avoid change to prevent outages).

DevOps bridges this gap via:

1. Shared Responsibility: Developers are responsible for their code in production ("You build it, you run it").
2. Shift Left: Testing and security checks move earlier in the lifecycle.
3. Feedback Loops: Monitoring data flows back to Devs.
4. Infrastructure as Code (IaC): Operations work becomes code-based, allowing shared tools.

Microservices Architecture breaks an application into small, independent services rather than a single massive application (Monolith).

Characteristics:

• Loosely coupled (can change one without breaking others).
• Independently deployable.
• Organized around business capabilities.

Benefit to DevOps: It enables small, frequent deployments. If one microservice fails, the whole application does not crash, supporting the goal of agility and stability.

VCS is critical for DevOps because:

1. Source of Truth: It holds the definitive version of application code and infrastructure code (IaC).
2. Collaboration: It allows multiple developers to work simultaneously without overwriting each other.
3. Traceability: Every change is logged with the author, timestamp, and reason, enabling audit trails and easier rollback.

1. Legacy Infrastructure: Moving from on-premise, monolithic systems to cloud-native microservices is risky and difficult.
2. Tool Complexity: Integrating disparate tools (the "DevOps Toolchain") like Jira, Jenkins, and Kubernetes requires significant effort.
3. Security (DevSecOps): Integrating security checks without slowing down the rapid deployment pipeline.
4. Skill Gaps: Difficulty in finding professionals who possess both coding skills and infrastructure management knowledge.

Technical Benefits:

• Continuous Delivery: Software is deployable at any time.
• Less Complexity: Incremental changes are easier to manage than "big bang" releases.
• Faster Resolution: Lower Mean Time To Recovery (MTTR) via automated rollbacks.

Business Benefits:

• Faster Time to Market: Features reach customers quickly.
• Stability: High deployment rates with rigorous testing lead to stable environments.
• Resource Efficiency: Automation frees engineers for innovation.

Cloud Computing is the on-demand delivery of IT resources over the Internet with pay-as-you-go pricing.

NIST Characteristics:

1. On-Demand Self-Service: Users provision resources automatically without human interaction.
2. Broad Network Access: Capabilities are available over the network via standard devices.
3. Resource Pooling: Multi-tenant model where resources are pooled to serve multiple consumers.
4. Rapid Elasticity: Resources scale outward and inward rapidly based on demand.
5. Measured Service: Resource usage is automatically metered and optimized.

• IaaS (Infrastructure as a Service): Provides fundamental building blocks like VMs, networking, and storage. User manages OS and apps. (e.g., AWS EC2, Google Compute Engine).
• PaaS (Platform as a Service): Provides a platform for developing and managing applications without worrying about infrastructure. (e.g., AWS Elastic Beanstalk, Heroku).
• SaaS (Software as a Service): Completed software run and managed by the provider, accessed via browser. (e.g., Gmail, Slack, Salesforce).

Virtualization creates a simulated version of hardware/OS using software. The Hypervisor is the software layer that coordinates VMs and assigns hardware resources.

• Type 1 (Bare Metal): Installs directly on hardware. Highly efficient. Used in enterprise data centers (e.g., VMware ESXi).
• Type 2 (Hosted): Runs as an application inside an existing OS. Used for personal desktops (e.g., Oracle VirtualBox).

1. Speed of Deployment: Cloud enables instant server provisioning, complementing DevOps automation.
2. Scalability: Cloud automatically scales resources for microservices.
3. Infrastructure as Code (IaC): Cloud allows infrastructure to be defined and versioned by code.
4. Automation: Cloud APIs allow tools like Jenkins to programmatically control infrastructure.
5. Cost Efficiency: Eliminates CapEx and allows testing environments to be spun down to save OpEx.

• Regions: Physical geographic locations (e.g., US-East-1) that are completely independent of each other.
• Availability Zones (AZs): Discrete data centers within a Region. Each AZ has redundant power and networking. They provide high availability.
• Edge Locations: Endpoints used for caching content (via CloudFront) to reduce latency for end-users.

• Continuous Delivery: Code changes are automatically prepared for release to production after passing CI. However, there is a manual approval step before the code goes live.
• Continuous Deployment: An extension of Continuous Delivery where every change that passes the automated pipeline is released to customers automatically without human intervention.

Continuous Integration (CI) is a practice where developers integrate code into a shared repository frequently (several times a day).

Process: Commit -> Automated Build -> Automated Tests.
Goal: The primary goal is to Fail Fast, detecting integration errors and bugs as quickly as possible to reduce debugging time.

• chmod (Change Mode): Changes file permissions.
  • Example: chmod 755 script.sh (Sets Read/Write/Execute for owner, Read/Execute for others).
  • chmod +x filename (Makes a file executable).
• chown (Change Owner): Changes the owner and group of a file.
  • Example: chown user:group filename.

Process Management:

• top: Displays a dynamic real-time view of running processes.
• ps: Displays currently running processes (ps aux for details).
• kill [PID]: Terminates a process by ID.

Networking:

• ping [host]: Checks connectivity to a host.
• netstat: Shows network statistics (ports, connections).

Infrastructure as Code (IaC) is the practice of provisioning and managing cloud resources using code and scripts (e.g., Terraform, CloudFormation) rather than manual configuration.

Benefits:

• Allows infrastructure to be version controlled alongside application code.
• Ensures consistency (eliminates configuration drift).
• Enables rapid, automated replication of environments.

Git is a free, open-source Distributed Version Control System (DVCS) created by Linus Torvalds.

Key Characteristics:

• Distributed: Every developer has a full copy of the project history, not just a checkout.
• Snapshot-based: Git stores data as snapshots of the filesystem, not just differences (deltas).
• Data Integrity: Uses SHA-1 hashes to checksum everything; history cannot be altered without detection.
• Performance: Most operations are local and fast.

1. Working Directory: The actual files you see and edit on your computer's filesystem (your sandbox).
2. Staging Area (Index): A file that stores information about what will go into the next commit. It acts as a loading dock.
3. Local Repository (.git directory): Where Git stores the metadata and object database (snapshots) for the project. This is the permanent history.

1. Modified: The file has been changed in the Working Directory but has not been committed to the database yet.
2. Staged: The modified file has been marked in its current version to go into the next commit snapshot.
3. Committed: The data is safely stored in the local database.

• Initialization: git init creates a new Git repository in the current directory.
• Configuration:
  bash
  git config --global user.name "Your Name"
  git config --global user.email "your.email@example.com"

• git fetch: Downloads new data from the remote repository to your local machine (updating remote-tracking branches) but does not integrate/merge it into your working files. It is safe and non-destructive.
• git pull: Fetches the data and immediately merges it into your current local branch. It is essentially git fetch + git merge.

1. The main branch represents the official project history.
2. Developers create a new branch (e.g., feature-login) for every new feature or bug fix.
3. Work is done, staged, and committed on this feature branch.
4. The branch is pushed to the remote repository.
5. A Pull Request (PR) is opened to merge the feature branch into main, facilitating code review before the merge.

• Create: git branch [name]
• Switch: git checkout [name] (or git switch [name])
• Create & Switch: git checkout -b [name]
• Merge: git merge [branch_name] (merges the specified branch into the current branch).

Traditional VCS stores data as a list of file-based changes (Deltas). Git thinks of its data as a series of Snapshots of a miniature filesystem.

• Every commit takes a picture of what all files look like at that moment.
• If a file hasn't changed, Git doesn't store the file again; it just stores a link to the previous identical file, making it efficient.

The Forking Workflow is common in Open Source projects where developers do not have write access to the main repository.

1. Developer forks (copies) the repo to their own account.
2. Clones their fork, makes changes, and pushes to their fork.
3. Creates a Pull Request from their fork to the original repository for the maintainer to review and merge.

• git diff: Shows changes in the Working Directory that are not yet staged.
• git diff --staged: Shows changes that are staged and ready to be committed (compared to HEAD).
• git diff branch_A..branch_B: Shows the difference between two branches.

• Fast-Forward: Occurs when the current branch tip is a direct ancestor of the target branch. Git simply moves the pointer forward. No new commit is created.
• Three-Way (Recursive): Occurs when branches have diverged (both have new unique commits). Git finds a common ancestor and creates a new Merge Commit with two parents to join the histories.

A Merge Conflict occurs when Git cannot automatically merge branches because the same part of the same file was modified differently in both.

Resolution:

1. Git pauses the merge and marks files with conflict markers (<<<<, ====, >>>>).
2. The developer manually edits the file to select the correct code.
3. The developer stages the file (git add) and commits it to complete the merge.

Rebasing rewrites the commit history to produce a straight, linear succession of commits. It takes changes from one branch and replays them on top of another.

Difference:

• Merge: Preserves history exactly as it happened (traceability) but can lead to a messy graph.
• Rebase: Creates a clean, linear history but alters the commit history (rewrites it).

Never rebase commits that exist outside your repository (public/shared commits).

Since rebasing changes the commit Hash ID, performing it on shared code will cause chaos for other developers whose history will no longer match the remote repository.

Stashing temporarily shelves changes in the working directory (dirty state) so you can switch branches to work on something else, and re-apply the changes later.

Commands:

• git stash: Save changes to the stack.
• git stash list: View stored stashes.
• git stash pop: Apply the stash and remove it from the stack.
• git stash apply: Apply the stash but keep it in the stack.

Tags mark specific points in history as important (e.g., releases like v1.0).

• Lightweight Tags: A simple pointer to a commit (like a branch that doesn't move).
• Annotated Tags: Stored as full objects in the Git database. They contain the tagger's name, email, date, a message, and can be GPG signed. Created using git tag -a.

This command displays the commit history in a visual graph format.

• --oneline: Shows abbreviated commit hash and message.
• --graph: Draws an ASCII graph representing the branch and merge history.
• --all: Shows history for all branches, not just the current one.

Interactive Rebasing (git rebase -i) opens an editor allowing you to modify commits as they are replayed. It is used to clean up history.

Actions:

• Pick: Keep the commit.
• Reword: Change the message.
• Squash: Combine the commit into the previous one.
• Drop: Delete the commit.

DevSecOps integrates security practices within the DevOps process.

Shift-Left Security means moving security checks to the earlier stages of the lifecycle (to the "left" of the timeline) rather than checking only at the end. This ensures code is secure before deployment, reducing the cost and time of fixing vulnerabilities.

AIOps (Artificial Intelligence for IT Operations) involves using AI and Machine Learning to analyze big data from monitoring tools.

Role: It helps predict outages, automates root cause analysis, and optimizes resource allocation, moving operations from reactive to proactive.

GitOps is a practice where Git repositories serve as the single source of truth for both infrastructure and application code. Changes to infrastructure are made via pull requests in Git, and automated tools (like ArgoCD) sync the live environment to match the Git state.

1. Continuous Integration (CI): Triggered by code commit. builds and tests code.
2. Continuous Delivery (CD): Triggered by successful CI. Deploys to staging. Requires manual approval for production.
3. Continuous Deployment: Triggered by successful staging tests. Automatically deploys to production without human intervention.

• Pipeline Management: Building CI/CD pipelines.
• Automation: Scripting repetitive tasks.
• Infrastructure Management: Managing cloud resources.
• Monitoring: Ensuring system availability.
• Collaboration: Bridging the gap between Dev and Ops.
• Security: Integrating security into the pipeline.

A T-shaped skill set implies:

• Deep knowledge (Vertical bar): Proficiency in one specific area (e.g., Coding or Systems Administration).
• Broad knowledge (Horizontal bar): General knowledge across other disciplines (Cloud, Networking, Testing, Security) to facilitate collaboration and understanding of the full lifecycle.

Jenkins is an open-source automation server used for CI/CD.

Architecture:

• Master (Controller): The brain of Jenkins. It holds the configuration, schedules builds, and dispatches jobs to agents.
• Slave (Agent): A separate machine (or container) that executes the build instructions sent by the Master to offload the workload.

• Dockerfile: A text file containing instructions to build an image.
• Image: A read-only template that includes the application and its dependencies.
• Container: A runnable instance of an image. It is the actual operating environment.

Kubernetes is an open-source container orchestration system for automating the deployment, scaling, and management of containerized applications.

Pod: The smallest deployable unit in Kubernetes. It represents a single instance of a running process and can contain one or more containers that share storage and network.

• Puppet:
  • Architecture: Master-Slave (Agent-based).
  • Model: Pull Model (Agents poll the master for updates).
  • Language: Ruby-based DSL.
• Ansible:
  • Architecture: Client-only (Agentless).
  • Model: Push Model (Control node pushes config via SSH).
  • Language: YAML.

Nagios is a monitoring tool used to track the health of systems, networks, and infrastructure.

Status Codes:

• OK (0): Service is working fine.
• WARNING (1): Issue detected but not yet critical.
• CRITICAL (2): Service is down or severe issue.
• UNKNOWN (3): Cannot determine status.

Apache Maven is a project management and build automation tool (primarily for Java).

POM (Project Object Model): The fundamental unit of work in Maven. It is an XML file (pom.xml) that contains information about the project, configuration details, and dependencies used by Maven to build the project.

1. Easier Build Process: Creates a standard way to build projects.
2. Uniform Build System: Allows developers to move between projects without learning new structures.
3. Quality Project Information: Manages dependencies, changelogs, and reports.
4. Better Practices: Enforces modular design and separation of source code from build output.

• Ant: A procedural tool. You must write scripts to tell Ant exactly what to do and when (e.g., mkdir, compile, copy).
• Maven: A declarative tool. You define what you want (via the POM), and Maven handles the "how" using its built-in lifecycle and conventions.

1. validate: Checks if the project is correct and all information is available.
2. compile: Compiles the source code.
3. test: Runs unit tests using a testing framework.
4. package: Takes compiled code and packages it into a distributable format (JAR/WAR).
5. install: Installs the package into the local repository for use as a dependency in other projects.

Selenium is an open-source framework for automated testing of web applications.

Integration: It is integrated into CI tools like Jenkins. After a build is deployed to a test environment, Jenkins triggers Selenium scripts to run functional/UI tests. If tests fail, the pipeline stops, ensuring quality control.

Serverless Computing is a cloud execution model where the cloud provider (like AWS Lambda) dynamically manages the allocation of machine resources.

• Developers run code without provisioning or managing servers.
• It reduces operational overhead and costs (pay only for compute time used).

• Prometheus: A monitoring system that collects metrics from configured targets at given intervals. It is excellent for storing time-series data.
• Grafana: A visualization tool that connects to data sources (like Prometheus) to create dashboards and graphs, allowing teams to visualize system health and trends.

• Commit: A static snapshot of the project at a specific point in time. It contains a pointer to the parent commit, an author, and a message.
• Branch: A lightweight, movable pointer to a specific commit. It allows you to diverge from the main line of development and continues moving forward as you make new commits.

Configuration Management automates the maintenance of servers in a desired state (e.g., ensuring Nginx is installed and running on all web servers).

Importance: It eliminates manual configuration, prevents "configuration drift," and ensures consistency across Dev, Test, and Prod environments.
Tools: Ansible, Puppet, Chef.

Shift-Left testing involves moving testing phases to the earlier stages of the software development lifecycle (towards the "Plan" and "Code" phases).

Instead of waiting for a dedicated QA phase at the end, automated unit and integration tests are run immediately upon every code commit. This catches bugs early when they are cheaper and easier to fix.