Services and Networking →hardMultiple ChoiceObjective-mapped

CKAD Services and Networking Practice Question

An Ingress resource is defined as: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: test-ingress spec: rules: - host: example.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 80 tls: - hosts: - example.com secretName: tls-secret What must exist in the cluster for TLS termination to work?

⚠ Common exam trap

A common mix-up: candidates think TLS termination requires an IngressClass annotation or a ConfigMap, but the CKAD exam specifically tests that a Secret of type `kubernetes.io/tls` with the correct name and namespace is mandatory for TLS to work.

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

✓

A Secret named tls-secret of type kubernetes.io/tls in the same namespace

C is correct because TLS termination requires the actual TLS certificate and key to be stored in a Kubernetes Secret of type `kubernetes.io/tls`. The Ingress controller reads this Secret to terminate HTTPS connections, decrypting traffic before forwarding it to the backend service. Without this Secret, the Ingress controller cannot present a valid certificate to clients.

Answer analysis

Option-by-option breakdown

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

✗
An IngressClass annotation specifying the ingress controller
Why it's wrong here
An IngressClass annotation only tells the ingress controller which controller implementation (e.g., nginx, traefik) should process the Ingress resource. It has no role in supplying the TLS certificate or private key; without the actual secret containing the PEM data, the controller cannot terminate TLS. Moreover, a default IngressClass is often already configured, and even a correct class annotation will not make TLS work if the secret is missing.
✗
A ServiceAccount named tls-secret
Why it's wrong here
A ServiceAccount is a Kubernetes object that provides an identity for Pods to authenticate with the API server, often used for RBAC authorization. It is not designed to hold certificate or key material, and the ingress controller will never look for TLS data in a ServiceAccount. The existence of a ServiceAccount named tls-secret would neither satisfy the referenced secretName in the Ingress spec nor expose the required tls.crt and tls.key entries.
✓
A Secret named tls-secret of type kubernetes.io/tls in the same namespace
Why this is correct
The Ingress resource must reference a Secret of type kubernetes.io/tls in its spec.tls[].secretName field, and Kubernetes requires that Secret to exist in the same namespace as the Ingress. This Secret must contain the keys tls.crt and tls.key, holding the PEM-encoded certificate and private key. The ingress controller reads those exact keys to terminate HTTPS traffic, so creating this Secret in the correct namespace is the essential prerequisite for TLS to function.
✗
A ConfigMap named tls-secret with certificate data
Why it's wrong here
A ConfigMap is intended for non-confidential configuration data, but a TLS private key is highly sensitive and must never be stored in plaintext as a ConfigMap entry. The ingress controller specifically looks for a Secret of type kubernetes.io/tls, not a ConfigMap, and will ignore certificate data placed in a ConfigMap even if the keys are named correctly. Therefore, storing certificate material in a ConfigMap fails both the security requirement and the controller's expected resource type.

Go deeper

CKAD Services and Networking Practice Question

Why each option matters

Option-by-option breakdown

Related to this question