KCSA Practice Test 15 — 15 Questions

Question 1

An administrator notices that unauthorized users can view sensitive ConfigMaps across different namespaces because default RoleBindings were overly permissive. Which security principle was violated?

Accepted Answer

Least privilege access. Overly permissive default RoleBindings that allow unauthorized users to view ConfigMaps across namespaces violate the principle of least privilege. Least privilege requires granting only the minimum permissions necessary for a user or service to perform its function. Default RoleBindings that grant broad read access to ConfigMaps across namespaces exceed that minimum and expose sensitive configuration data.

Answer

Shared responsibility model

Answer

Immutable infrastructure

Answer

Supply chain security

Question 2

Which TWO components are involved when an Ingress controller routes external HTTPS traffic to a backend service in Kubernetes? (Choose two)

Accepted Answer

The Ingress resource object defining routing rules and TLS hosts. Option D is correct because the Ingress resource is the declarative API object that defines the routing rules (host/path to backend Service mappings) and the TLS configuration, including the tls.hosts and secretName fields that specify which certificate to use for HTTPS termination. Option E is correct because the Ingress Controller pod (e.g., NGINX Ingress Controller, Traefik, HAProxy) is the actual data-plane component that watches Ingress resources and implements the reverse proxy logic, terminating TLS and forwarding requests to the backend Service's endpoints. Option A is incorrect because the kube-apiserver's etcd encryption key protects data at rest in etcd and plays no role in routing external HTTPS traffic. Option B is incorrect because CoreDNS provides cluster DNS resolution for service names, not TLS private key management. Option C is incorrect because the CSI controller handles persistent volume provisioning and attachment, which is unrelated to Ingress traffic routing.

Answer

The kube-apiserver etcd storage backend encryption key

Answer

The coreDNS server managing TLS private keys

Answer

The persistent volume CSI controller

Question 3

An administrator needs to restrict a container from accessing any devices on the host system via device nodes. By default, how does Docker or containerd handle device access for containers when no custom security profile is applied?

Accepted Answer

By applying a default device allowlist that restricts access to essential devices like /dev/null and /dev/random. By default, Docker and containerd apply a default device allowlist that permits access only to essential devices like /dev/null, /dev/zero, /dev/random, and /dev/urandom, while denying access to all other host devices. This is implemented via the default cgroup device controller policy.

Answer

By disabling all system calls related to file I/O

Answer

By routing all device access requests through kube-proxy

Answer

By mounting the entire host /dev directory in read-write mode

Question 4

Which RBAC verb allows a user to delete an existing resource in a Kubernetes namespace?

Accepted Answer

delete. In Kubernetes RBAC, the verb 'delete' is the canonical action that authorizes removal of an existing resource within a namespace (or cluster-scoped resource). It is one of the standard verbs alongside get, list, watch, create, update, patch, and deletecollection. A Role or ClusterRole rule such as 'verbs: ["delete"]' on a resource like pods grants the subject permission to issue DELETE requests against that resource's API endpoint.

Answer

remove

Answer

purge

Answer

destroy

Question 5

A security engineer needs to verify that control plane component pods (such as kube-apiserver and etcd) have correct file ownership on the control plane node. According to CIS benchmarks, who should own these manifest files located in "/etc/kubernetes/manifests"?

Accepted Answer

root:root. CIS Kubernetes Benchmark requires that control plane manifest files in /etc/kubernetes/manifests (static pod manifests for kube-apiserver, etcd, kube-controller-manager, kube-scheduler) be owned by root:root with permissions 644 or more restrictive. This prevents unprivileged users from modifying critical control plane definitions.

Answer

nobody:nogroup

Answer

daemon:daemon

Answer

kube:kube

Question 6

Which TWO entities can be assigned RBAC permissions in a Kubernetes cluster? (Choose TWO)

Accepted Answer

