KCSA Practice Test 21 — 15 Questions

Question 1

A security engineer is hardening a Kubernetes cluster against container breakout attacks. They configure AppArmor profiles and ensure pods run with a non-root user. Which of the 4Cs layers are these security measures primarily designed to protect?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Container layer. AppArmor profiles and running pods as a non-root user are security measures that apply to the container runtime and the containerized processes. These controls restrict what a container can do, such as limiting system calls or preventing privilege escalation, which are part of the Container layer in the 4Cs model. Therefore, the Container layer is the primary target.

Answer

Cluster layer

Answer

Cloud layer

Answer

Code layer

Question 2

Which CNCF project acts as a cloud-native runtime security and intrusion detection tool that monitors system calls against predefined security rules?

Accepted Answer

Falco. Falco is the CNCF-graduated cloud-native runtime security project that detects anomalous activity and intrusions by monitoring Linux system calls (and Kubernetes audit events) against a rule engine. It uses a kernel module or eBPF probe to capture syscalls and evaluates them against YAML-defined rules, generating alerts when behavior matches known attack patterns. This makes it the canonical answer for runtime threat detection in Kubernetes environments.

Answer

Trivy

Answer

Fluentd

Answer

Cert-manager

Question 3

You have configured a NetworkPolicy with an egress rule targeting a specific CIDR block. However, DNS resolution for external domain names fails from within the pods selected by this policy. What is the most likely cause?

Accepted Answer

Outgoing DNS traffic on UDP/TCP port 53 to the cluster DNS server was blocked by the default-deny egress behavior.. When a NetworkPolicy with egress rules is applied, it acts as a default-deny for all egress traffic except what is explicitly allowed. DNS resolution requires egress to the cluster DNS service (often CoreDNS) on UDP/TCP port 53. If that traffic is not allowed, DNS queries fail, causing resolution errors.

Answer

NetworkPolicies automatically disable CoreDNS across the entire namespace.

Answer

DNS packets are rejected because they do not contain IP block headers.

Answer

The external domain name does not have a corresponding Service object.

Question 4

A security auditor notices that a deployment running in the 'production' namespace is violating the Restricted Pod Security Standard because containers are running as root. How can you enforce compliance using Pod Security Admission?

Accepted Answer

Label the 'production' namespace with 'pod-security.kubernetes.io/enforce=restricted'.. Pod Security Admission is enforced per-namespace via labels, and the label 'pod-security.kubernetes.io/enforce=restricted' applies the Restricted Pod Security Standard to every pod created in that namespace, rejecting non-compliant pods such as those running as root. This is the native, supported mechanism in Kubernetes 1.25+ after PodSecurityPolicy was removed.

Answer

Create a NetworkPolicy that blocks root user communication.

Answer

Enable the SecurityContextDeny legacy admission controller.

Answer

Update the kube-apiserver flags to globally block non-restricted pods without namespace labels.

Question 5

According to the shared responsibility model for a cloud-managed Kubernetes service, who is responsible for managing application data encryption keys (using KMS) and application-level secrets?

Accepted Answer

The customer. Under the shared responsibility model for managed Kubernetes (EKS, AKS, GKE), the cloud provider secures the control plane and physical infrastructure, but the customer always owns their data and the keys protecting it. Application data encryption keys managed via KMS and application-level secrets (API keys, DB credentials, tokens) remain the customer's responsibility regardless of service model.

Answer

The cloud provider

Answer

The Linux Foundation

Answer

The container runtime vendor

Question 6

When configuring a container to run securely in a Kubernetes cluster, you want to ensure that the container process cannot gain any new privileges during its lifecycle, even if it runs as root or exploits a setuid binary. Which Linux kernel feature should be enabled in the container security context?

Accepted Answer

allowPrivilegeEscalation: false. The allowPrivilegeEscalation: false setting directly controls whether a container process can gain more privileges than its parent process. It sets the Linux no_new_privs flag on the container process, which prevents setuid/setgid binaries and file capabilities from elevating privileges. This is the exact kernel feature that blocks privilege escalation even when running as root.

