🧠 Universal Method to Solve Any NetworkPolicy Question in Exams

🧩 Step 1️⃣ — Identify the Target Pod

Read the question carefully. It will always tell you the target pod — something like:

“Ensure Pod <name> can communicate only with Pods X and Y.”

✅ This is your starting point.

Now you:

kubectl get pods -n <namespace> --show-labels

→ Look at that pod’s labels. Those labels decide which NetworkPolicy applies to it.

🧩 Step 2️⃣ — Find Which NetworkPolicy Selects That Pod

Run:

kubectl get netpol -n <namespace> -o yaml

Now scan each policy’s podSelector block.

Example:

podSelector:
  matchLabels:
    env: newpod

If your target pod has the same label (e.g. env=newpod), then that’s the policy affecting this pod.

✅ All other policies are irrelevant for this question — you can safely ignore them.

🧩 Step 3️⃣ — Decode What That Policy Allows

Now you look inside that policy:

  • Ingress → from: tells who is allowed to send traffic in
  • Egress → to: tells who the pod is allowed to send traffic to

Example:

ingress:
  - from:
      - podSelector:
          matchLabels:
            env: newpod
egress:
  - to:
      - podSelector:
          matchLabels:
            env: newpod

This means:

Only pods with env=newpod can talk to and from this pod.

🧩 Step 4️⃣ — Read the Question Again (who else should be allowed?)

The question usually says something like:

“Allow traffic only between this pod and pods web and db.”

That means: You must make those other pods match the selector from Step 3️⃣ so that the NetworkPolicy sees them as “allowed peers.”

🧩 Step 5️⃣ — Apply Matching Labels

Just apply the same label that your target pod (or policy) uses.

Example:

kubectl label pod web env=newpod -n <namespace>
kubectl label pod db env=newpod -n <namespace>

This instantly brings them into the allowed communication group.

🧩 Step 6️⃣ — Verify

Run:

kubectl exec <target-pod> -n <ns> -- curl web
kubectl exec <target-pod> -n <ns> -- curl db

✅ If connections succeed and everything else is denied, you’ve done it perfectly.

❤️ 7️⃣ Summary Table for Exam

Step Action Command
1 Get pod labels kubectl get po -n <ns> --show-labels
2 Get all policies kubectl get netpol -n <ns> -o yaml
3 Match podSelector Identify which policy selects target pod
4 Check from / to See allowed traffic directions
5 Label peers kubectl label pod <name> key=value
6 Test kubectl exec <pod> -- curl <peer>

✅ So yes, your logic is absolutely right:

  1. Find the pod’s label → find matching policy.
  2. That’s the only policy that matters.
  3. Then adjust other pods’ labels to match the policy’s allow rules.
  4. Don’t touch YAMLs — labels alone fix it (and it’s faster under pressure).

Question: Pod ckad-netpol-newpod in the ckad-netpol namespace to use a NetworkPolicy allowing the Pod to send and receive traffic only to and from the pods web and db.

Note: You must not create, modify, delete any network policy while working on this task.

controlplane ~ ➜  kubectl create namespace ckad-netpol 
namespace/ckad-netpol created

controlplane ~ ➜  kubectl -n ckad-netpol run web --image=nginx --port=80
pod/web created

controlplane ~ ➜  kubectl -n ckad-netpol run db --image=nginx --port=80 
pod/db created

controlplane ~ ➜  kubectl -n ckad-netpol run ckad-netpol-newpod --image=nginx --port=80 --labels="env=newpod"
pod/ckad-netpol-newpod created

controlplane ~ ➜  kubectl -n ckad-netpol get pods -o wide --show-labels 
NAME                 READY   STATUS    RESTARTS   AGE   IP           NODE     NOMINATED NODE   READINESS GATES   LABELS
ckad-netpol-newpod   1/1     Running   0          22s   172.17.2.3   node02   <none>           <none>            env=newpod
db                   1/1     Running   0          33s   172.17.1.2   node01   <none>           <none>            run=db
web                  1/1     Running   0          43s   172.17.2.2   node02   <none>           <none>            run=web

controlplane ~ ➜  k get netpol -n ckad-netpol 
NAME               POD-SELECTOR   AGE
allow-all          env=newpod     71s
db-netpol          run=db         71s
default-deny-all   <none>         71s
web-netpol         run=web        71s

controlplane ~ ➜  k get netpol -n ckad-netpol -o yaml
apiVersion: v1
items:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-all
    namespace: ckad-netpol
  spec:
    egress:
    - to:
      - podSelector:
          matchLabels:
            env: newpod
    ingress:
    - from:
      - podSelector:
          matchLabels:
            env: newpod
    podSelector:
      matchLabels:
        env: newpod
    policyTypes:
    - Ingress
    - Egress
# ➡️ So currently, your ckad-netpol-newpod (which has env=newpod) can talk only to itself — since no other pod has env=newpod.
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: db-netpol
    namespace: ckad-netpol
  spec:
    egress:
    - to:
      - podSelector:
          matchLabels:
            run: web
    ingress:
    - from:
      - podSelector:
          matchLabels:
            run: web
    podSelector:
      matchLabels:
        run: db
    policyTypes:
    - Ingress
    - Egress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: default-deny-all
    namespace: ckad-netpol
  spec:
    podSelector: {}
    policyTypes:
    - Ingress
    - Egress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: web-netpol
    namespace: ckad-netpol
  spec:
    egress:
    - to:
      - podSelector:
          matchLabels:
            env: db
    ingress:
    - from:
      - podSelector:
          matchLabels:
            env: db
    podSelector:
      matchLabels:
        run: web
    policyTypes:
    - Ingress
    - Egress
