KCSA Practice Test 20 — 15 Questions

Question 1

A security engineer is analyzing supply chain risks for container images. An unsigned image from an untrusted public registry is pulled into a secure cluster. Which Admission Controller plugin can be leveraged to prevent the deployment of unsigned container images?

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

Accepted Answer

ValidatingAdmissionWebhook executing a policy engine integrated with Cosign image signature verification. The ValidatingAdmissionWebhook admission plugin allows external policy engines (e.g., OPA Gatekeeper, Kyverno) to intercept API server requests and enforce custom validation logic. When integrated with Cosign, the webhook can verify image signatures against trusted public keys before allowing a Pod to be created. This is the standard Kubernetes-native mechanism for enforcing image signature verification at admission time, directly preventing unsigned images from being deployed.

Answer

NamespaceLifecycle admission plugin

Answer

DefaultStorageClass admission controller

Answer

LimitRanger

Question 2

An administrator wants to ensure that containers cannot execute any system calls related to module loading or debugging, such as 'init_module' or 'kexec_load'. Which security mechanism in Kubernetes allows applying a predefined system call filter to containers?

Accepted Answer

Seccomp profiles. Seccomp (secure computing mode) profiles allow administrators to filter which system calls a container can make, including blocking dangerous calls like init_module or kexec_load. In Kubernetes, seccomp profiles can be applied via the securityContext.seccompProfile field, restricting the container's syscall surface. This directly addresses the requirement to prevent module loading and debugging-related syscalls.

Answer

Pod Disruption Budgets

Answer

Kubernetes NetworkPolicies

Answer

ResourceQuotas

Question 3

An administrator is auditing a managed Kubernetes service (such as Amazon EKS, Google GKE, or Azure AKS) to verify compliance with cloud native security principles. The administrator attempts to SSH directly into the underlying worker node to inspect system logs. The connection is refused. Why is this restriction expected under the cloud native security model?

Accepted Answer

The cloud provider abstracts and manages the underlying Cloud layer, prohibiting direct node access to maintain infrastructure integrity.. In a managed Kubernetes service the provider owns and operates the control plane and the underlying host/cloud layer, and direct SSH access to worker nodes is deliberately blocked to preserve the provider's infrastructure integrity, patching cadence, and security guarantees. The cloud native security model expects operators to use Kubernetes-native and provider APIs (kubectl, logging/metrics services, node debugging tools) rather than logging into nodes, which enforces the shared responsibility boundary.

Answer

The kubelet has been disabled by the cloud provider for security compliance.

Answer

Container runtime security policies have blocked the SSH daemon process.

Answer

NetworkPolicies applied to the kube-system namespace have dropped incoming port 22 traffic.

Question 4

A security engineer is configuring kube-apiserver audit logging to satisfy NIST compliance requirements. Which configuration file specifies which requests are logged and at what log level?

Accepted Answer

Audit policy file. The audit policy file is the Kubernetes resource that defines which requests are logged and at what level (None, Metadata, Request, RequestResponse). It is passed to the kube-apiserver via the --audit-policy-file flag, and the apiserver evaluates each request against the policy rules to determine logging behavior. Other configuration files govern different components and do not control audit logging.

Answer

kubeadm.conf

Answer

Kubelet configuration file

Answer

Admission configuration YAML

Question 5

Which of the following is a core tenet of Zero Trust architecture in cloud native environments?

Accepted Answer

Verify explicitly, use least privilege access, and assume breach. The canonical Zero Trust tenet is 'never trust, always verify,' operationalized as verify explicitly, apply least privilege access, and assume breach. Option C captures all three pillars in one statement, matching NIST SP 800-207 and industry frameworks like Google BeyondCorp. These principles apply equally to users, devices, and workloads in cloud-native environments.

Answer

Grant cluster-admin privileges to all operations engineers

Answer

Disable all encryption for internal microservice communication to improve speed

Answer

Trust all traffic originating from inside the corporate virtual private cloud (VPC)

Question 6

Which TWO statements accurately describe how Kubernetes admission controllers function? (Choose TWO)

Accepted Answer

Validating admission controllers can reject incoming requests but cannot modify the object content.. Option B is correct because validating admission controllers operate during the API server's admission phase and can only allow or deny a request; they cannot mutate the object, which is the exclusive role of mutating controllers. Option E is correct because in the Kubernetes admission chain, mutating admission controllers (including mutating admission webhooks) run first and may alter the object's fields, after which validating admission controllers run against the final mutated object. Option A is wrong because admission controllers run in the kube-apiserver, not on the kubelet, which only handles pod/container lifecycle after scheduling. Option C is wrong because admission controllers are a separate policy layer and do not replace RBAC authentication/authorization, which still governs API access. Option D is wrong because a validating webhook with failurePolicy 'Ignore' causes the API server to ignore the webhook's failure and continue processing, not stop processing further webhooks.

