Configuration Management

Configuration Management is 4.1 percent of the CCDV-F blueprint, a little over two of the 53 scored questions. Its scope is narrower than the name suggests: not infrastructure provisioning, but the values a running system reads and the discipline around changing them.

Start with an inventory, because the first thing this sub-skill tests is whether you recognise configuration when you see it. The model identifier is configuration. So are the effort level, the output cap, the timeout and retry counts, the tool set enabled for a given deployment, any beta feature flags in play, the endpoint the client talks to, and every toggle guarding a rollout. Prompts sit at the boundary: they are versioned artefacts belonging in the repository, and treating them as runtime settings someone can edit in a console is how teams lose their audit trail.

Credentials are configuration under stricter rules, and their mechanics are more interesting than candidates expect. The client libraries resolve credentials from several sources in a defined order, which means an unset environment variable does not imply the absence of a credential. Knowing that order turns a baffling authentication failure into a two-minute fix.

What the exam tests here

• •Telling configuration apart from code and from versioned content such as prompts
• •Why model identifiers are exact strings that should be pinned rather than assembled
• •The order in which client libraries resolve credentials, and what shadows what
• •Keeping environments separated with differences that are deliberate rather than accidental
• •Validating configuration at startup instead of discovering an invalid value on the first request
• •Managing beta feature flags and provider endpoints as versioned settings

Model identifiers are exact strings

An identifier is a literal the API either recognises or rejects with a not-found error. It is not a pattern you can extend. Appending a date suffix to a current identifier because older ones carried dates produces a request that fails, and platform variants differ in their own way, with some hosted providers prefixing the name and others separating a dated snapshot with a different character.

Two rules follow. Read the identifier from configuration so a change is a deploy rather than an edit across call sites. And pin it deliberately, because the alternative is a dependency that can move without your involvement. Log the identifier the response reports alongside the one you asked for; where a fallback or routing layer is in play they are not always the same string.

Credential resolution is an ordered chain

The absence of an API key in the environment does not mean there is no credential. The SDKs consult several sources in a fixed order and take the first that answers: an API key variable, then a bearer token variable, then a locally stored profile selected by name or by being active, then a federated workload identity assembled from its own variables, then the default stored profile.

Two consequences matter operationally. A stale key exported in a shell shadows a correctly configured profile, producing an authentication failure that looks inexplicable until you know the order. And a set profile name outranks the federation variables, so a half-migrated environment can authenticate as the wrong identity while appearing correctly configured.

Environments differ on purpose, and the differences are listed

Staging exists to differ from production in known ways and to be identical in every other respect. The known differences are usually the credential, the endpoint, the rate-limit ceiling, the log verbosity and sometimes a cheaper model tier. Everything else drifting is a bug in the making, because a defect that reproduces only in production is expensive exactly to the extent that nobody can enumerate what is different.

The practice worth naming is one schema for configuration with per-environment values, so adding a setting forces a decision everywhere rather than defaulting silently. Where a cheaper model runs outside production, treat that as a documented difference and remember that behaviour measured there does not transfer.

Fail at startup, not on the first request

Configuration errors found at boot are cheap; the same errors found under load are not. Validate on the way up: required values present, numeric values parsed and in range, the model identifier one this deployment expects, the endpoint well formed, and any beta flag in use paired with the code path requiring it. Refuse to start when something is missing rather than defaulting to a value that will surprise somebody later.

Beta flags deserve particular attention because they are version-coupled. A feature reached through a flag is tied to a specific flag string and a specific request shape, and pairing a flag with the wrong parameter form is rejected. Treat those pairs as a unit in configuration and in review.

Where candidates go wrong

Common questions