Everything in CI/CD & Automation, page 12
Docker Compose: A Tool for Containerized Applications
Docker Compose is a tool in the Docker suite for running applications in containers. It ensures your app runs the same everywhere by packaging it with its dependencies, solving the 'works on my machine' problem.
Container Image: A Blueprint for Your Application
A container image is a static blueprint for your application, bundling code, runtime, and settings. You build images to ship software for Docker or Kubernetes, which then run them as live containers.
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.
Kubernetes Sealed Secrets: Git-Friendly Secret Management
Sealed Secrets let you safely commit encrypted Kubernetes secrets to a public Git repo. A one-way lockbox: anyone can add a secret, but only the target cluster can unlock it. Essential for GitOps, but remember: a Sealed Secret is tied to its cluster.
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.
Environment Variables: Configuration Outside Code
Environment variables are settings passed to your app from the outside world, letting you change behavior without touching code. Use them for API keys or database URLs. The biggest footgun is committing secrets to version control instead of using variables.
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.
Packer: Build Identical Machine Images Everywhere
Packer is a universal recipe for baking machine images. It takes a single template and builds identical images for multiple platforms like AWS or Docker. Use it to create consistent "golden images" for your infrastructure.
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