Phase 6: Cloud & Deployment Concepts · ~30 minutes · Python · environment variables

Environment Variables and Config, for Real

It works on your machine because a required setting has been sitting in your local shell for months. It fails the instant it reaches a fresh production environment that never had a reason to know that.

Hiring signal: Never hardcodes environment-specific config, and immediately suspects config drift when something only fails in production

What you will learn

Explain the Twelve-Factor App's config principle: behavior varies by environment variable, never by hardcoded value
Explain why secrets management is a real, non-optional practice
Refactor hardcoded configuration into environment-variable-driven configuration
Identify config drift as a likely cause when a bug only reproduces in production

Introduction

Type: Learn Languages: Python Prerequisites: Lesson 01 (What "The Cloud" Actually Is) Time: ~30 minutes

Objective

Learning objectives

Explain the Twelve-Factor App's config principle: behavior varies by environment variable, never by hardcoded value
Explain why secrets management is a real, non-optional practice
Refactor hardcoded configuration into environment-variable-driven configuration
Identify config drift as a likely cause when a bug only reproduces in production

What you're building

Take a script with hardcoded configuration:

DATABASE_URL = "postgres://localhost/myapp_dev"
DEBUG = True
MAX_CONNECTIONS = 10

A script (config_refactor.py) that:

Refactors every hardcoded value into os.environ.get(...) with a sensible development default, or os.environ[...] (no default) for anything that should never silently fall back
Runs correctly with no environment variables set (using defaults) and prints what it's using
Runs correctly with different real environment variables injected, and prints the different resulting behavior — confirm the same code genuinely behaves differently
Deliberately reproduces this lesson's config-drift KeyError for one required-with-no-default variable, and writes a comment explaining exactly why it worked in an earlier "session" and not this one

A script hardcodes API_KEY = "sk-abc123" directly in a .py file that gets committed to git. What are the two real problems with this, per this lesson and Phase 03?

Both lessons' concerns apply simultaneously here, and they're genuinely different problems. Phase 03's concern: once committed, this key is permanently retrievable from git history, regardless of any later deletion — a real, non-hypothetical security exposure. This lesson's concern, independent of the security issue: hardcoding it also means the exact same code can't correctly use a different key in a different environment without editing the source file, exactly the inflexibility the Twelve-Factor config principle exists to avoid. The fix for both is the same: read it from an environment variable, never commit the actual value.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.