Frequently Asked Questions About Sangam Mukherjee DevOps Beginner Blueprint
23 answers covering everything from basics to advanced usage.
// Basics
What does DevOps actually mean in one sentence?
DevOps is Development + Operations. Its three core advantages are: build faster, deploy safer, and easy to maintain. This shortest definition anchors everything in the blueprint — whenever a new tool is introduced, it's justified by returning to whether it makes you build faster, deploy safer, or maintain more easily.
What is the P0/P1 sensitivity mindset in DevOps?
P0/P1 applications are user-facing, revenue-critical products where downtime directly impacts the business. The mindset means treating every deployment decision through the lens of criticality: P0/P1 apps demand tight release flows, multiple staging environments, and zero casualness in production. This justifies every DevOps safeguard — staging environments and release gates exist because production casualness costs real money.
What baseline Linux commands do I need before touching DevOps tools?
Master these first: pwd (current path), ls / ls -l / ls -a (list files), cd (navigate), touch (create file), mkdir (create directory), rm and rm -r (delete file/directory), find [path] -name [filename] (locate files), and grep [string] [file] (search inside a file). These are mandatory baseline commands you need before any DevOps tooling makes sense.
What is the difference between the working directory, staging area, and commit in Git?
The working directory holds your local changes tracked by Git but unstaged. The staging area is where you snapshot changes ready for commit using 'git add .'. The committed state permanently records that snapshot with 'git commit -m'. Confusing staging with committing leads to partial or accidental commits — always check state with 'git status' before committing.
What makes a good Git commit message?
A good commit message describes what changed and why — for example 'payment feature for PayPal added' rather than vague messages like 'changes' or 'fix'. In a team context, vague messages make Git history unreadable and release tracking impossible. Clear messages let anyone scan the history and understand each snapshot's purpose at a glance.
// How To
How do I write and run a shell script for automation?
Follow four steps: (1) create the file with 'nano scriptname.sh'; (2) write the script starting with the shebang '#!/bin/bash', then commands, variables (NAME=value, echo $NAME), and conditionals; (3) make it executable with 'chmod +x scriptname.sh'; (4) run it with './scriptname.sh'. Use shell scripts to automate repeated command sequences like installs, config, backups, and cron jobs.
How do I set up a .gitignore file correctly?
Create a .gitignore file at the project root before any staging. Add node_modules/ immediately, then build/dist artefacts, environment files with sensitive data, and OS system files. Verify your tracked file count drops dramatically in your IDE after saving. The rule: anything you don't want public or that can be regenerated locally belongs in .gitignore.
How do I connect my local Git repo to GitHub and push?
Create a repository on GitHub, then link local to remote with 'git remote add origin [URL]'. Push with 'git push -u origin main'. Establish a branching strategy using separate branches for dev, stage, and prod — never commit directly to main/prod. Team members push to the shared repo and pull to get updated code locally.
How do I set up Continuous Integration with GitHub Actions?
Create a workflow file in .github/workflows/. Define a CI flow that triggers build and lint checks automatically on every push or PR. Add pre-commit hooks (Prettier/linting) to enforce code quality before code even reaches GitHub. CI sits in the Build and Test pillars — the goal is that every push is automatically validated with no manual build steps.
How do I deploy my Dockerised app to AWS EC2?
Create an AWS account and launch an EC2 instance. Install Docker and Docker Compose on the instance, then deploy your demo app containers on it. Access the running app via the instance's public IP. This step proves your app is environment-agnostic — the same Docker setup that ran locally now runs in the cloud identically.
How do I automate deployment so I never deploy manually again?
Extend your GitHub Actions workflow with a CD stage. Configure it so every push to main/prod automatically SSHs into the EC2 instance, pulls the latest image, and restarts the containers. After this, no manual deployment is ever required — push code and it deploys itself, completing the CI/CD pipeline in the Deploy pillar.
// Troubleshooting
Why did git init not track my server code?
You likely ran 'git init' inside a sub-folder like /client instead of the project root. This means the server side is never tracked by Git. Fix it by removing the misplaced .git folder, navigating to the project root (outside both client and server folders), and running 'git init' there so both are tracked together.
Why did node_modules get pushed to my repository?
You forgot to create .gitignore before your first 'git add .', so thousands of node_modules files got staged and pushed. This bloats the repo permanently — even deleting them later leaves them in history. Always create .gitignore with node_modules/ listed before your first staging. If already pushed, you'll need to untrack and rewrite history.
Why does my shell script fail with a permission error?
You didn't make the script executable before running it. Run 'chmod +x scriptname.sh' first, then execute with './scriptname.sh'. Without the executable permission, the script fails silently or throws a permission-denied error. This is one of the most common beginner mistakes with shell scripting on Linux and WSL.
Why won't my DevOps tools work properly on Windows?
You probably skipped WSL setup. Docker, Kubernetes tooling, and shell scripts are optimised for Linux environments, so running them natively on Windows creates friction. Install WSL via PowerShell with 'wsl --install' to get an Ubuntu distribution, then run all DevOps tooling inside that Linux environment.
// Comparisons
How is Docker different from Kubernetes?
Docker alone handles single-host container management — building, running, and orchestrating containers on one machine (with Docker Compose). Kubernetes handles orchestration across multiple hosts, providing high availability and scaling. Don't treat Kubernetes as a drop-in replacement for Docker Compose at the beginner stage; introducing it before Docker fundamentals are solid creates confusion.
How does this blueprint differ from just following tool documentation?
Tool docs teach one tool in isolation with no lifecycle context. This blueprint places every tool explicitly within the seven-pillar lifecycle, anchors it to one real demo app, and follows a Concepts → Flows → Apply rhythm. You learn why each tool exists and where it fits, not just how to run commands — avoiding the disengagement that comes from context-free theory.
Is Continuous Integration the same as Continuous Deployment?
No. Continuous Integration (CI) automatically builds and tests code every time you push, catching errors early in the Build and Test pillars. Continuous Deployment (CD) extends CI by automatically deploying validated changes to a target environment like EC2 without manual intervention, living in the Deploy pillar. CI verifies correctness; CD ships it.
// Advanced
Should I use Minikube or a cloud Kubernetes cluster to learn?
Use Minikube first. It runs a local, single-node Kubernetes cluster on your machine, letting you learn Deployment and Service manifests without needing a cloud-based cluster or incurring costs. Keep Kubernetes conceptual-heavy with practical basics at the beginner stage — deep Kubernetes and cloud clusters are later-part topics once fundamentals are solid.
How should I structure branches for dev, stage, and prod?
Use separate branches for dev, stage, and prod environments and never commit directly to main/prod. Developers work on named branches, raise pull requests to merge into higher environments, and code flows dev → stage → (pre-prod) → prod. This release flow enforces the P0/P1 mindset — user-facing apps get multiple staging gates before production.
How do I manage sensitive credentials in a DevOps pipeline?
Never push API keys, database passwords, or .env files to a public GitHub repository. List them in .gitignore and manage them via environment variables or a secrets manager. For CI/CD, use GitHub Actions secrets to inject credentials at runtime. Leaked credentials in public repos are one of the most damaging and common DevOps pitfalls.
How do I audit which DevOps pillars my project is missing?
Map your project explicitly to all seven pillars — Plan, Develop, Build, Test, Release, Deploy, Monitor — and mark which are currently manual, missing, or broken. For example, a solo dev deploying via FTP has Plan and Develop, but Build, Test, Release, Deploy, and Monitor are all manual or absent. This audit drives the rest of your workflow.
Does my specific tech stack change the DevOps steps?
No. Whether you use React + Node, or any equivalent front-end and back-end stack, the DevOps steps remain the same. Git initialisation, .gitignore, Docker containerisation, CI/CD, EC2 deployment, and Kubernetes all apply identically. The specific stack only affects details like which files go in .gitignore and what your Dockerfile installs — the sequence and lifecycle are stack-agnostic.