ServiceAccount. In Kubernetes RBAC, permissions are granted to subjects (the "who") via RoleBindings or ClusterRoleBindings, and the two subject types listed here are ServiceAccount (C) and User (E). A ServiceAccount (C) is a namespaced identity used by Pods and controllers, and it can be bound to Roles or ClusterRoles so workloads receive specific API permissions. A User (E) represents a human or external identity authenticated by the cluster (for example via client certificates or an OIDC provider) and can likewise be referenced as a subject in RoleBinding/ClusterRoleBinding. By contrast, ConfigMap (A), Namespace (B), and PersistentVolume (D) are API resources/objects that permissions are granted on (the "what"), not subjects that can be assigned permissions.

Answer

ConfigMap

Answer

Namespace

Answer

PersistentVolume

Question 7

An auditor notices that a cluster allows users to create Pods that mount host paths (`hostPath`). Which threat does this pose to the underlying node integrity?

Accepted Answer

Arbitrary read/write access to the host filesystem, enabling node compromise. A hostPath volume mounts a directory or file from the node's filesystem directly into the pod, so a container with write access can modify critical node files such as /etc/cron.d, /var/lib/kubelet, or SSH keys, leading to full node compromise and potential cluster-wide lateral movement. This is why Pod Security Standards restricted mode and admission policies like OPA Gatekeeper or Kyverno commonly block hostPath usage.

Answer

Automatic failure of Kubernetes liveness and readiness health probes

Answer

Inability of the CNI plugin to assign IP addresses to pods

Answer

Immediate corruption of the etcd distributed consensus state

Question 8

A security team is implementing NIST SP 800-190 guidelines for container runtime security. Which kernel feature is leveraged by container runtimes to restrict system calls and meet least-privilege execution requirements?

Accepted Answer

Seccomp profiles. Seccomp (secure computing mode) profiles are the kernel feature that filters which system calls a container process may invoke, directly enforcing least-privilege execution at the syscall boundary. NIST SP 800-190 explicitly calls out seccomp as a runtime control to reduce the kernel attack surface. By applying a seccomp profile (e.g., RuntimeDefault or a custom allowlist), the runtime blocks dangerous syscalls like ptrace or mount that a compromised container might abuse.

Answer

cgroups v2

Answer

AppArmor MAC profiles

Answer

Namespaces

Question 9

Which component in the Kubernetes control plane is directly responsible for interacting with etcd to persist and retrieve cluster state?

Accepted Answer

kube-apiserver. The kube-apiserver is the only control plane component that talks directly to etcd. It exposes the REST API, validates and mutates objects via admission controllers, and persists/retrieves all cluster state in etcd. Other components (scheduler, controller-manager, kubelet) interact with the API server, never with etcd directly.

Answer

kube-controller-manager

Answer

kube-scheduler

Answer

kubelet

Question 10

An administrator needs to secure access to the Kubernetes API server from an external CI/CD pipeline. Which mechanism should be used to authenticate the pipeline using an existing external identity provider without embedding long-lived static tokens?

Accepted Answer

Configure the API server with --oidc-issuer-url and related flags to validate JSON Web Tokens issued by the IDP.. Configuring the API server with --oidc-issuer-url, --oidc-client-id, and related flags lets it validate JSON Web Tokens (ID tokens) issued by an external OIDC identity provider, enabling short-lived, federated authentication for the CI/CD pipeline without static credentials. The pipeline obtains a token from the IdP (e.g., via client credentials or workload identity federation) and presents it as a Bearer token; the API server verifies the signature against the issuer's JWKS and maps claims to a username and groups for RBAC.

Answer

Store the administrative kubeconfig file in a public ConfigMap.

Answer

Enable anonymous requests on the API server for the CI/CD CIDR block.

Answer

Create a shared static password file and pass it via --basic-auth-file.

Question 11

You are hardening etcd and want to ensure that sensitive data stored in Kubernetes secrets is encrypted at rest within etcd. Which API server configuration file parameter specifies how secrets should be encrypted?

Accepted Answer

