KCSA — Pod & Network Security — Practice Questions

10 minute read

Practice Questions — Pod & Network Security

Test your understanding of Chapter 5 concepts with these 10 multiple-choice questions. These questions mirror the style and difficulty of the KCSA exam.

Instructions:

Select the one best answer for each question
Click the answer toggle to reveal the explanation
Try to answer each question before looking at the solution

Question 1 — Pod Security Standards Levels

Which Pod Security Standards (PSS) level blocks hostNetwork, hostPID, and privileged containers, but does not require runAsNonRoot?

A. Privileged
B. Baseline
C. Restricted
D. Default

Show Answer

Correct Answer: B

Option	Explanation
A. Privileged	❌ The Privileged level has no restrictions — it allows hostNetwork, hostPID, and privileged containers.
B. Baseline	✅ Correct. The Baseline level blocks known privilege escalation vectors including hostNetwork, hostPID, hostIPC, and privileged containers. However, it does not require `runAsNonRoot` — that requirement only exists at the Restricted level.
C. Restricted	❌ The Restricted level blocks all of these and requires `runAsNonRoot: true`. The question specifically says it does not require `runAsNonRoot`.
D. Default	❌ There is no PSS level called “Default.” PSS defines exactly three levels: Privileged, Baseline, and Restricted.

Question 2 — Pod Security Admission Modes

A team wants to track which pods in their staging namespace would violate the Restricted PSS level but does not want to block any pods. Which PSA modes should they use?

A. enforce: restricted
B. audit: restricted and warn: restricted
C. enforce: baseline and audit: restricted
D. warn: restricted only

Show Answer

Correct Answer: B

Option	Explanation
A. enforce: restricted	❌ The `enforce` mode rejects non-compliant pods. The requirement is to not block any pods.
B. audit: restricted and warn: restricted	✅ Correct. The `audit` mode records violations in the audit log, and the `warn` mode sends warnings to users — but neither blocks pod creation. Using both gives comprehensive visibility without disruption.
C. enforce: baseline and audit: restricted	❌ The `enforce: baseline` would block pods that violate Baseline (e.g., privileged containers). The question says they don’t want to block any pods.
D. warn: restricted only	❌ While `warn` alone would not block pods, using both `audit` and `warn` gives better visibility. The `audit` mode writes to the audit log for compliance tracking, which `warn` alone does not. Option B is the more complete answer.

Question 3 — Security Context Fields

A pod has the following security context at the container level:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Which PSS level does this container configuration comply with?

A. Privileged only
B. Baseline only
C. Restricted
D. None — the configuration is invalid

Show Answer

Correct Answer: C

