Secrets and API Key Management for the Developer Exam

The secret does not belong in the code

Every Claude application authenticates to the API with a key, and every integration accumulates other credentials: database passwords, third-party tokens, signing secrets. The single most important rule for all of them, and the one the Claude Certified Developer - Foundations (CCDV-F) exam returns to under Task Statement 7.4, is that the secret does not live in the source code. A key hard-coded into a file, or pasted into a prompt template, has become part of an artifact that is copied, cloned, logged, and shared far more widely than the key itself ever should be.

Instead the application reads its secrets at runtime from somewhere outside the source tree. In simple deployments that is an environment variable, set on the machine or the container and never written into the repository. In larger systems it is a dedicated secret manager, a service whose entire job is to hold credentials, hand them to authorised processes at runtime, and record who asked. Either way the principle is identical: the code references the secret by name, and the actual value is supplied from the environment. This is a direct expression of the secure-by-design thinking in secure-by-design and least privilege, where a credential is exposed to as few places, and as few people, as possible.

Why committing a key is worse than it looks

The intuition many developers start with is that a key in a private repository is fine, or that deleting the line later undoes the mistake. Both are wrong, and the exam tests candidates on exactly this misplaced confidence. Source control is designed to remember everything: even after you remove a key in a new commit, the old value is still sitting in the history, readable by anyone who clones the repository or browses back through it. Repositories also travel further than people expect, into forks, into CI systems, onto laptops, into backups. A key committed once should be considered exposed forever, which is why the only correct response to a committed key is to rotate it, not to quietly delete the line.

One key per environment, never shared

The second discipline is scope. Development, staging, and production each get their own key, and a key is not reused across services either. This containment is what limits the blast radius when something goes wrong. If a development key leaks, it should be able to do development things only, and revoking it should have no effect on production traffic. If one production key were shared across every environment and every service, a single leak would compromise all of them at once, and rotating it would mean coordinating a change everywhere simultaneously, which teams avoid precisely when they most need to act.

Separate keys also make monitoring meaningful. When each environment has its own credential, unusual usage on one of them points at a specific place to investigate, which is what authorized access monitoring depends on. A single shared key turns every anomaly into an undifferentiated blur. Scoped keys are therefore not just tidier, they are what make the later stages of access control - validating who is calling and watching how keys are used - actually work.

Rotation and revocation

The third discipline is that keys are not permanent. Rotation means replacing a key with a fresh one on a regular schedule, so that even a credential that leaked without anyone noticing has only a limited window in which it is useful. Because keys are read from the environment rather than baked into code, rotation is an operational change - update the secret store, restart or refresh the consumers - not a code change and redeploy. Designing for rotation from the start, with one key per environment pulled from a secret source, is what keeps it a routine operation rather than an emergency.

Revocation is rotation's urgent cousin. The moment a key is known or suspected to be exposed, in a commit, a log, a screenshot, a shared file, it is revoked so it stops working, and a new key is issued to the legitimate consumers. The mistake the exam highlights is leaving a leaked key active in the hope that the exposure went unnoticed. A leaked credential is compromised by definition, and the only safe assumption is that someone hostile has it.

The traps the exam sets

How it shows up on the exam

This is an understand-level knowledge point, so questions usually describe a handling practice and ask whether it is sound or how to correct it. The credited answers track three ideas: secrets stay out of code and are read from the environment or a secret manager, keys are scoped per environment rather than shared, and a leaked key is revoked and rotated rather than left active. Distractors offer the comfortable wrong answers - a key in a private repo is fine, deleting the line undoes a commit, one strong key everywhere is simpler. If you hold the three disciplines of storage, scope, and rotation in mind, those distractors are easy to strike out.