Answer

readOnlyRootFilesystem: false

Answer

privileged: true

Answer

runAsNonRoot: false

Question 7

A developer configures a Kubernetes Pod with `hostNetwork: true`. Under the STRIDE threat model, which threat category is most directly introduced or elevated by this configuration?

Accepted Answer

Elevation of Privilege and Information Disclosure. Setting hostNetwork: true places the Pod directly in the host's network namespace, so it shares the node's IP, routing table, and can bind to any host port — including privileged ports and ports used by node services. This directly elevates privilege (the Pod can sniff or interfere with node-level traffic and reach services bound to localhost) and discloses information (it can observe host network traffic and access node-local endpoints). Under STRIDE, these map to Elevation of Privilege and Information Disclosure.

Answer

Denial of Service via CPU exhaustion

Answer

Tampering of container image layers at rest

Answer

Repudiation of database audit logs

Question 8

Which TWO methods can be used to restrict network traffic between services inside a service mesh? (Choose two)

Accepted Answer

PeerAuthentication resources enforcing STRICT mTLS mode between workloads. Option B is correct because PeerAuthentication with mode STRICT enforces mutual TLS between workloads, so only identities holding a valid SPIFFE certificate issued by the mesh CA can complete the TLS handshake, effectively blocking plaintext or non-mesh traffic to those pods. Option E is correct because Istio AuthorizationPolicy resources let you define allow/deny rules based on source principals (SPIFFE identities), namespaces, HTTP methods, paths, and ports, which directly restricts which services may talk to which others inside the mesh. Option A is wrong because CoreDNS forwarding upstream servers only affects name resolution for external domains, not intra-mesh traffic filtering. Option C is wrong because Horizontal Pod Autoscalers adjust replica counts based on metrics and do not enforce any traffic restrictions. Option D is wrong because PersistentVolumeClaim resize operations change storage capacity and have no bearing on network traffic between services.

Answer

Modifying CoreDNS forwarding upstream servers

Answer

Configuring Horizontal Pod Autoscalers

Answer

Kubernetes PersistentVolumeClaim storage resize operations

Question 9

An application pod requires access to the Kubernetes API to list other pods. To follow secure practices, you create a dedicated ServiceAccount and bind a custom Role to it. How should you configure the Pod specification to prevent the default service account token from being automatically mounted?

Accepted Answer

Set 'automountServiceAccountToken: false' in the Pod specification.. Setting automountServiceAccountToken: false in the Pod spec prevents Kubernetes from automatically projecting the ServiceAccount token into the pod's filesystem. This is the correct way to stop the default token mount while still allowing the pod to use a dedicated ServiceAccount for API access when needed. The pod can still explicitly mount a token if required, but automatic mounting is disabled.

Answer

Delete the 'default' ServiceAccount in the namespace.

Answer

Configure the Pod securityContext with 'readOnlyRootFilesystem: true'.

Answer

Add a deny NetworkPolicy blocking egress to the Kubernetes API service IP.

Question 10

An external identity provider (OIDC) is integrated with your Kubernetes cluster. You want to restrict a group named 'contractors' so they can only view pods in the 'staging' namespace. Which configuration correctly maps this requirement?

Accepted Answer

A ClusterRole granting pod read access bound via a RoleBinding in the 'staging' namespace to the subject kind 'Group' with name 'contractors'.. A ClusterRole defines the permissions (read pods) at cluster scope, and a RoleBinding in the 'staging' namespace binds that ClusterRole to the 'contractors' Group, restricting the grant to only that namespace. This is the canonical pattern for granting cluster-defined permissions to a group within a single namespace.

Answer

A Namespace-scoped ServiceAccount configured with an OIDC JWT issuer URL.

Answer

A Role in the 'staging' namespace bound via a ClusterRoleBinding to the 'contractors' group.

Answer

An OIDC webhook configuration in the kube-apiserver specifying namespace boundaries.

Question 11

An auditor is evaluating the Kubernetes control plane attack surface. Which component exposes the primary interface for cluster management and must be protected with strong authentication and authorization?

