Secrets and Configuration in Cloud Deployments
Summary
This note explains the difference between ordinary configuration and sensitive secrets in cloud deployments. The goal is to make deployment design safer by separating what can be exposed publicly from what must be protected and controlled.
Why this matters
- many early cloud mistakes happen because secrets are treated like normal config values
- deployment pipelines become risky when credentials are copied between local machines, repos, and portals
- safer configuration habits make troubleshooting easier because the access path is clearer
Environment / Scope
| Item | Value |
|---|---|
| Topic | configuration and secret handling |
| Best use for this note | understanding what should and should not be stored in deployment config |
| Main focus | app config, secrets, environment variables, secret stores |
| Safe to practise? | yes |
Core distinction
| Type | What it is | Typical example |
|---|---|---|
| Configuration | non-sensitive values that define behaviour | region, feature flag, API base URL |
| Secret | sensitive value that grants access or should stay private | API key, database password, client secret |
Mental model
Think about deployment inputs like this:
normal config
-> shapes behaviour
secret
-> protects accessThe key question is not only “does the app need this value?” but also “what happens if this value is exposed?”
Everyday examples
| Situation | Better handling model |
|---|---|
| app needs to know which region to use | normal configuration |
| function needs a storage key or client secret | secret store or managed identity path |
| CI pipeline needs deployment credentials | protected pipeline secret or workload identity |
| app has different values in dev and prod | environment-specific config, with secrets separated from plain settings |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”If it is in an environment variable, it is automatically safe” | env vars are only a delivery mechanism, not a security model |
| ”Config files are fine if the repo is private” | secrets still spread too easily through history and reuse |
| ”One secret for every environment is simpler” | separation is safer and makes incidents easier to contain |
| ”Local testing secrets can be reused in CI” | local and pipeline trust boundaries are different |
Practical checks
Before finalising a deployment, ask:
- which values are plain config and which are secrets?
- where are secrets stored?
- who or what can read them?
- can managed identity or role-based access replace stored credentials?
- are dev, lab, and production values separated clearly?
Good habits
- keep secrets out of normal markdown notes, repos, and screenshots
- separate config review from secret review
- prefer secret stores or workload identity over copied credentials
- keep environment names and scopes clear
- document the access model without exposing the secret itself
Key takeaways
- configuration and secrets are related but should not be treated the same way
- safer deployments come from separating behaviour settings from access-sensitive values
- identity design, secret handling, and deployment workflow all affect each other