Configuration 101: what did the program actually load?

Configuration means settings that control how a program runs. An attempt limit is ordinary configuration. A credential is sensitive configuration. Both might reach an application through environment variables, but they need different handling in logs, source control and access policy.

A process is one running instance of a program. An environment variable is a named text value available to that process. A dotenv file is a text file of name=value lines. It is an input to a loader, not the process environment itself. In this lab, Node's --env-file option performs the loading. A framework can have its own automatic loading and precedence rules; do not generalize this command's behavior to every framework.

Think of the same function run with different arguments: the implementation stays the same while inputs change its behavior. The analogy has a limit. Configuration often arrives when the application starts and remains in memory; it is not automatically refreshed with every request.

An SDK is another component. It uses the configuration your application supplies, then prepares a service request. Loading a nonempty credential does not prove that it is valid, scoped correctly or accepted by that service.

The fictional setting DEMO_MAX_ATTEMPTS is a limit from 1 to 5. The program reads it as text and explicitly converts a valid value to a number. DEMO_CREDENTIAL is generated inside the exercise. The output reports only credentialConfigured: true or false, never its value.

Follow this path: file and launch settings → process environment → application validation → allowlisted diagnostic. Precedence is the rule for deciding which source wins when two define the same name. For Node's --env-file, an inherited value takes priority over the file's value.

Do not confuse parsing with validation. A dotenv parser can load the word many. The application's startup rule still rejects it as an attempt limit. The rule names the expected range without echoing an arbitrary rejected input. A missing required credential also stops the example before client creation; there is no silent fallback to another account.

The script never creates a client or tries authentication. configuration-ready means only that this example's local startup checks passed. It is not a service-health result.

Download fde-configuration-lab.mjs into a new folder. Use Node.js 24 and an ordinary local terminal. The script creates one temporary folder, writes its own .env.demo, launches only its own worker and removes that folder afterward. Existing files, shell settings and deployment settings are unchanged. Children receive an explicit lab environment, not the parent terminal's environment. The temporary file uses owner-only permissions where the operating system supports them; this is still a teaching fixture, not a production secret store.

node --version
node fde-configuration-lab.mjs

Before running, predict each result. The JSON report is the actual output of local child processes, not expected-output text printed as though it were observed. Cases intentionally stop on missing or invalid settings; exit code 2 is this example's startup refusal. The overall command exits successfully when it completes the experiment, including those refusals.

Read inspectConfiguration first. It is the application rule. Then locate the env option passed to each child process and the --env-file argument. The script uses the current Node executable directly; it does not ask a shell to expand a command. The file-edit case uses a local inter-process message to coordinate when to reread the existing process environment. That message is a timing signal, not a file reload.

not-loaded: the process reports missing credential and invalid/missing limit, then exits 2. The nearby file did not load itself. file-loaded: input type is string, the validated limit is number 2, credential presence is true and exit is 0. Those are the startup conditions this app checks.

inherited-wins: the effective limit is 4, despite the file's 2. Diagnose the launch environment and its precedence before editing the same file repeatedly. invalid-string: the parser accepts text, while the application stops with maxAttempts: null. The diagnostic gives a fixed rule rather than copying an untrusted or potentially sensitive value into logs.

file-edit: the first process reports 2 before and after the driver edits the file. A newly launched process reports 5. This program does not reread the file after startup. Some applications implement reloads or watch configuration stores; those mechanisms need their own consistency, validation and failure behavior.

child-change: one child's own environment changes from 3 to 5. The next sibling reports 3. Neither the parent's launch dictionary nor the file was modified by that child change. A process-local assignment does not reconfigure every process or update a cloud deployment.

These observations establish behavior of this local program on the recorded Node version. They do not test a cloud secret manager, credential rotation, a framework's client bundling, provider authentication or multiple production replicas. Keep those receiving checks separate from the evidence this lab supplies.

Make two independent copies of the downloaded file. Never edit the generated credential or add a real one.

In the first copy, change INHERIT_OVERRIDE = true to INHERIT_OVERRIDE = false. Predict inherited-wins, run the copy and record its effective limit. It should now use 2 from the file because the competing launch value was removed. This explains the cause of the difference; merely changing the diagnostic would not repair it.

In the second copy, start from the original and change INVALID_ATTEMPTS = "many" to INVALID_ATTEMPTS = "3". Run again. The invalid-string case retains its case label but now passes the startup rule with number 3. It is the changed input and actual decision that matter, not the label. Explain why this still says nothing about credential validity.

Keep the original observations beside each changed-copy result. Record the exact constant you changed and one outcome you expected to remain unchanged. Do not combine the changes until you can explain each independently.

Create a small configuration card for an application you understand. Name each required setting, its purpose, its owner, where it comes from, which process consumes it and whether a change requires restart or explicit reload. Record types and safe ranges, loader precedence and a missing-setting response. For a credential, record the approved reference or delivery mechanism and a presence check; omit the value.

In a real project, keep sensitive files out of source control and use the organization's approved secret storage and workload identity mechanisms. A .env file is plain text, and placing a value in an environment variable does not make it encrypted or inaccessible. Avoid environment dumps, secrets in command arguments, browser-visible configuration, screenshots and diagnostic exports. An example file can document names with empty placeholders; a public example must not contain a usable credential.

For a deployment, distinguish settings supplied during a build from those supplied to the running service. Some toolchains substitute build-time values into generated browser code. A server credential belongs in a restricted server-side path, not a public browser bundle. Verify your actual framework's behavior and the intended running version; do not assume that changing one console setting updates every existing process.

Explain the fictional incident to a colleague: “The file says two, but this process received four from its launcher. I can show the effective nonsecret limit and whether the required credential is present. I do not need the credential value to diagnose precedence.” Then continue to the SDK lesson and distinguish configuration readiness from the first actual request.

Primary references checked 22 October 2026: Node.js 24 environment variables, process environment and Node's env-file option. The instruction and experiment here are original LockedIn Labs material.