Option	Explanation
A. Privileged only	❌ Privileged has no restrictions, so this pod would comply, but this is not the most restrictive level it meets.
B. Baseline only	❌ This pod exceeds Baseline requirements. It includes `runAsNonRoot`, drops all capabilities, and uses `RuntimeDefault` seccomp — all requirements of Restricted.
C. Restricted	✅ Correct. This configuration meets all Restricted requirements: `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `drop: ["ALL"]` capabilities, and `seccompProfile: RuntimeDefault`. Since Restricted is the most restrictive level, a pod that meets Restricted also meets Baseline and Privileged.
D. None	❌ The configuration is perfectly valid YAML and meets all Restricted-level requirements.

Question 4 — Linux Capabilities

What is the security best practice for managing Linux capabilities in containers?

A. Add SYS_ADMIN to allow containers to manage the system
B. Use the default capabilities provided by the container runtime
C. Drop ALL capabilities and add back only the specific ones needed
D. Add NET_RAW and NET_ADMIN for network functionality

Show Answer

Correct Answer: C

Option	Explanation
A. Add SYS_ADMIN	❌ `SYS_ADMIN` is one of the most dangerous capabilities. It grants near-root access including the ability to mount filesystems and perform namespace operations. This should almost never be granted.
B. Use default capabilities	❌ The default set includes approximately 14 capabilities, many of which are unnecessary for most applications. Using defaults violates the principle of least privilege and does not comply with the Restricted PSS level.
C. Drop ALL, add only needed	✅ Correct. This follows the principle of least privilege. By dropping ALL capabilities and adding back only the specific ones the application needs (e.g., `NET_BIND_SERVICE` for binding to low ports), you minimize the attack surface. This is required by the Restricted PSS level.
D. Add NET_RAW and NET_ADMIN	❌ `NET_RAW` allows raw socket operations (used in network attacks), and `NET_ADMIN` allows network configuration changes. Neither should be added unless absolutely necessary. These are not allowed under the Restricted PSS level.

Question 5 — Seccomp Profiles

Which seccomp profile type provides no syscall filtering and is NOT allowed under the Restricted PSS level?

A. RuntimeDefault
B. Localhost
C. Unconfined
D. Disabled

Show Answer

Correct Answer: C

Option	Explanation
A. RuntimeDefault	❌ `RuntimeDefault` uses the container runtime’s default seccomp profile, which blocks 40-60 dangerous syscalls. It is allowed under Restricted.
B. Localhost	❌ `Localhost` uses a custom seccomp profile from a file on the node. It is allowed under Restricted (assuming the profile is properly configured).
C. Unconfined	✅ Correct. `Unconfined` means no seccomp filtering is applied. The container can make any system call to the host kernel. This is the least secure option and is not allowed under the Restricted PSS level.
D. Disabled	❌ There is no seccomp profile type called “Disabled” in Kubernetes. The valid types are `Unconfined`, `RuntimeDefault`, and `Localhost`.

Question 6 — Network Policy Selectors (AND vs OR)

Given the following NetworkPolicy ingress rule:

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        env: production
    podSelector:
      matchLabels:
        app: frontend

Which traffic is allowed?

A. Traffic from any pod in any namespace labeled env: production OR any pod labeled app: frontend
B. Traffic from pods labeled app: frontend that are in namespaces labeled env: production
C. Traffic from all pods in all namespaces
D. Traffic from pods labeled app: frontend in the same namespace as the target pod

Show Answer

Correct Answer: B

Option	Explanation
A. OR logic	❌ This would be the case if the selectors were in separate `from` entries (each with its own `-`). In this YAML, both selectors are in the same entry (no `-` before `podSelector`), which means AND logic.
B. AND logic	✅ Correct. Because `namespaceSelector` and `podSelector` are in the same `from` entry (there is no `-` before `podSelector`), they are combined with AND logic. Traffic is only allowed from pods that have the label `app: frontend` AND are in a namespace with label `env: production`. Both conditions must be true.
C. All traffic	❌ An empty selector (`{}`) would allow all traffic, but these selectors are not empty — they specify specific labels.
D. Same namespace only	❌ A standalone `podSelector` (without `namespaceSelector`) would only match pods in the same namespace. Here, the `namespaceSelector` explicitly selects pods from namespaces labeled `env: production`, which could be a different namespace.

Question 7 — Default Deny Network Policy

Which NetworkPolicy creates a default deny all ingress rule for every pod in the secure-ns namespace?

spec:
  podSelector:
    matchLabels:
      deny: "true"
  policyTypes: ["Ingress"]

spec:
  podSelector: {}
  policyTypes: ["Ingress"]

C. ```yaml spec: podSelector: {} policyTypes: [“Ingress”] ingress:
- from:
  - podSelector: {} ```
D. ```yaml spec: podSelector: {} policyTypes: [“Ingress”, “Egress”] ingress:
- {} ```

Show Answer

Correct Answer: B

Option	Explanation
A. matchLabels deny: true	❌ This only targets pods with the label `deny: "true"`, not all pods. A default deny policy must use `podSelector: {}` to select all pods in the namespace.
B. podSelector: {} with Ingress	✅ Correct. `podSelector: {}` selects all pods in the namespace. `policyTypes: ["Ingress"]` means ingress traffic is controlled. Because there are no `ingress` rules, all incoming traffic is denied. This is the standard default-deny-ingress pattern.
C. podSelector: {} with ingress from all	❌ This has `ingress: [from: [podSelector: {}]]`, which allows ingress from all pods in the namespace. The question asks for a deny-all policy, not an allow-all policy.
D. Ingress with allow-all rule	❌ The `ingress: [{}]` entry is an allow-all ingress rule. It also includes Egress in policyTypes, which denies egress (no egress rules), but the question asks specifically about ingress denial.

Question 8 — CNI Plugin Support

A team has deployed NetworkPolicy resources in their cluster, but pod-to-pod communication is not being restricted as expected. The policies are correctly configured. What is the most likely cause?

A. The NetworkPolicy API is not enabled in the API server
B. The CNI plugin does not support NetworkPolicy enforcement
C. NetworkPolicy resources require a restart of the kubelet
D. The pods have not been annotated with the network policy name

Show Answer

Correct Answer: B

Option	Explanation
A. API not enabled	❌ The NetworkPolicy API (`networking.k8s.io/v1`) is always available in modern Kubernetes. If it weren’t enabled, the resources couldn’t be created at all.
B. CNI doesn’t support it	✅ Correct. This is the most common cause. CNI plugins like Flannel do not support NetworkPolicy. When the CNI doesn’t support it, NetworkPolicy resources are accepted by the API server (they’re valid Kubernetes objects) but are never enforced. There is no error or warning. Calico, Cilium, or Weave are needed for enforcement.
C. Kubelet restart needed	❌ NetworkPolicy enforcement does not require a kubelet restart. Policies take effect immediately when the CNI plugin processes them.
D. Pods need annotations	❌ NetworkPolicy uses label selectors, not annotations. Pods do not need any special annotation to be affected by a NetworkPolicy.

Question 9 — Resource Requests vs Limits

A container has the following resource configuration:

resources:
  requests:
    cpu: "500m"
    memory: "256Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

What QoS class will Kubernetes assign to a pod with only this container?

A. BestEffort
B. Burstable
C. Guaranteed
D. Standard

Show Answer

Correct Answer: C

Option	Explanation
A. BestEffort	❌ BestEffort is assigned when no resource requests or limits are specified. This container has both requests and limits.
B. Burstable	❌ Burstable is assigned when requests and limits are different (requests < limits), or when only requests are specified. Here, requests and limits are equal.
C. Guaranteed	✅ Correct. A pod gets the Guaranteed QoS class when every container has `requests == limits` for both CPU and memory. In this case, `cpu: 500m == 500m` and `memory: 256Mi == 256Mi`, so the pod is Guaranteed. Guaranteed pods are the last to be evicted when a node runs out of resources.
D. Standard	❌ There is no QoS class called “Standard” in Kubernetes. The three QoS classes are Guaranteed, Burstable, and BestEffort.

Question 10 — QoS Eviction Priority

During a node memory pressure event, Kubernetes needs to evict pods to free up resources. In which order will pods be evicted?

A. Guaranteed → Burstable → BestEffort
B. BestEffort → Burstable → Guaranteed
C. Alphabetical order by pod name
D. Oldest pods first, regardless of QoS class

Show Answer

Correct Answer: B

Option	Explanation
A. Guaranteed first	❌ This is the reverse of the correct order. Guaranteed pods are the last to be evicted because they have predictable resource usage (requests == limits).
B. BestEffort → Burstable → Guaranteed	✅ Correct. Kubernetes evicts pods in this order during resource pressure: BestEffort pods are evicted first (no resource guarantees), then Burstable pods (partial guarantees), and finally Guaranteed pods (full guarantees, last resort). Within each QoS class, pods exceeding their requests are evicted before those within their requests.
C. Alphabetical order	❌ Kubernetes does not use pod names for eviction decisions. Eviction is based on QoS class and actual resource usage relative to requests.
D. Oldest first	❌ Pod age is not the primary factor in eviction decisions. QoS class and resource usage are the determining factors.

Self-Assessment Scoring Guide

Count your correct answers and assess your readiness:

Score	Rating	Recommendation
9–10	Excellent	You have a strong grasp of pod and network security. Move to the next chapter.
7–8	Good	Review the topics where you made mistakes, then proceed.
5–6	Fair	Re-read the sections on your weak areas before moving on.
Below 5	Needs Work	Go through Chapter 5 again, focusing on the comparison tables and YAML examples.

Topics to Review Based on Mistakes

If You Missed	Review This Topic
Q1	Pod Security Standards (PSS) — PSS levels comparison table
Q2	Pod Security Admission (PSA) — PSA modes
Q3	Security Contexts — Key fields table
Q4	Security Contexts — Linux capabilities
Q5	Security Contexts — Seccomp profiles
Q6, Q7	Network Policies — AND vs OR logic, default deny
Q8	Network Policies — CNI plugin support
Q9, Q10	Resource Limits & DoS Prevention — QoS classes

What’s Next?

You’ve completed Chapter 5 — Pod & Network Security. Continue to the next chapter in your KCSA preparation.

Back to Chapter 5 Hub

Share on

Twitter Facebook LinkedIn

KCSA — Pod & Network Security — Practice Questions

Practice Questions — Pod & Network Security

Question 1 — Pod Security Standards Levels

Question 2 — Pod Security Admission Modes

Question 3 — Security Context Fields

Question 4 — Linux Capabilities

Question 5 — Seccomp Profiles

Question 6 — Network Policy Selectors (AND vs OR)

Question 7 — Default Deny Network Policy

Question 8 — CNI Plugin Support

Question 9 — Resource Requests vs Limits

Question 10 — QoS Eviction Priority

Self-Assessment Scoring Guide

Topics to Review Based on Mistakes

What’s Next?

Share on

You may also enjoy

AWS EKS Karpenter: Intelligent Kubernetes Node Autoscaling and Provisioning

Terraform Provider Development: Building Custom Providers with the Plugin Framework

EKS IRSA and Pod Identity: Fine-Grained AWS Permissions Without Static Keys

Writing Resume: Quantifying Infrastructure Impact with Metrics and Cost Savings