CKS Practice Question: Which TWO of the following are recommended…

Answer analysis

Option-by-option breakdown

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

• ✗

  Set --cors-allowed-origins=* for easy access.

  Why it's wrong here

  Setting --cors-allowed-origins=* on the API server allows any web application origin to make cross-origin HTTP requests against it. With a wildcard, browsers enforce no same-origin restriction, and if credentials such as cookies or bearer tokens are present, malicious pages can trigger state-changing requests on behalf of an authenticated user, effectively enabling CSRF attacks. You should instead explicitly list trusted origins or omit CORS entirely for internal clusters.

• ✗

  Disable TLS to improve performance.

  Why it's wrong here

  Disabling TLS on the API server eliminates encrypted communication, exposing all transmitted data—including authentication tokens, secrets, and cluster configuration—to network eavesdropping and man-in-the-middle tampering. TLS also provides server identity verification, which is critical to prevent impersonation; modern CPUs handle TLS computationally inexpensively, so the performance gains are negligible. Kubernetes requires secure communication for all control-plane components, and without TLS the cluster cannot meet basic security standards.

• ✓

  Enable audit logging.

  Why this is correct

  Enabling audit logging on the API server records a chronological, policy-filtered set of metadata and request/response details for every administrative and user action. These logs give operators visibility into who performed which operation, when it happened, and whether it was authorized, enabling rapid detection of anomalous behavior, insider threats, or attempted privilege escalation. Audit logs also serve as forensic evidence for incident response and are a prerequisite for satisfying compliance frameworks that demand traceability of cluster changes.

• ✗

  Set --insecure-port=8080 to allow non-TLS access.

  Why it's wrong here

  Binding the API server to --insecure-port=8080 exposes a plain-HTTP endpoint that bypasses authentication and authorization, allowing any network-reachable client to issue arbitrary API calls without credentials. This port has long been deprecated and is disabled by default in modern Kubernetes because it creates a critical privilege-escalation and data-exposure risk. You must leave the insecure port off and rely solely on the secure port (6443) that enforces TLS, authentication, and authorization.

• ✓

  Set --anonymous-auth=false.

  Why this is correct

  Setting --anonymous-auth=false configures the API server to reject all requests that do not provide valid user credentials instead of mapping them to the built-in system:anonymous user. By default, anonymous authentication, combined with overly permissive RBAC bindings, can inadvertently grant unauthenticated clients access to cluster resources; disabling it eliminates that entire attack vector. This is a recommended hardening step because it forces every request to prove identity, reducing the likelihood of unauthorized access through misconfiguration.

Go deeper

Related to this question