Config File Roadmap: YAML, .env, and Cron for New DevOps Engineers

Every devops config files roadmap has to start with YAML, because almost everything downstream is written in it. Kubernetes manifests, GitHub Actions and GitLab CI pipelines, Docker Compose files, Ansible playbooks — the ecosystem converged on YAML over JSON for one reason: comments and a syntax that reads closer to plain English are worth the tradeoff for files humans hand-edit constantly, even though JSON is the friendlier format for machines to generate and parse.

That tradeoff comes with two gotchas worth learning before you hit them in production instead of in training. The first is whitespace significance — YAML uses indentation to express nesting, so a file with mixed tabs and spaces, or a list item indented one column off from its siblings, fails to parse in ways that look like nothing is wrong when you eyeball it. The second is the “Norway problem”: an unquoted no or yes in a YAML value gets parsed as the boolean false or true, not the string, which is exactly why a country code field containing NO(Norway's ISO code) has broken real parsers in the wild.

countries:
  - NO   # parses as boolean false, not the string "NO"
  - "NO" # quoted — parses as the string, correctly

Learning YAML's rules in full, plus how to move cleanly between YAML and JSON when a tool in your chain only speaks one of them, is covered in the YAML to JSON guide. Get comfortable there first — every later stage in this roadmap assumes you can read a YAML file without guessing at its structure.

Once you can read a config file, the next skill is knowing which values don't belong inside one. Database URLs, API keys, and anything that differs between local, staging, and production belong in environment variables, not hardcoded into YAML — and that's where a fresh set of parsing rules shows up, this time around .env files. This is the step where learn devops configuration stops being abstract and starts being the actual reason a service won't boot on a teammate's machine.

.envsyntax looks trivial and isn't: unquoted values are read literally, including trailing spaces; quoting changes whether escape sequences and variable expansion are honored; and multi-line values need explicit handling that most parsers get subtly wrong. The precise rules — what needs quotes, what a comment looks like, how to represent a value that spans multiple lines — are laid out in the dotenv file syntax guide.

The other half of this stage is diagnosis. “My environment variable isn't loading” is almost never a mystery once you know the short list of actual causes: the .envfile isn't in the working directory the process actually runs from, a shell-exported variable is shadowing the file's value (or vice versa, depending on load order), the variable name has a typo that differs only in case, or the framework in use requires a prefix like NEXT_PUBLIC_ to expose it to the client at all. The dotenv best practices guide walks through this exact troubleshooting sequence, along with what should never go in a checked-in .env file to begin with.

With static config and per-environment values under control, the next stage is time-based execution — the cron jobs, scheduled tasks, and Kubernetes CronJobs that run backups, send digest emails, and clean up stale data. This stage comes after environment variables deliberately: a scheduled job's command usually reads its config from the same .env-sourced values you just learned to trust, so debugging a cron job that fails silently means already knowing its environment is correct before you even look at its schedule.

Cron's 5-field syntax (minute, hour, day-of-month, month, day-of-week) is compact enough to memorize, but two things trip up almost everyone at some point. Step values like */15 and ranges like 1-5are straightforward once you've seen them written out. The genuinely surprising part is that when both day-of-month and day-of-week are restricted (neither is *), cron treats them as an OR, not an AND — a schedule meant to mean “the 1st of the month, if it's a Monday” actually runs on the 1st of every month and on every Monday, which is a far more frequent job than intended and a classic cause of unexplained load spikes.

0 0 1 * 1
# reads like "1st of the month, only if it's a Monday"
# actually means: run on the 1st of every month OR every Monday

Building and reading schedules like this by hand is error-prone enough that it's worth verifying every expression before it ships — which is exactly the workflow covered in the cron expression guide, including the field-by-field breakdown and the OR-not-AND behavior in more depth.

At this point you can read config, manage per-environment values, and schedule work correctly — the next decision is what actually runs all of it. This is where devops fundamentals for new engineers tend to get muddled into a false choice: Docker Compose or Kubernetes, as if picking one rules out the other. In practice they solve different problems at different points in a project's life, and most teams end up using both, just not for the same thing at the same time.

Docker Compose is the right tool for local development and small, single-host deployments — a single YAML file, no cluster to manage, and a container comes up in seconds. Kubernetes earns its complexity when you need production-grade scheduling: self-healing pods, rolling updates, horizontal autoscaling, and multi-node placement decisions that Compose was never designed to make. The realistic path for most projects is Compose first, for everything local and for a simple production deployment that doesn't yet need to scale, then a deliberate migration to Kubernetes once uptime and scaling requirements justify the operational overhead — not before.

The concrete tradeoffs — what each tool actually handles well, where the migration friction really is, and how to tell which stage your project is at — are covered in the Docker Compose vs. Kubernetes guide. Read it before you provision a cluster you don't need yet.

Once Kubernetes is actually the right call, the final stage in this yaml env cron for devops progression is writing manifests that apply cleanly and behave the way they read — which means everything from Stage 1's YAML rules now applies at full complexity, across multiple linked documents at once.

A minimal working setup is a Deployment, a Service, and a ConfigMap, and the gotchas that catch people here are specific and recurring. A Service's selectorhas to match the Deployment pod template's labels exactly — one mismatched key and the Service silently routes to zero pods, with no error, just failed connections. Resource requests and limits need correct units: 500m for half a CPU core is not the same as 500, and 128Mi for memory is not the same as 128M — get either wrong and the pod either never schedules or gets OOM-killed under real load.

# Service
spec:
  selector:
    app: orders-api   # must equal a label below, exactly

# Deployment
spec:
  template:
    metadata:
      labels:
        app: orders-api

The full set of applyable examples — Deployment, Service, and ConfigMap wired together correctly, with every one of these gotchas called out inline — is in the Kubernetes Deployment YAML example. By this stage you're no longer learning devops configuration in the abstract — you're shipping it.