CKS Minimize Microservice Vulnerabilities Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  kubectl get gatekeeper-constrainttemplates

  Why it's wrong here

  The resource name 'gatekeeper-constrainttemplates' does not exist in the Kubernetes API. Although Gatekeeper defines ConstraintTemplate custom resources, the correct plural form of the resource is simply 'constrainttemplates' — there is no 'gatekeeper-' prefix in the API resource name. Running kubectl with this invented plural will yield an error like 'the server doesn't have a resource type "gatekeeper-constrainttemplates"', even if the CRD is installed and active.

• ✗

  kubectl describe opa constrainttemplate

  Why it's wrong here

  The command 'kubectl describe opa constrainttemplate' is invalid because 'opa' is not a Kubernetes resource type. In kubectl syntax, the second positional argument after 'describe' is always interpreted as a resource type (or 'resource/name'), so kubernetes attempts to find a server-side resource named 'opa', which does not exist. Additionally, 'constrainttemplate' is the singular form; to list all constraints you must use the plural 'constrainttemplates', and there is no need to reference OPA, since Gatekeeper's CRDs make these resources natively visible to kubectl.

• ✓

  kubectl get constrainttemplates

  Why this is correct

  This is the correct command because 'constrainttemplates' is the exact plural name of the custom resource served by the Kubernetes API after Gatekeeper's CRD is installed. kubectl get constrainttemplates works without specifying a namespace because these resources are cluster-scoped, and it directly returns the actual instances of the ConstraintTemplate custom resource, not just the CRD definition. It leverages the standard dynamic API discovery mechanism, so no additional flags or 'opa' references are required.

• ✗

  kubectl get crd -o name | grep constraint

  Why it's wrong here

  While this pipeline will return lines of output for CRD definitions whose names contain 'constraint', it only lists the custom resource definitions themselves, not the live instances (ConstraintTemplate objects) that have been created. To retrieve the actual constraints, you need to query the resource type directly, e.g., kubectl get constrainttemplates; the 'get crd' command is for inspecting the schema, not the resource instances. Moreover, the output format '-o name' yields lines like 'customresourcedefinition.apiextensions.k8s.io/constrainttemplates.templates.gatekeeper.sh', which do not represent the individual constraint objects you want to view.

Go deeper

Related to this question