Answer

Admission controllers run on the kubelet before container creation on the worker node.

Answer

Admission controllers replace the need for RBAC authentication.

Answer

If any validating webhook fails and its failurePolicy is 'Ignore', the API server stops processing further webhooks.

Question 7

An administrator needs to enforce mTLS (Mutual TLS) across all microservices within a service mesh without modifying application code. Which component is automatically injected into each application pod to handle the encryption and decryption of traffic?

Accepted Answer

Sidecar proxy. A sidecar proxy is a secondary container deployed alongside the application container within the same pod. In service meshes like Istio or Linkerd, the sidecar proxy (e.g., Envoy) intercepts all inbound and outbound traffic, handles mTLS handshakes, certificate rotation, and encryption/decryption transparently — no application code changes are needed. This is the core mechanism for zero-trust networking in Kubernetes service meshes.

Answer

Container runtime shim

Answer

Kube-proxy

Answer

Ingress controller

Question 8

Which THREE of the following steps are recognized best practices for hardening worker nodes against attacks and container escapes?

Accepted Answer

Keeping node host operating system kernels and container runtimes regularly patched. Option A is correct because regularly patching node host OS kernels and container runtimes closes known privilege-escalation and container-escape vulnerabilities (e.g., runc CVEs) that attackers exploit to break out of containers. Option C is correct because the Kubelet read-only port 10255 serves unauthenticated pod and node metadata; disabling it (or ensuring it is not enabled, since it is deprecated/removed in newer Kubernetes) prevents unauthenticated information disclosure and reconnaissance. Option E is correct because restricting direct SSH access to worker nodes and requiring hardened bastion hosts reduces the attack surface and enforces auditable, controlled administrative access to nodes. Option B is wrong because running pods as UID 0 (root) violates least privilege and increases the impact of a container escape. Option D is wrong because allowing anonymous authentication on the Kubelet API exposes node and pod operations to unauthenticated users and should be disabled via --anonymous-auth=false.

Answer

Configuring all pods to execute with `securityContext.runAsUser: 0`

Answer

Allowing anonymous authentication requests on the Kubelet API

Question 9

You are auditing the Kubernetes control plane and notice that the API server is configured with an insecure port (--insecure-port=8080). What is the primary security implication of leaving this port enabled?

Accepted Answer

It bypasses all authentication and authorization modules, granting full administrative access to anyone who reaches the port.. The --insecure-port flag on the kube-apiserver opens an unauthenticated, unencrypted HTTP endpoint that completely bypasses the normal authentication (x509 client certs, bearer tokens, OIDC) and authorization (RBAC, ABAC, Node authorizer) chain. Any client that can reach that port — including a compromised pod on the host network or a misconfigured firewall — is treated as an anonymous, fully privileged user and can perform any API action, including creating cluster-admin bindings. This is why the flag was deprecated in Kubernetes 1.20 and removed in 1.24.

Answer

It prevents the kubelet from communicating with the control plane nodes.

Answer

It restricts API access exclusively to read-only operations.

Answer

It forces all clients to downgrade their TLS encryption cipher suites to plaintext.

Question 10

You are hardening a production Kubernetes control plane. You need to ensure that etcd client-to-server and peer communications are strictly encrypted in transit and require mutual TLS (mTLS). Which etcd configuration flag combination enforces this requirement?

Accepted Answer

--client-cert-auth=true and --peer-client-cert-auth=true along with valid CA and key pair paths.. The flags --client-cert-auth=true and --peer-client-cert-auth=true force etcd to require and verify client certificates on both the client-facing listener (port 2379) and the peer listener (port 2380), which is exactly what mTLS demands. Combined with --cert-file, --key-file, --trusted-ca-file, --peer-cert-file, --peer-key-file, and --peer-trusted-ca-file, etcd will reject any connection that does not present a certificate signed by the trusted CA. This is the canonical CIS Kubernetes Benchmark configuration for a hardened etcd.

Answer

--auto-tls=true for all endpoints.

Answer

--insecure-transport=false combined with HTTP proxy routing.

Answer

--cipher-suites=TLS_RSA_WITH_AES_128_CBC_SHA

Question 11

