CKAD Application Deployment Practice Question
Which THREE of the following are valid reasons to use an annotation in Kubernetes?
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
✓
To store the name of the CI/CD tool that deployed the resource
Option B is correct because annotations are designed to hold non-identifying metadata such as tooling information, so recording the CI/CD tool that deployed a resource is a valid use. Option C is correct because annotations commonly store build versions or commit hashes for auditing and traceability, since this metadata does not need to be used for selection or scheduling. Option E is correct because the Kubernetes API explicitly defines annotations as a way to attach arbitrary non-identifying metadata to objects, which is their core purpose. Option A is not valid because Service Pod selection is performed with label selectors, not annotations, which cannot be used in selectors. Option D is not valid because container resource limits are set in the pod spec under resources.limits, not via annotations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
To enable a Service to select Pods based on the annotation value
Why it's wrong here
Service selectors match only labels, never annotations, so an annotation value cannot drive Pod selection. It is tempting because annotations and labels sit side by side in metadata, but only labels are indexed and queryable by selectors; annotations hold non-identifying metadata.
- ✓
To store the name of the CI/CD tool that deployed the resource
Why this is correct
Annotations hold non-identifying metadata that Kubernetes never uses for scheduling or selection. Recording the deploying CI/CD tool's name is purely informational, so it fits an annotation rather than a label, which must remain queryable and short.
- ✓
To record the build version or commit hash for auditing
Why this is correct
Annotations store arbitrary non-identifying metadata, so a build version or commit hash can be attached without affecting scheduling or selection. This satisfies the auditing requirement in the stem, since Kubernetes imposes no schema or validation on annotation values, unlike labels, which must be valid and are indexed for selectors.
- ✗
To set resource limits for a container
Why it's wrong here
Resource limits are enforced by the container's spec.containers[].resources.limits field, which the kubelet and scheduler read directly; annotations are non-enforcing metadata. Annotations suit descriptive data such as build IDs, contact details or tool configuration that Kubernetes itself does not act upon.
- ✓
To attach arbitrary non-identifying metadata to an object
Why this is correct
Annotations store arbitrary non-identifying metadata that Kubernetes itself never interprets, unlike labels, which are indexed and selectable by label selectors. This satisfies the stem's requirement for a valid annotation use: recording descriptive or tooling-specific data, such as build information or contact details, without affecting object identity or selection.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. 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.