← CCA hub

CCA — Network Policy

18% of the CCA exam. Sample questions below; the full library has 18 questions tagged to this domain.

Sample questions on Network Policy

Network Policy

Q1. When a CiliumNetworkPolicy specifies 'fromEndpoints' with an empty label selector, what traffic does it match?

Reveal answer and explanations
  1. A No traffic - empty selector matches nothing

    Incorrect. An empty selector is inclusive, not exclusive.

  2. B All traffic from all endpoints in the cluster

    Correct. In Kubernetes/Cilium semantics, an empty label selector matches all objects.

  3. C Traffic from endpoints with no labels

    Incorrect. Empty selector matches all, regardless of label presence.

  4. D Traffic from endpoints in the current namespace only

    Incorrect. Namespace scope is controlled separately via 'fromNamespaces'.

Network Policy

Q2. In Cilium's policy enforcement, what is the difference between 'namespaceSelector' and 'podSelector' in a rule?

Reveal answer and explanations
  1. A 'namespaceSelector' selects entire namespaces as policy sources; 'podSelector' selects specific pods within namespaces

    Correct. 'namespaceSelector' targets pods based on namespace labels; 'podSelector' targets pods based on pod labels.

  2. B 'namespaceSelector' requires the target namespace to exist first

    Incorrect. Selectors don't have dependencies on resource existence order.

  3. C They are synonymous; both select pods by namespace

    Incorrect. They serve different purposes.

  4. D 'namespaceSelector' is deprecated; use only 'podSelector'

    Incorrect. 'namespaceSelector' is actively supported.

Network Policy

Q3. A pod in namespace `prod` has a CiliumNetworkPolicy with: ```yaml namespaceSelector: matchLabels: name: staging ``` The policy also allows: ```yaml fromNamespaces: [staging] ``` Will a pod in the `staging` namespace be able to send traffic to the pod in `prod`?

Reveal answer and explanations
  1. A Yes, because the fromNamespaces selector explicitly allows staging pods

    Correct. The CiliumNetworkPolicy's 'fromNamespaces: [staging]' allows ingress from pods in the staging namespace to the pod in prod.

  2. B No, because the namespaceSelector in the policy applies only to the policy's pod, not remote pods

    Incorrect. namespaceSelector applies to the target pod's namespace; fromNamespaces explicitly allows source namespaces.

  3. C Yes, but only if the staging pod has a matching label

    Incorrect. Labels aren't required once the namespace is allowed by fromNamespaces.

  4. D No, because Cilium requires both source and destination pods to be in the same namespace for policies to apply

    Incorrect. CiliumNetworkPolicy supports cross-namespace policies via fromNamespaces.

Network Policy

Q4. When you apply a CiliumNetworkPolicy that specifies only ingress rules and no egress rules, what happens to egress traffic from the affected pods?

Reveal answer and explanations
  1. A Egress traffic is allowed only to kube-system namespace

    Incorrect. There is no automatic exception for kube-system.

  2. B All egress traffic is denied

    Incorrect. Absent egress rules do not trigger a deny.

  3. C Egress traffic is allowed by default (falls through to default policy mode)

    Correct. Policy rules are additive; specifying only ingress rules does not affect egress, which follows the cluster's default allow/deny mode.

  4. D Egress traffic requires a separate CiliumNetworkPolicy for each destination

    Incorrect. Separate policies are not required for each destination.

Network Policy

Q5. You configure a CiliumNetworkPolicy with toFQDN rules to allow DNS lookups of 'api.example.com', but the policy doesn't include DNS (port 53/UDP) egress rules. Will pod DNS lookups succeed?

Reveal answer and explanations
  1. A No, DNS egress must be explicitly allowed separately from FQDN rules

    Incorrect. toFQDN automatically permits DNS; no separate DNS egress rule is needed.

  2. B No, toFQDN requires a companion DNS allow rule and the policy is interpreted as deny-all egress

    Incorrect. toFQDN doesn't require a companion DNS rule; it self-permits necessary DNS traffic.

  3. C Yes, DNS is allowed by default unless a deny-all egress policy is active

    Incorrect. Cilium uses default-deny semantics when policies are present; DNS must be explicitly allowed or implicitly by toFQDN.

  4. D Yes, toFQDN rules implicitly allow DNS traffic to resolve the FQDN

    Correct. toFQDN rules implicitly allow the DNS lookups (port 53/UDP) required to resolve the specified FQDNs.

Drill Network Policy with the full bankDomain Drill mode targets your weak areas — paid feature

How this domain is tested

Network Policy accounts for 18% of the CCA exam. Expect questions that test recall of terminology and the ability to read short scenarios — not deep configuration. Use the sample questions above as difficulty calibration; if any feel hard, the rest of our 18-question domain bank will close those gaps.