Accepted Answer

kube-apiserver. The kube-apiserver is the central management interface for a Kubernetes cluster, exposing the REST API that all other components (kubectl, controllers, kubelets, schedulers) use to read and write cluster state. Because it is the single entry point for all control plane operations, it must be protected with strong authentication (client certs, OIDC, webhook tokens) and authorization (RBAC, ABAC, Node authorizer). Compromise of the API server effectively means full cluster compromise, making it the most critical attack surface to harden.

Answer

CoreDNS

Answer

kube-proxy

Answer

kube-scheduler

Question 12

A platform engineer is hardening a container runtime setup on worker nodes. They want to ensure that containers cannot make unauthorized changes to network configurations or mount host filesystems. Which capability must be explicitly dropped from the default container capabilities set?

Accepted Answer

CAP_SYS_ADMIN. CAP_SYS_ADMIN is the most powerful Linux capability, granting broad administrative privileges including mounting filesystems, modifying network configuration, and accessing kernel features. Dropping it prevents containers from performing privileged operations like mounting host filesystems or reconfiguring network interfaces, which are common container-escape and node-compromise vectors.

Answer

CAP_CHOWN

Answer

CAP_NET_BIND_SERVICE

Answer

CAP_DAC_OVERRIDE

Question 13

Which THREE of the following are key components of the Kubernetes control plane? (Choose THREE)

Accepted Answer

kube-scheduler. The Kubernetes control plane is composed of the components that make global cluster decisions and expose the cluster API. Option E, kube-apiserver, is correct because it is the front end of the control plane, serving the REST API on port 6443 and acting as the central communication hub that all other components talk to. Option A, kube-scheduler, is correct because it watches for newly created Pods with no assigned node and selects a suitable node based on resource requirements, affinity, and taints/tolerations. Option C, kube-controller-manager, is correct because it runs the core control loops (such as the node, replication, endpoints, and service account controllers) that reconcile desired state with observed state. Option B, the container runtime (e.g., containerd), is not a control plane component; it runs on every node (including workers) as part of the kubelet's container execution layer via the CRI. Option D, kube-proxy, is also not a control plane component; it runs on each node to implement Service networking rules via iptables or IPVS, making it a node-level networking component rather than part of the control plane.

Answer

container runtime (e.g., containerd)

Answer

kube-proxy

Question 14

An auditor is evaluating the security posture of an on-premises Kubernetes cluster. The team notices that the etcd data directory is stored without encryption at rest. What is the primary threat this exposes the cluster to?

Accepted Answer

Direct exposure of all Kubernetes Secrets in plain text to anyone with read access to etcd storage. Without encryption at rest, etcd stores all Kubernetes objects—including Secrets—in plaintext on disk. Anyone with read access to the etcd data directory (e.g., via filesystem access, stolen disk, or backup) can directly read sensitive data like service account tokens, database passwords, and TLS keys. This is the primary threat because etcd is the single source of truth for cluster state, and encryption at rest is a defense-in-depth measure specifically designed to protect this data if the storage medium is compromised.

Answer

Inability of worker nodes to perform TLS handshakes with the API server

Answer

Immediate failure of HorizontalPodAutoscaler metric polling loops

Answer

Automatic elevation of all ServiceAccounts to cluster-admin privileges

Question 15

A security engineer is configuring a seccomp profile for a critical application pod running in a hardened Kubernetes cluster to restrict system calls. The pod requires access to the networking stack but must block module loading. Where must this custom JSON seccomp profile be placed on a worker node running containerd so that it can be referenced via the pod security spec?

Accepted Answer

/var/lib/kubelet/seccomp/. Custom seccomp profiles referenced by kubelet must be placed in the kubelet's seccomp root directory, which defaults to /var/lib/kubelet/seccomp/ on the worker node. The pod spec then references the profile via securityContext.seccompProfile with type Localhost and a relative path under that directory. This is the documented location for local seccomp profiles in Kubernetes.

Answer

/var/log/containers/

Answer

/etc/kubernetes/manifests/

Answer

/etc/containerd/certs.d/