Module 10: Configuration & Environments | AZD for Beginners

"Dev, test, production — same app, different settings. azd environments keep them cleanly separated so you never deploy to the wrong place."

Level: Beginner · Time: ~2 days · Prerequisites: Module 5

Learning Objectives

By the end of this module, you will be able to:

Explain what an azd environment is
Manage multiple environments (dev, prod)
Set and read environment variables
Keep configuration out of your code

An azd environment is a named set of settings and deployed resources — like dev, staging, or prod. Each has its own subscription, region, resource names, and variables. Switching environments lets you deploy the same code to different places without changing anything in your app.

azd keeps each environment in a local .azure/<name>/ folder that holds its variables and a pointer to its subscription and region. Switching environments is really just azd pointing at a different one of these folders, which is why the swap is instant and safe.

Concept: One codebase, many environments. Your app doesn't know or care whether it's running in dev or prod — the environment supplies the differences (which database, which keys, which region).

2. Managing Environments

azd tracks environments for you:

bash

azd ,[object Object], list           ,[object Object],
azd ,[object Object], new staging    ,[object Object],
azd ,[object Object], ,[object Object], prod    ,[object Object],

Whatever environment is selected is where the next azd up or azd deploy goes. Creating an environment doesn't deploy anything by itself — it just sets up the target. The first azd up afterward is what actually provisions resources into it.

Common mistake: Deploying to the wrong environment because you forgot which was selected. Run azd env list (the current one is marked) before a production deploy — a two-second check that prevents a bad afternoon.

3. Environment Variables

Each environment stores variables — connection strings, endpoints, feature flags. azd captures outputs from provisioning (like a database URL) as env vars and injects them into your app at deploy time.

bash

azd ,[object Object], ,[object Object], FEATURE_NEW_UI ,[object Object],
azd ,[object Object], get-values

This closes a common gap: your app needs the database's address, but that address doesn't exist until provisioning creates it. azd captures it as an output and hands it to the app as a variable, so you never copy-paste connection strings by hand.

Explain like I'm new: Environment variables are sticky notes attached to each environment. The dev note says "use the test database"; the prod note says "use the real one." Your app just reads whichever note is present.

4. Config Belongs Outside Code

The golden rule: never hard-code settings. Read them from environment variables so the same build runs anywhere. azd wires the right values into each environment automatically.

Bad	Good
`db = "prod-server;pw=123"` in code	`db = env("DATABASE_URL")`
Different code per environment	One codebase, per-env variables

This "build once, run anywhere" rule is also what makes automated pipelines work: the exact same artifact promotes from dev to prod untouched, with only its variables changing.

Try this: Look at where your app reads its database or API endpoint. If it's a literal string, that's a setting to move into an environment variable — the change that makes multi-environment deploys possible.

5. Secrets Stay Secret

Environment variables that are sensitive (keys, passwords) shouldn't sit in plain files. azd integrates with Azure Key Vault so secrets are stored securely and injected at runtime — the topic of the next module. Rather than store a secret as plain text, your Bicep grants the app permission to read it from Key Vault at runtime, so the value never lands in a file or a log.

Real-world use case: A team runs identical code in dev and prod. Dev points at a throwaway database and a test AI key; prod points at the real ones. Nobody edits code to switch — they just azd env select the target and deploy.

✅ Checkpoint

What is an azd environment?
Which command shows all environments and marks the current one?
Why should settings live in environment variables, not code?

Answers: 1) A named set of settings and deployed resources (e.g., dev, prod), each with its own subscription, region, and variables. 2) azd env list. 3) So one codebase runs anywhere; the environment supplies the differences without code changes.

Key Takeaway: An azd environment (dev, staging, prod) is a named bundle of settings and resources, so the same code deploys to different places. Manage them with azd env, store per-environment variables (which azd injects at deploy time), and keep all configuration out of your code. Sensitive values belong in Key Vault, covered next.

Further Learning

Part of "AZD for Beginners." Adapted from Microsoft's open AZD curriculum (MIT License).