Skip to content
tezvyn:
Menu

☁️DevOps & Cloud

Infrastructure, containers, CI/CD, and cloud

1173 bites

Test yourself: Top 30 DevOps & Cloud interview questions →Multiple choice, with the correct answer and why it is correct on every question. Free, no sign-in.

Everything in DevOps & Cloud, page 59

easy2 min read

.gitignore: Telling Git What to Ignore

A .gitignore file is a deny-list for your repository, telling Git which files and directories to intentionally leave untracked. Use it to keep build artifacts, log files, and local configs out of your commit history.

easy2 min read

Git Commit: A Snapshot, Not a Diff

A Git commit is a permanent snapshot of your entire project, not just the changes. It's a save point containing the full state of all files, linked to the previous commit to form a historical chain.

Distributed Version Control (DVCS): Everyone Gets a Copy
easy2 min read

Distributed Version Control (DVCS): Everyone Gets a Copy

A DVCS gives every developer a full, independent copy of the repository, history and all. This is Git's model, making commits and branches instant because they're local. The footgun: your local copy isn't the team's truth until you push and pull to sync.

Idempotency: Safe to Retry Automation
advanced2 min read

Idempotency: Safe to Retry Automation

Idempotent automation ensures an operation has the same effect whether run once or many times. This is vital for safely retrying failed CI/CD jobs or configuration scripts. The footgun: thinking it means 'no side effects'.

GitOps: Your Git Repo is the Single Source of Truth
advanced2 min read

GitOps: Your Git Repo is the Single Source of Truth

GitOps makes a Git repo the single source of truth for your infrastructure's desired state. An automated process makes production match what's declared in Git, enabling continuous deployment.

advanced2 min read

Immutable Infrastructure: Treat Servers Like Cattle, Not Pets

Immutable infrastructure means you never modify running servers. To deploy, you replace them with new ones built from a golden image. This is key for CI/CD and autoscaling, ensuring consistency. The footgun is configuration drift from manual, one-off fixes.

advanced2 min read

Pipeline as Code: Versioning Your Build Process

Treat your CI/CD pipeline not as clicks in a UI, but as a version-controlled file (Jenkinsfile) living with your code. This enables automated, reviewable build processes for every branch. The footgun is defining pipelines in the UI, creating a black box.

intermediate2 min read

Canary Release: Test New Code on Real Users, Safely

A canary release is like sending a canary into a coal mine: expose a new version to a small group of users to detect problems before a full rollout. It's used to safely test changes in production by gradually shifting traffic.

Blue-Green Deployment: Zero-Downtime Releases
intermediate2 min read

Blue-Green Deployment: Zero-Downtime Releases

Run two identical production environments, Blue (live) and Green (new). To deploy, just flip a switch routing traffic to Green. This enables zero-downtime releases and instant rollbacks. The footgun is using DNS for the switch, which can lag due to caching.

intermediate2 min read

Infrastructure as Code: Manage Servers with Code, Not Clicks

Infrastructure as Code (IaC) treats servers and networks like software: defined in files and versioned in Git. It's used to automate cloud resource provisioning on AWS or GCP, ensuring consistent, repeatable environments.

intermediate2 min read

Artifact Repository: Your CI/CD's Private Library

An artifact repository is your CI/CD's private library for build outputs like packages and images. CI pipelines publish artifacts here, and deployment scripts pull from it.

easy2 min read

Automated Testing: Catch Bugs Before They Ship

Automated testing is like a robot QA engineer checking every code change instantly. It's the engine of CI/CD pipelines, running tests on every commit to give developers immediate feedback on business risks.

easy2 min read

Build Automation: The Engine of CI/CD

Build automation is a repeatable script that turns source code into a runnable application. It's the first step in any CI/CD pipeline, compiling code and running tests. The main footgun is creating brittle scripts that only work on one developer's machine.

We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.

See open roles