Quiz: Secrets Management¶
8 questions
L0 (1 questions)¶
1. Why are Kubernetes Secrets not truly secure by default?
Show answer
Kubernetes Secrets are only base64-encoded, not encrypted. Anyone with kubectl get secret access can decode them instantly. If the Secret YAML is committed to Git, the credential is in repo history forever. You need additional tooling (Sealed Secrets, SOPS, Vault, External Secrets Operator) for real secrets management.L1 (4 questions)¶
1. A developer committed an API key to git. What do you do?
Show answer
1. Revoke/rotate the key immediately (assume it's compromised).2. Remove from history with git filter-repo or BFG.
3. Add the pattern to .gitignore and set up pre-commit hooks (e.g., detect-secrets). History rewriting alone is not enough — the key is already exposed.
2. Where should applications get secrets at runtime instead of config files?
Show answer
Use a secrets manager: HashiCorp Vault, AWS Secrets Manager, or K8s external-secrets-operator. Inject via environment variables or mounted volumes. Never bake secrets into container images or git repos.3. What are common operational security mistakes in DevOps teams?
Show answer
1. Sharing credentials in Slack/email.2. Long-lived API keys with broad permissions.
3. No MFA on cloud consoles.
4. Running production workloads as root.
5. Not rotating secrets after employee departure.
6. Overly permissive security groups (0.0.0.0/0).
4. How does Bitnami Sealed Secrets solve the 'secrets in Git' problem?
Show answer
Sealed Secrets encrypts secrets with a cluster-specific public key. The developer creates a regular Secret, pipes it through kubeseal to produce a SealedSecret YAML, and commits that to Git. Only the Sealed Secrets controller running in the cluster has the private key to decrypt it. The SealedSecret is safe in Git because it can only be decrypted in that specific cluster.L2 (2 questions)¶
1. How do you handle secrets rotation with zero downtime?
Show answer
1. Add the new secret alongside the old one (dual-read).2. Update the app to accept both.
3. Roll out the new secret to all consumers.
4. Remove the old secret. For databases: create new credentials, update connection strings via rolling restart, then revoke old credentials.
2. What is the External Secrets Operator and when would you choose it over Sealed Secrets?
Show answer
ESO syncs secrets from external stores (AWS Secrets Manager, Vault, GCP Secret Manager) into Kubernetes Secrets. Choose ESO when: (1) you already have a centralized secret store, (2) you need dynamic/rotating secrets, (3) you manage secrets across multiple clusters, (4) you want a single source of truth outside Kubernetes. Sealed Secrets is simpler if you only need Git-safe secrets for one cluster.L3 (1 questions)¶
1. Design a secrets management strategy for a multi-cluster production environment using HashiCorp Vault. How do secrets get into pods?