--encryption-provider-config. The kube-apiserver flag --encryption-provider-config points to an EncryptionConfiguration YAML file that defines which resources (e.g., secrets) are encrypted and which providers (aescbc, aesgcm, kms, secretbox, identity) are used. This is the only supported mechanism for encrypting Kubernetes Secrets at rest in etcd. Without it, secrets are stored as base64-encoded plaintext in etcd.

Answer

--etcd-encryption-key

Answer

--secrets-encryption-enabled

Answer

--etcd-ca-file

Question 12

What is the primary risk associated with running containers as the `root` user (`runAsUser: 0` or omitting the user directive)?

Accepted Answer

If a container escape vulnerability occurs, the attacker immediately obtains root privileges on the underlying host.. Running a container as root (UID 0) means that if an attacker exploits a container escape vulnerability, they gain root privileges on the host node because the container process runs as root in the host's user namespace (unless user namespaces are enabled). This violates the principle of least privilege and significantly increases the blast radius of a compromise. The other options are unrelated to user ID configuration.

Answer

It prevents the kubelet from restarting the container upon failure.

Answer

It disables the container runtime engine's ability to pull images from private registries.

Answer

It forces the CNI plugin to drop network packets destined for external IPs.

Question 13

A CI/CD pipeline service account needs permission to create Deployments and Services across multiple namespaces, but should not have cluster-admin privileges. What is the most secure way to grant these permissions?

Accepted Answer

Define a ClusterRole with the required verbs and resources, then create a RoleBinding for that ClusterRole in each target namespace.. A ClusterRole defines permissions cluster-wide but does not grant them until bound. By creating a RoleBinding in each target namespace that references the ClusterRole, the service account receives only the specified verbs (create) on the specified resources (Deployments, Services) within those namespaces. This follows the principle of least privilege and avoids cluster-admin rights.

Answer

Place the service account in the kube-system namespace.

Answer

Grant the service account permissions at the node level using kubeconfig overrides.

Answer

Create a ClusterRoleBinding linking the default cluster-admin ClusterRole to the service account.

Question 14

An auditor evaluates network security controls in a Kubernetes cluster. Which TWO configurations help mitigate lateral movement and network-based attacks between pods?

Accepted Answer

Implementing a service mesh (such as Istio or Linkerd) with strict mTLS enforcement. Option B is correct because a service mesh such as Istio or Linkerd with strict mTLS enforcement authenticates and encrypts all service-to-service traffic, so a compromised pod cannot impersonate another workload or sniff plaintext traffic, directly limiting lateral movement. Option E is correct because Kubernetes NetworkPolicies implement pod-level, label-selector-based ingress and egress filtering enforced by the CNI, allowing only explicitly permitted pod-to-pod flows and blocking unauthorized east-west connections. Option A is wrong because disabling CNI plugins and using plain bridge mode removes policy enforcement and segmentation, increasing exposure rather than mitigating it. Option C is wrong because NodePort services expose internal microservices on every worker node's IP and port range, widening the attack surface instead of containing it. Option D is wrong because hostNetwork: true places pods in the node's network namespace, letting them see node traffic and bypass pod network isolation, which enables rather than prevents lateral movement.

Answer

Disabling CNI network plugins to run pods in bridge mode

Answer

Exposing all internal microservices via NodePort services on worker nodes

Answer

Mounting the host network namespace (`hostNetwork: true`) on all application pods

Question 15

A cluster administrator needs to intercept and reject any resource creation requests that do not include a mandatory security-context label. Which admission controller type should be implemented?

Accepted Answer

ValidatingAdmissionWebhook. A ValidatingAdmissionWebhook is the correct choice because it is invoked during the admission review phase and can evaluate an incoming object against custom policy logic, returning an 'allowed: false' response to reject requests that fail validation. Since the requirement is to intercept and reject resource creation requests missing a mandatory label, a validating webhook is purpose-built for this enforcement. Mutating webhooks can only modify objects, not reject them, and built-in controllers like ServiceAccount or NamespaceLifecycle do not perform arbitrary label validation.

Answer

MutatingAdmissionWebhook

Answer

ServiceAccount

Answer

NamespaceLifecycle