Knowledge check

Check your knowledge

Choose an answer to see why it is right or wrong.

JavaScript is off, so every explanation is shown at once.

1. 01A service needs the base URL of a downstream API, which differs between staging and production. How should this value be expressed?

   • As a deployment parameter in the typed config layer, supplied by the per-environment overlay - it is likely to vary between deploys.Correct. A hostname or URL that changes between staging and production is a deployment parameter, so it lives in the typed config layer and is set by the overlay that loads for that environment.
   • As a named const in code, because a URL is a fixed string once written.Incorrect. Code constants are for domain invariants that are identical in every environment. A URL that differs between staging and production hard-binds the code to one environment, which the 12-Factor litmus test forbids.
   • As a SecretRef, because any external endpoint should be treated as sensitive.Incorrect. A SecretRef is for credentials, keys, and tokens. A base URL is not a secret; making it one would send a non-secret through the secret-resolution path unnecessarily.

2. 02In the Cogitave precedence chain, which source wins when the same key is set in both config.{env}.toml and a COG_* environment variable?

   • The COG_* environment variable, because it comes later in the ordered chain (defaults, config.toml, config.{env}.toml, COG_* env vars, then CLI arguments).Correct. Providers are ordered and later overrides earlier, so a COG_* env var overrides the committed overlay - and a CLI argument would override the env var.
   • The config.{env}.toml overlay, because a committed file is more authoritative than a runtime environment variable.Incorrect. The chain is ordered by precedence, not by whether a source is committed. The env var comes after the overlay and therefore wins.
   • Whichever is loaded first, because the first provider to set a key locks it.Incorrect. The chain is last-wins, not first-wins: built-in defaults load first precisely so that every later layer can override them.

3. 03At startup a service finds that a required config value is missing and a SecretRef cannot be resolved against the store. What should it do?

   • Fail closed - refuse to start and emit a precise, layer-attributed error naming what was wrong.Correct. Cert-grade config means never running misconfigured. Both a missing required value and an unresolvable secret reference cause the process to refuse to start with a precise error.
   • Start anyway using a built-in default for the missing value and an empty string for the secret, then log a warning.Incorrect. A default may never mask a required or environment-specific value, and an empty secret would let the service run in a broken, insecure state - the exact silent-acceptance failure the standard exists to prevent.
   • Start in a degraded read-only mode and retry resolving the secret on each request.Incorrect. The standard is fail-closed at the boundary: config is parsed once at startup into a value that cannot be invalid, not re-checked per request. An unresolvable secret means the service does not start.

4. 04How does dotenvx let a team commit .env files to git without leaking secrets?

   • It encrypts the values with a committed DOTENV_PUBLIC_KEY; only the matching DOTENV_PRIVATE_KEY - kept out of git in .env.keys and held in the secret store in production - can decrypt them at runtime.Correct. The public key lets anyone add and encrypt values, the encrypted .env is safe to commit, and decryption requires the private key, which is a runtime secret held in the store and fetched via OIDC in CI.
   • It strips secret values out of the .env at commit time and stores them in the git config instead.Incorrect. dotenvx does not move secrets into git config; that would still place plaintext secrets in the repository. It encrypts the values in place so the committed file carries only ciphertext.
   • It adds .env to .gitignore so the file is never committed at all.Incorrect. The point of dotenvx is that the encrypted .env is committed and reviewable. It is the private key file .env.keys that is gitignored, not the encrypted .env.