Devops
294 bites tagged Devops — interview questions with model answers, and 60-second explainers.
Dockerfile: The Recipe for Your Container
A Dockerfile is a recipe for building a container image. It's a text file of commands that automates an application's environment setup, ensuring it runs identically anywhere. The footgun is creating bloated images with unnecessary build tools.
Software Containers: Portable, Isolated Applications
Think of a container as a standardized box for your app, bundling its code and all dependencies. This lets you run it consistently anywhere, from your laptop to the cloud.
External Secrets Operator: Sync Secrets into Kubernetes
The External Secrets Operator (ESO) acts as a bridge, syncing secrets from an external store like Vault or AWS Secrets Manager into native Kubernetes Secrets. This keeps secrets out of Git and centralizes management.
AWS Secrets Manager: Stop Hardcoding Credentials
AWS Secrets Manager is a digital vault for your app's credentials. Instead of hardcoding API keys or database passwords, your app fetches them at runtime. It's used for storing sensitive data securely, with built-in rotation and auditing.
Configuration Drift: When Servers Go Rogue
Configuration drift is when a server's live settings diverge from your version-controlled 'source of truth.' This happens from manual hotfixes or inconsistent deployments, creating snowflake servers that are hard to debug.
Configuration as Code: Treat Your Settings Like Source Code
Configuration as Code (CasC) treats your settings like source code, storing them in version control. This ensures every environment is identical, with changes automatically tested and deployed via CI/CD.
The Twelve-Factor App: Store Config in the Environment
Your app's code is the blueprint; its config is the specific address and utility hookups. Store config—database URLs, API keys—in environment variables, not in the code. The footgun is hardcoding secrets, making your code base impossible to open-source safely.
Configuration Files: Separating Code from Settings
A config file separates a program's behavior from its code, allowing you to change settings like database URLs without recompiling. They're used for API keys, feature flags, and environment-specific values. The footgun is committing secrets to version control.
Cloud-Init: Bootstrapping Cloud Instances
Cloud-init is the script that runs on a generic VM's first boot to turn it into *your* server. It's used by cloud providers to apply your `user-data` (like SSH keys and startup scripts) at launch. The biggest footgun: it only runs once on first boot.
Open Policy Agent (OPA): Centralized Policy as Code
OPA decouples policy decisions from your app's code. Instead of scattering `if` statements, you query a central engine: 'Is this allowed?' It enforces rules in Kubernetes, CI/CD, and API gateways. A common footgun is only using it for yes/no decisions.
Terragrunt: A Thin Wrapper for DRY Terraform
Terragrunt is a thin wrapper for Terraform/OpenTofu that automates common tasks. Just add an empty `terragrunt.hcl` file to get features like automatic `init`.
Pulumi: Infrastructure as Code with Real Programming Languages
Pulumi is Infrastructure as Code using real languages like Python or TypeScript, not a special DSL. This lets you use loops, functions, and classes to define resources. The main footgun is writing overly complex, clever code that becomes unmaintainable.
Ephemeral Environments: A Staging Server for Every PR
Ephemeral environments are disposable, production-like test servers created for every pull request. They let developers test changes in isolation without waiting for a shared staging server, catching integration bugs earlier.
Infrastructure Drift: When Reality and Code Diverge
Infrastructure drift is when live systems no longer match their configuration code. This happens when someone manually changes a cloud resource instead of updating the Terraform file. The footgun: your next `terraform apply` may destroy your manual changes.
Ansible: Automating Infrastructure with Playbooks
Ansible is like a recipe book for your servers. You write simple "playbooks" describing a desired state, and Ansible makes it happen over SSH without installing agents. It's ideal for configuration management, app deployment, and orchestrating workflows.
Terraform State: The Map to Your Infrastructure
Terraform state is the source of truth mapping your code to real cloud resources. It's used on every `plan` and `apply` to determine changes. The footgun: never store state in Git or edit the `tfstate` file directly; this risks corruption and secret leaks.
AWS CloudFormation: Your AWS Infrastructure as a Blueprint
AWS CloudFormation is your infrastructure's blueprint. Declare AWS resources in a YAML/JSON file, and AWS builds it. This is perfect for creating repeatable, version-controlled environments.
Terraform: Manage Infrastructure as Code
Terraform lets you define cloud infrastructure—servers, databases, networks—in a text file, like a blueprint. It reads this file and builds everything for you, making setups on AWS, GCP, or Azure repeatable.
Dynamic Pipelines: Parent-Child vs. Multi-Project
Break up monolithic CI/CD pipelines into smaller, independent ones. Use parent-child pipelines for dynamic jobs in one project (like a monorepo), or multi-project pipelines to coordinate across repos. The footgun: the parent pipeline doesn't wait by default.
Pipeline Templates: Reusable CI/CD Building Blocks
Think of pipeline templates as versioned, shareable functions for your CI/CD. Instead of copy-pasting YAML, you import a standardized block of logic for tasks like security scanning or deployment.
Self-Hosted Runners: Bring Your Own CI/CD Hardware
A self-hosted runner is your own machine executing CI/CD jobs, giving you full control over its environment and network. Use it for private network access or custom hardware. The footgun: you are now responsible for all security, updates, and maintenance.
Jenkins Shared Libraries: Don't Repeat Your Pipeline Code
Jenkins Shared Libraries let you centralize and reuse Pipeline code, just like a common function library. Use them to define standard build or deployment stages across many projects.
Secrets Management in CI/CD Pipelines
Treat secrets like temporary keys, not permanent passwords. Your CI/CD pipeline should fetch them just-in-time from a central vault, never storing them in code. The biggest footgun is storing secrets as long-lived environment variables in the CI tool itself.
CI/CD Pipelines: How Stages and Jobs Orchestrate Work
Think of a CI/CD pipeline as an assembly line. Stages are sequential stations (Build, Test, Deploy), while jobs are the parallel tasks at each station. This model automates software delivery. The footgun: a single failed job halts the entire line by default.
Get Devops bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.