CKS Cluster Setup Practice Question
A security audit reveals that the kube-apiserver is using the default insecure port 8080 on a production cluster. Which is the most secure and recommended remediation?
⚠ Common exam trap
CNCF often tests the misconception that simply changing the insecure port number or setting it to a non-default value is sufficient, whereas the only secure remediation is to disable it entirely with `--insecure-port=0` and explicitly enable the secure port.
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
✓
Set --insecure-port=0 and ensure --secure-port=6443 is configured
Setting `--insecure-port=0` disables the unencrypted HTTP port (default 8080), which eliminates the risk of unauthenticated access to the API server. Ensuring `--secure-port=6443` is configured enforces TLS-encrypted communication on the standard secure port, which is the only recommended and secure method for production clusters.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the --insecure-port flag to 0
Why it's wrong here
Setting --insecure-port=0 disables the HTTP listener on the kube-apiserver, but this alone does not guarantee that the API server is securely reachable. The control plane may still have the insecure port enabled via a separate bind address or default configuration, and without explicitly confirming --secure-port=6443 and its TLS settings, the remediation is incomplete. Therefore, while disabling the insecure port is a necessary step, it is insufficient as the 'most secure' fix.
- ✓
Set --insecure-port=0 and ensure --secure-port=6443 is configured
Why this is correct
Setting --insecure-port=0 disables the plaintext HTTP endpoint on the kube-apiserver, eliminating unauthenticated access. Simultaneously ensuring --secure-port=6443 is configured guarantees that all API communication is served over TLS on the standard secure port, using client certificate and token authentication. This combination is the recommended hardening measure per Kubernetes documentation.
- ✗
Set --insecure-port=6443
Why it's wrong here
Setting --insecure-port=6443 would expose the insecure, plaintext HTTP API on the default secure port, effectively replacing the TLS-protected endpoint with an unauthenticated one. This is critically dangerous because port 6443 is typically used for the secure API server, and doing so would allow unencrypted, unauthenticated access to the cluster, violating security best practices. The correct approach is to disable the insecure port entirely.
- ✗
Set --secure-port=8080
Why it's wrong here
Setting --secure-port=8080 reconfigures the TLS-serving port to 8080, but it does not disable the insecure port, which defaults to 8080 in some configurations. This can create a port conflict if the insecure listener is still active, or it may move the secure endpoint to a non-standard port without addressing the underlying plaintext listener. The most secure remediation must explicitly disable the insecure port (--insecure-port=0) and keep the secure port on its default 6443 with TLS, not just shift ports around.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 114 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 CKS 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 CKS exam.