An attacker gains execution inside a container and attempts to modify the container's root filesystem. The platform team has configured the deployment with `securityContext.readOnlyRootFilesystem: true`. What security mechanism does this enforce?

Accepted Answer

Filesystem immutability and prevention of unauthorized file modifications. Setting `securityContext.readOnlyRootFilesystem: true` in a Kubernetes pod spec mounts the container's root filesystem as read-only, preventing any process inside the container from writing to or modifying files on the root filesystem. This enforces filesystem immutability, which blocks attackers who gain code execution from persisting malware, modifying binaries, or tampering with configuration files. Any write attempt returns an EROFS (Read-only file system) error, forcing attackers to rely on writable volume mounts if any exist.

Answer

Automatic container image re-signing

Answer

Kernel capability escalation blocking

Answer

Network isolation via NetworkPolicies

Question 12

Which Kubernetes feature allows administrators to define mandatory security baselines, such as disallowing privileged containers, across an entire namespace or cluster?

Accepted Answer

Pod Security Admission. Pod Security Admission (PSA) is a built-in Kubernetes admission controller that enforces Pod Security Standards (PSS) at the namespace level. It allows administrators to define mandatory security baselines—such as disallowing privileged containers, hostPath volumes, or host networking—by labeling namespaces with pod-security.kubernetes.io/enforce, audit, or warn modes. PSA replaced the deprecated PodSecurityPolicy and is enabled by default in Kubernetes v1.23+, making it the correct feature for cluster-wide or namespace-scoped security baselines.

Answer

Horizontal Pod Autoscaler

Answer

PersistentVolume security controller

Answer

kube-dns policy mapper

Question 13

Your organization requires that all container images deployed to the production cluster must be scanned for known Common Vulnerabilities and Exposures (CVEs) before admission. Which component in a cloud-native architecture is primarily responsible for intercepting and blocking deployments if a vulnerability threshold is exceeded?

Accepted Answer

An Admission Controller webhook. Admission Controller webhooks (specifically ValidatingAdmissionWebhooks) intercept API server requests after authentication and authorization but before the object is persisted to etcd. This makes them the correct enforcement point for policies like 'block any pod whose image fails a CVE scan.' Tools such as OPA Gatekeeper, Kyverno, and custom webhooks register with the API server and can reject a Deployment or Pod creation request if the image violates the vulnerability threshold, ensuring non-compliant workloads never reach the scheduler.

Answer

The Kubernetes Scheduler

Answer

The kube-proxy daemonset

Answer

The container runtime (e.g., containerd)

Question 14

Which TWO of the following are valid Kubernetes RBAC rule subjects that can be bound to roles or cluster roles?

Accepted Answer

User. Option B (User) is correct because Kubernetes RBAC subjects include User, Group, and ServiceAccount, and a User subject is identified by a string name (often an email or certificate CN) in a RoleBinding or ClusterRoleBinding. Option D (ServiceAccount) is correct because ServiceAccount is a first-class RBAC subject, specified with its name and namespace (e.g., system:serviceaccount::) when binding a Role or ClusterRole. Options A (Secret), C (Namespace), and E (PersistentVolume) are not RBAC subjects; they are Kubernetes API resource kinds that can appear in a Role/ClusterRole's rules as resources, but they cannot be bound as the subject of a RoleBinding or ClusterRoleBinding.

Answer

Secret

Answer

Namespace

Answer

PersistentVolume

Question 15

Which THREE options represent valid ways to supply sensitive data to a container using Kubernetes native features? (Choose THREE)

Accepted Answer

Mounting the Secret as a volume in the Pod specification.. Option B is correct because Kubernetes natively supports mounting a Secret as a volume in a Pod spec (via volumes.secret and volumeMounts), which projects each key as a file inside the container's filesystem. Option C is correct because a container can use its mounted ServiceAccount token to authenticate to the Kubernetes API server and, with appropriate RBAC permissions, read Secret objects directly via the API. Option E is correct because Secret keys can be injected as environment variables using env.valueFrom.secretKeyRef, a standard native mechanism for passing sensitive data to containers. Option A is not a Kubernetes-native way to supply Secrets; LUKS-encrypted persistent volumes are an external storage/encryption concern and Secrets are not stored in PVs. Option D is not valid because embedding plaintext secrets in image build args exposes them in image layers and build history, and it is not a Kubernetes Secret delivery mechanism.

Answer

Placing the Secret inside a persistent volume formatted with LUKS encryption.

Answer

Embedding the Secret plaintext string in the container image build args.