Everything in DevOps & Cloud, page 55

Kubernetes Service: A Stable Address for Ephemeral Pods
A Kubernetes Service provides a stable IP address and DNS name for a group of ephemeral Pods. It acts like a load balancer, distributing traffic so you don't have to track individual Pod IPs, which can change at any time.

Kubernetes Deployment: Declarative App Updates
A Kubernetes Deployment is your app's blueprint. You declare the desired state—like '3 replicas of image v2'—and Kubernetes makes it happen. It's the standard for stateless apps like APIs. The footgun: don't manage Pods directly; manage the Deployment.

Kubernetes Pods: The Atomic Unit of Deployment
A Kubernetes Pod is the atomic unit of deployment, a logical host for containers sharing a network and storage. This is ideal for co-locating a main app with a helper "sidecar" container. The footgun: a Pod is not a container; you scale by adding more.
Kubernetes: The Operating System for Your Cluster
Think of Kubernetes as an OS for your entire datacenter. It automates deploying, scaling, and managing containerized applications across a fleet of servers. The footgun is adopting it for simple projects, where its complexity outweighs its benefits.

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.
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