KCNA Cloud Native Architecture Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  In a configuration file that is version-controlled

  Why it's wrong here

  Version-controlled configuration files still bundle environment-specific values into the repository, so the same revision cannot be deployed unchanged across staging and production without branching or overrides. Twelve-factor mandates environment variables. Checked-in config files suit static, non-secret defaults that are genuinely identical in every deployment.

• ✗

  In a database table

  Why it's wrong here

  Storing configuration in a database table couples the app to a backing service before it can start, and credentials for that database must themselves be configured externally, creating a circular dependency. Environment variables are the twelve-factor answer. A database table suits shared, runtime-editable business settings rather than per-deployment connection strings.

• ✓

  In environment variables

  Why this is correct

  Storing configuration in environment variables satisfies the 12-factor requirement to strictly separate config from code, since values vary per deployment without code changes. Environment variables are language- and OS-agnostic, avoid committing credentials to version control, and allow the same build artefact to be promoted unchanged across environments.

• ✗

  Hard-coded in the application code

  Why it's wrong here

  Hard-coding connection strings means every deployment shares identical code, so promoting a build between environments requires editing and rebuilding source. Twelve-factor config belongs in environment variables, letting the same artefact run unchanged anywhere. Hard-coding suits fixed constants that never vary, such as a mathematical value or protocol name.

Go deeper

Related to this question