CKAD Practice Question: Application Environment, Configuration and Security
Which command creates an Opaque Secret named 'my-secret' with key 'password' and value 'p@ssw0rd'?
⚠ Common exam trap
A common mix-up: candidates confuse the order of key and value in the `--from-literal` syntax, or mistakenly use a different secret type like TLS or docker-registry, which have specific purposes and required flags.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
kubectl create secret generic my-secret --from-literal=password=p@ssw0rd
`kubectl create secret generic` creates an Opaque secret, and the `--from-literal=key=value` syntax correctly assigns the literal value 'p@ssw0rd' to the key 'password'. This produces a secret with the specified key-value pair.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl create secret tls my-secret --cert=cert.pem --key=key.pem
Why it's wrong here
The `kubectl create secret tls` subcommand produces a Secret of type `kubernetes.io/tls`, which is distinct from the `Opaque` type requested in the prompt. Furthermore, it expects PEM-encoded certificate and key files to populate `tls.crt` and `tls.key`; even if those files existed, the resulting Secret would not contain the literal data the question asks for. To create an opaque Secret, the generic subcommand is required, not tls.
- ✗
kubectl create secret generic my-secret --from-literal=password
Why it's wrong here
The `--from-literal` flag requires the syntax `key=value`; providing only `password` omits the value after the `=` delimiter. Kubectl would either reject the argument as malformed or treat it as an incomplete key, so no secret data is actually defined. This command cannot succeed because literals must be explicitly paired with a corresponding value.
- ✗
kubectl create secret generic my-secret --from-literal=p@ssw0rd=password
Why it's wrong here
This option reverses the logical mapping: `p@ssw0rd` becomes the key and `password` becomes the value. The resulting Opaque Secret would store data under the key `p@ssw0rd` with the value `password`, which is the opposite of what was intended. Secret consumers expect the actual password to be associated with a meaningful key such as `password`, not the other way around.
- ✓
kubectl create secret generic my-secret --from-literal=password=p@ssw0rd
Why this is correct
This is the correct command because `generic` creates the default `Opaque` Secret type, and `--from-literal=password=p@ssw0rd` explicitly defines a data entry with key `password` and value `p@ssw0rd`. Kubectl will automatically base64-encode the literal value when the Secret object is stored in etcd. The syntax follows the required `key=value` format, making it the only valid option.
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.