CKAD Services and Networking 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.

• ✓

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: backend

  Why this is correct

  This is correct because the NetworkPolicy is placed in the frontend namespace, so its podSelector matches frontend pods carrying the app: web label. The policyTypes: [Ingress] explicitly makes this an ingress rule, and the ingress from list uses a namespaceSelector that matches the backend namespace by its automatically assigned metadata.name label, thus permitting inbound traffic only from pods in namespace backend — not from any other source. Because no podSelector is nested inside the namespaceSelector, the rule applies to every pod running in that source namespace.

• ✗

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: backend spec: podSelector: matchLabels: app: web ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: frontend

  Why it's wrong here

  This policy is invalid for the requirement because NetworkPolicies are namespaced resources and can only affect pods in their own namespace; placing it in backend means the podSelector, matching app: web, targets backend pods, not the frontend pods you need to protect. Even though the ingress rule references a namespaceSelector for frontend (which would treat frontend pods as allowed traffic sources), the traffic flow is reversed: it permits frontend pods to reach backend, rather than restricting ingress to frontend. To control ingress to frontend pods, the policy must be created inside the frontend namespace.

• ✗

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web ingress: - from: - ipBlock: cidr: 0.0.0.0/0

  Why it's wrong here

  The ipBlock with CIDR 0.0.0.0/0 matches every IPv4 address, so this ingress rule would allow traffic from any namespace, any pod, and any external IP, completely defeating the stated intent of only permitting backend namespace clients. It does not use namespaceSelector or podSelector, so it cannot express a namespace-scoped allow rule. Moreover, this is a common misconfiguration: a broad all-zero CIDR is effectively an allow-all and should only be used when the explicit goal is open access.

• ✗

  apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-backend namespace: frontend spec: podSelector: matchLabels: app: web policyTypes: - Ingress ingress: - from: - podSelector: matchLabels: app: backend

  Why it's wrong here

  The from rule uses a podSelector, and a podSelector without a surrounding namespaceSelector only matches pods in the same namespace as the NetworkPolicy — which is frontend here. Therefore, this would allow traffic from frontend pods that happen to have the app: backend label, not from pods in the actual backend namespace, and it would likely allow nothing if no such pods exist. To restrict by namespace, you need a namespaceSelector (optionally combined with a podSelector) in the from block.

Go deeper

Related to this question