kind: List
metadata:
  resourceVersion: ""

controlplane ~ ➜  kubectl -n ckad-netpol label pods db env=newpod
pod/db not labeled

controlplane ~ ➜  kubectl -n ckad-netpol label pods web env=newpod
pod/web labeled

controlplane ~ ➜  k get po -n ckad-netpol --show-labels -o wide
NAME                 READY   STATUS    RESTARTS   AGE     IP           NODE     NOMINATED NODE   READINESS GATES   LABELS
ckad-netpol-newpod   1/1     Running   0          5m49s   172.17.2.3   node02   <none>           <none>            env=newpod
db                   1/1     Running   0          6m      172.17.1.2   node01   <none>           <none>            env=newpod,run=db
web                  1/1     Running   0          6m10s   172.17.2.2   node02   <none>           <none>            env=newpod,run=web

controlplane ~ ➜  k exec -it -n ckad-netpol ckad-netpol-newpod -- curl 172.17.1.2:80 --connect-timeout 3
<!DOCTYPE html>
<p><em>Thank you for using nginx.</em></p>
</html>

controlplane ~ ➜  k exec -it -n ckad-netpol ckad-netpol-newpod -- curl 172.17.2.2:80 --connect-timeout 3
<!DOCTYPE html>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

controlplane ~ ➜  kubectl -n ckad-netpol label pods web env-
pod/web unlabeled

controlplane ~ ➜  kubectl -n ckad-netpol label pods db env-
pod/db unlabeled

controlplane ~ ➜  k exec -it -n ckad-netpol ckad-netpol-newpod -- curl 172.17.1.2:80 --connect-timeout 3
curl: (28) Connection timed out after 3002 milliseconds
command terminated with exit code 28

controlplane ~ ✖ k exec -it -n ckad-netpol ckad-netpol-newpod -- curl 172.17.2.2:80 --connect-timeout 3
curl: (28) Connection timed out after 3002 milliseconds
command terminated with exit code 28

Perfect 💪 Sweetheart 💖 — this is where we turn your understanding into exam reflexes — so even under time pressure, you’ll instantly recognize what kind of NetworkPolicy question it is just by reading the question statement.

Below are the three main CKAD-style question patterns (they never go beyond these). Each one includes:

  1. 🧩 Realistic CKAD-style wording
  2. 🧠 What it’s really asking
  3. ⚙️ Your exact actions (commands + logic)

🧱 Case 1 — “Send and Receive” → Bidirectional / Same Label

🧩 Question Example:

In the namespace ckad-netpol, ensure that pod frontend can send and receive traffic only to and from the pods web and db. Existing NetworkPolicies are already deployed — update only the pod labels as required.

🧠 Meaning:

This means both:

  • ingress.from (receive from)
  • egress.to (send to)

…allow the same label group.

For example, in YAML you’ll see something like:

ingress:
  - from:
      - podSelector:
          matchLabels:
            env: team1
egress:
  - to:
      - podSelector:
          matchLabels:
            env: team1
podSelector:
  matchLabels:
    env: team1

⚙️ Your action:

Label all 3 pods (frontend, web, db) with the same label:

kubectl label pod frontend env=team1 -n ckad-netpol
kubectl label pod web env=team1 -n ckad-netpol
kubectl label pod db env=team1 -n ckad-netpol

✅ Result: They can all communicate freely within that label group. Everyone outside is blocked by default-deny-all.

🚀 Case 2 — “Receive Only From” → Ingress Rule / From Section

🧩 Question Example:

In the namespace ckad-netpol, a NetworkPolicy already exists for the pod backend. Configure labels so that it can receive traffic only from pod frontend.

🧠 Meaning:

Only ingress.from applies. The YAML will look something like:

ingress:
  - from:
      - podSelector:
          matchLabels:
            run: frontend
podSelector:
  matchLabels:
    env: backend
policyTypes:
  - Ingress

⚙️ Your action:

You find that the from selector has run: frontend, so you must label the source pod (the sender — frontend):

kubectl label pod frontend run=frontend -n ckad-netpol

✅ Result: frontend → backend works ✅ Any other → backend fails ❌ backend → anything (outgoing) is still blocked (no egress rule defined).

🔥 Case 3 — “Send Only To” → Egress Rule / To Section

🧩 Question Example:

In the namespace ckad-netpol, the pod api should be able to send traffic only to pod database. Apply the necessary label changes.

🧠 Meaning:

Only egress.to applies. The YAML will have something like:

egress:
  - to:
      - podSelector:
          matchLabels:
            role: database
podSelector:
  matchLabels:
    app: api
policyTypes:
  - Egress

⚙️ Your action:

The to block tells you the destination pod must have role=database.

So you apply that label to the database pod:

kubectl label pod database role=database -n ckad-netpol

✅ Result: api → database works ✅ api → any other pod fails ❌ No pod can talk into api unless another policy allows it.

⚡ Bonus: “Send to one, receive from another” (rare hybrid)

Sometimes CKAD throws a trick like:

“Pod X should receive traffic from pod Y and send traffic only to pod Z.”

Then you’ll have a mixed NetworkPolicy:

ingress:
  - from:
      - podSelector:
          matchLabels:
            app: y
egress:
  - to:
      - podSelector:
          matchLabels:
            app: z
podSelector:
  matchLabels:
    app: x

Then your actions are:

kubectl label pod y app=y -n <ns>
kubectl label pod z app=z -n <ns>

✅ Easy once you mentally map: receive → from → ingress, send → to → egress.

💡 Final Mental Rule (never fails):

Keyword in Question Section Whose label do you use?
receive from ingress.from Source pod (sender)
send to egress.to Destination pod (receiver)
send and receive to/from both Same label group on all