CKAD Services and Networking Practice Question
You apply the following Ingress manifest: ``` apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: ingressClassName: nginx rules: - host: app.example.com http: paths: - pathType: Prefix path: / backend: service: name: app-svc port: number: 80 ``` What is missing to enable TLS termination for this Ingress?
⚠ Common exam trap
A common mix-up: candidates think TLS termination is automatically enabled by the ingress controller or that a ConfigMap can hold certificates, but Kubernetes explicitly requires a `tls` section and a Secret of type `kubernetes.io/tls` for this purpose.
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
✓
Add `tls` section under spec with hosts and secretName
D is correct because TLS termination in Kubernetes Ingress requires a `tls` section under `spec` that specifies the `hosts` and a `secretName` referencing a Kubernetes Secret containing the TLS certificate and private key. Without this section, the Ingress will only serve HTTP traffic, even if an ingress controller like nginx is used.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create a ConfigMap with the TLS certificate
Why it's wrong here
ConfigMaps are designed for non-sensitive configuration data such as environment variables or plain text settings. A TLS certificate and private key are sensitive credentials that must be stored in a Kubernetes Secret of type kubernetes.io/tls, specifically containing tls.crt and tls.key. The Ingress controller only looks for a referenced secretName in the tls block; it will never read certificate material from a ConfigMap. Placing the certificate in a ConfigMap would not meet the Ingress API contract and would also violate security best practices by exposing the private key in plaintext.
- ✗
Set `service.beta.kubernetes.io/load-balancer-source-ranges` annotation on the Service
Why it's wrong here
The annotation service.beta.kubernetes.io/load-balancer-source-ranges is used only on a Service of type LoadBalancer to restrict the client IP address ranges that are allowed to reach the backend. It controls network access at the load balancer level and has no relationship to TLS termination or certificate configuration. TLS termination is handled by the Ingress controller using the tls section of the Ingress spec, not by annotations on the backend Service. Therefore, adding this annotation would do absolutely nothing to enable HTTPS on the Ingress.
- ✗
Change the Ingress API version to extensions/v1beta1
Why it's wrong here
The extensions/v1beta1 API version for Ingress is deprecated and has been completely removed in Kubernetes 1.22 and later, so changing to it is not a viable solution. Even when it was available, that version's Ingress spec still required an explicit tls block under spec to configure TLS termination; merely switching the API version does not magically enable TLS. The presence or absence of a tls section is what determines TLS behavior, regardless of the API group or version used. Relying on a deprecated API version would likely cause an error or, at best, leave the Ingress without TLS.
- ✓
Add `tls` section under spec with hosts and secretName
Why this is correct
To expose a service over HTTPS, the Ingress manifest must include a tls section directly under spec that lists the hosts to be covered and the secretName referencing a TLS secret. The secret must exist in the same namespace as the Ingress and contain the certificate and private key in the expected format. This tls block instructs the Ingress controller to terminate TLS by decrypting incoming HTTPS traffic for the specified hosts and forwarding plain HTTP to the backend service. Without this section, even if you have a valid certificate in a Secret, the Ingress will only serve plain HTTP.
Go deeper
Related to this question
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.