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.

• ✗

  ingress: - from: - namespaceSelector: matchLabels: name: ingress podSelector: matchLabels: app: ingress

  Why it's wrong here

  This rule incorrectly assumes the namespace in question carries a label with the key 'name' and value 'ingress'. Kubernetes automatically labels namespaces with 'kubernetes.io/metadata.name' (whose value is the namespace name), not 'name' — unless an operator manually applied such a label, this selector will match no namespaces, making the rule ineffective. Even though the same 'from' entry correctly ANDs the namespace and pod selectors, the namespace selector itself is broken.

• ✗

  ingress: - from: - namespaceSelector: matchLabels: app: ingress podSelector: {}

  Why it's wrong here

  Here the empty podSelector (i.e., 'podSelector: {}') selects all pods in any namespace that carries the label 'app: ingress', not only pods with that label in the specific ingress namespace. This broadens the allowed sources to every pod in every namespace that happens to be labeled 'app: ingress', including potentially unrelated workloads. The rule fails to pin down both the namespace and the pod identity simultaneously, so it permits far more ingress than intended.

• ✗

  ingress: - from: - podSelector: matchLabels: app: ingress - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress

  Why it's wrong here

  This policy splits the desired condition into two separate 'from' entries: one that selects any pod with app: ingress in any namespace, and another that selects any pod in the namespace labeled 'kubernetes.io/metadata.name: ingress'. Because entries in the 'from' list are OR'd together, traffic is allowed from either source — meaning any matching pod outside the ingress namespace or any pod inside that namespace (even without the app label) can reach the protected service. The correct approach requires both selectors within a single 'from' entry so they are ANDed.

• ✓

  ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: ingress podSelector: matchLabels: app: ingress

  Why this is correct

  This is correct because a single 'from' entry containing both a namespaceSelector and a podSelector applies Boolean AND semantics: the source pod must run in a namespace that carries the 'kubernetes.io/metadata.name: ingress' label (i.e., the namespace literally named 'ingress') AND the pod itself must have the label 'app: ingress'. Since no other ingress rules exist, the policy defaults to deny all other ingress traffic, precisely matching the requirement. Using the standard metadata.name label ensures reliable namespace identification without relying on manually maintained labels.

Go deeper

Related to this question