CKAD Application Deployment Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Defining the name of a Kubernetes resource.

  Why it's wrong here

  Defining the name of a Kubernetes resource is invalid because a resource's name is set in the required `metadata.name` field, which serves as the object's unique identifier within a namespace. Annotations are optional key-value pairs and cannot replace or override `metadata.name`; they are not used by the Kubernetes API for identification or routing. For example, `kubectl get pod` displays the name from `metadata.name`, never from an annotation.

• ✗

  Identifying which pods a Service should route traffic to.

  Why it's wrong here

  Identifying which pods a Service should route traffic to is invalid because Service-to-Pod selection relies exclusively on label selectors (`spec.selector`) that match pod labels, not annotations. Labels are designed to be queryable and selectable, whereas annotations are explicitly non-identifying metadata that are ignored by Service routing logic. A Service cannot use an annotation like `my-annotation: backend` to choose endpoints; only matching label key-value pairs create the endpoint slice.

• ✓

  Configuring ingress controllers with specific settings like rewrite rules.

  Why this is correct

  Configuring ingress controllers with specific settings like rewrite rules is a valid use of annotations because ingress controllers (e.g., NGINX, Traefik) are designed to read controller-specific annotations attached to the Ingress resource to customize routing behavior. For example, `nginx.ingress.kubernetes.io/rewrite-target` instructs the NGINX controller to rewrite request paths before proxying them to backend services. These annotations act as declarative configuration that the controller consumes, while the core Ingress spec remains portable across different controllers.

• ✓

  Storing non-identifying metadata such as build information or release notes.

  Why this is correct

  Storing non-identifying metadata such as build information or release notes is a valid use of annotations because Kubernetes defines annotations as a place to attach arbitrary key-value data that does not carry identifying semantics. Unlike labels, annotations are not used for grouping or selection; they are meant for tooling, automation, or humans to inspect. Common examples include `deployment.kubernetes.io/revision`, image commit hashes, or `kubernetes.io/change-cause` annotations, which help with auditability without affecting scheduling or routing.

• ✗

  Enabling service discovery between microservices.

  Why it's wrong here

  Enabling service discovery between microservices is invalid because Kubernetes service discovery is handled by DNS (e.g., `service.namespace.svc.cluster.local`), environment variables, and the cluster's internal kube-proxy/iptables or IPVS rules. Annotations are not part of the discovery mechanism—they are static metadata that is not resolved or queried by the kubelet or Service controller. Misusing annotations for discovery would fail because there is no API that reads annotations to populate DNS records or endpoint slices.

Go deeper

Related to this question