Courseiva

CKS Minimize Microservice Vulnerabilities Practice Question

You are deploying a ValidatingWebhookConfiguration. The webhook server is running in the 'webhook' namespace, service name 'svc', port 443. Which clientConfig should you specify?

⚠ Common exam trap

Common mistake: candidates may specify the wrong service name, using the webhook server's deployment name or pod name instead of the actual service name, or they may omit the 'path' field. Also, the namespace must match the service's namespace, not the default namespace.

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

✓

clientConfig: service: namespace: webhook name: svc path: /validate

A ValidatingWebhookConfiguration's clientConfig must reference the Kubernetes service that fronts the webhook server, specifying the service's namespace, name, and the path to the validation endpoint. Since the webhook server runs in the 'webhook' namespace with service name 'svc' on port 443, the service reference must use namespace: webhook and name: svc, with path: /validate. Kubernetes automatically resolves the service to its cluster-internal DNS name and uses the service's HTTPS port (443) when a service reference is provided.

Answer analysis

Option-by-option breakdown

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

  • ✓

    clientConfig: service: namespace: webhook name: svc path: /validate

    Why this is correct

    This is the correct configuration because the clientConfig.service block directly references the Service named `svc` in the `webhook` namespace, which is exactly where the webhook server is deployed. The API server will resolve this Service reference to a stable DNS name (`svc.webhook.svc.cluster.local`) and forward admission requests to the `path` `/validate` on that Service's HTTPS endpoint. Using the Service reference rather than a raw URL is the recommended Kubernetes pattern because it lets the API server automatically account for the Service's ClusterIP and the configured CA bundle.

  • ✗

    clientConfig: url: https://webhook.svc.cluster.local:443/validate

    Why it's wrong here

    While a raw `url` is accepted in a ValidatingWebhookConfiguration, this particular URL is incorrect for two reasons. First, the hostname `webhook.svc.cluster.local` would resolve to a Service named `webhook` in the `svc` namespace, inverting the actual service name and namespace of the deployed webhook (`svc` in `webhook`). Second, hardcoding the cluster domain makes the manifest environment-specific and fragile; the Service reference approach avoids this and is the standard. Therefore this option fails to target the running webhook.

  • ✗

    clientConfig: service: namespace: webhook name: webhook path: /validate

    Why it's wrong here

    This option selects the correct namespace, `webhook`, but specifies a Service name of `webhook` instead of the actual Service name `svc`. The Service backing the validation webhook is explicitly named `svc` in the deployment; a mismatch here means the API server will attempt to connect to a Service that does not exist, causing the webhook call to fail with a connection error. The Service name must exactly match the `metadata.name` of the Service object in that namespace.

  • ✗

    clientConfig: service: namespace: default name: svc path: /validate

    Why it's wrong here

    Here the Service name `svc` and path `/validate` are correct, but the namespace is set to `default`. The webhook's Service is deployed in the `webhook` namespace, so this configuration will cause the API server to look for a Service named `svc` in `default`, which is not the intended endpoint. As a result, admission requests that trigger this webhook will be unable to reach it, and depending on the failurePolicy, they may be denied or forced to bypass validation. The namespace field must match the Service's actual namespace.

Visual reference

Client Recursive Resolver Root DNS (13 root servers) TLD DNS (.com, .org, …) Authoritative example.com query IP addr answer

About these practice questions

This CKS question is part of Courseiva's 845-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

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.