Secrets, Keys, and Credentials

How to distinguish passwords, API keys, tokens, encryption keys, certificates, and secrets-management controls.

Secrets management is often taught as “put secrets in a vault,” but that is only the start. You also need to know what kind of secret exists, who can read or use it, how it rotates, where it appears in logs or builds, and whether it should exist at all.

The most important distinction: some objects are credentials used to authenticate, while others are keys used to protect data. They may live in related systems, but their risk and recovery behavior differ.

Secret types

Item Main purpose Typical control
Password Human or account authentication hashing, MFA, policy, reset, monitoring
API key Application authentication or identification vault storage, rotation, scope, rate limits
Access token Short-lived API authorization expiry, audience, scope, revocation
Refresh token Obtain new access tokens strong storage, rotation, revocation
Private key Prove identity or decrypt/sign hardware protection where needed, strict access
Certificate Bind public key to identity issuance, trust chain, expiry, revocation
Encryption key Encrypt, decrypt, sign, or verify data KMS/HSM, access policy, rotation, separation of duties
Database credential Authenticate application to data store vault, dynamic credential, least privilege

Do not treat all of these as interchangeable strings. A leaked encryption key, leaked refresh token, and leaked API key create different response work.

The secret lifecycle

    flowchart LR
	  C["Create or issue"] --> S["Store securely"]
	  S --> U["Use through controlled path"]
	  U --> R["Rotate or renew"]
	  R --> V["Revoke or retire"]
	  V --> E["Audit and improve"]

The lifecycle must include retirement. A secret that is created, copied, and never removed becomes unmanaged infrastructure.

Vaults and key-management systems

A secrets manager or vault stores sensitive values and controls retrieval. A key-management system controls cryptographic keys and key operations. Some platforms combine these experiences, but the design questions differ.

Requirement Strong first fit
Store database password with rotation Secrets manager or vault
Let application decrypt data without seeing key material KMS/HSM-backed decrypt operation
Issue short-lived database credentials Dynamic secrets or brokered credentials
Protect signing key with hardware boundary HSM or managed HSM
Prevent administrators from reading protected data Separate key administration from data access

For exam scenarios, “encrypt it” is not enough. Ask who controls the key, who can use the key, who can read plaintext, and what evidence proves use.

Rotation and revocation

Rotation changes a secret or key on a schedule or after risk. Revocation invalidates a credential or trust state. They are related but not identical.

Rotation is useful when:

  • a secret may have been exposed
  • policy requires periodic change
  • an operator leaves a privileged role
  • a certificate nears expiry
  • an API key has been broadly copied

Revocation is urgent when:

  • a token is stolen
  • a certificate should no longer be trusted
  • a user or workload should immediately lose access
  • an integration is terminated

Some encryption key rotations affect only future data keys or key versions. Understand whether old data must be re-encrypted or whether older key versions remain needed for decryption.

Common traps

Trap Better reasoning
“Environment variables are always safe for secrets.” They can leak through process inspection, logs, crash dumps, and misconfigured tooling.
“A vault fixes overprivileged access.” The vault must have scoped access policy, audit logs, and rotation discipline.
“Delete old encryption keys after rotation.” Old data may require old key versions for decryption.
“Store secrets in source control because the repo is private.” Private repos leak, get cloned, and feed build artifacts.
“Admins who manage keys should also read all data.” Separation of duties can prevent key admins from becoming data readers.

Incident response habit

When a secret is exposed:

  1. Identify what the secret can access.
  2. Revoke or rotate it based on secret type.
  3. Search for copies in source, images, logs, build systems, and tickets.
  4. Review activity during the exposure window.
  5. Replace the pattern if the secret should have been a workload identity or dynamic credential.

Sample Exam Question

A container image accidentally includes a production database password. The password has already been pushed to several registries and used by running workloads. What is the strongest response?

A. Delete one local copy of the image and keep the password active
B. Rotate or revoke the database credential, redeploy workloads with a secure retrieval pattern, search for image and log exposure, and review database activity
C. Rename the password variable
D. Add a comment warning developers not to use the image

Best answer: B. The secret has escaped into build artifacts and runtime. The response must invalidate it, remove the unsafe delivery path, and review use.

Revised on Friday, September 11, 2026