KCSA Practice Test 12 — 15 Questions

Question 1

Which TWO actions help secure Ingress traffic in a Kubernetes cluster? (Choose two)

Accepted Answer

Enforcing TLS termination with strong cipher suites and valid certificates. Option B is correct because enforcing TLS termination at the ingress layer with strong cipher suites and valid certificates encrypts client-to-cluster traffic and prevents downgrade or weak-crypto attacks, directly securing Ingress traffic. Option D is correct because restricting the ingress controller's exposure (e.g., limiting its Service to a LoadBalancer with tight firewall rules or a private IP) and placing a WAF in front of it filters malicious HTTP/HTTPS requests such as SQLi and XSS before they reach backend pods. Option A is wrong because exposing debugging endpoints over unencrypted HTTP on port 80 increases the attack surface and leaks sensitive data. Option C is wrong because disabling authentication at the ingress gateway removes access control, allowing anonymous or unauthorized users to reach services. Option E is wrong because storing TLS private keys in plaintext ConfigMaps exposes them to anyone with read access to the namespace, breaking key confidentiality.

Answer

Exposing all internal debugging endpoints via unencrypted HTTP on port 80

Answer

Disabling all authentication mechanisms at the ingress gateway

Answer

Storing TLS private keys in plaintext ConfigMaps

Question 2

What is the purpose of the Pod Security Standards 'baseline' profile?

Accepted Answer

To prevent known privilege escalations while maintaining broad compatibility for standard applications.. The baseline profile is designed to prevent known privilege escalations — such as privileged containers, hostNetwork, hostPID, and adding dangerous capabilities — while remaining broadly compatible with standard applications. It sits between the permissive 'privileged' profile and the highly restrictive 'restricted' profile. This makes it the default recommendation for general-purpose namespaces that need meaningful security without breaking typical workloads.

Answer

To disable all security controls and permit unrestricted container execution.

Answer

To automatically encrypt all container environment variables.

Answer

To enforce the highest level of security, restricting pods to hardened sandbox environments.

Question 3

A security engineer is hardening a Kubernetes cluster and wants to ensure that all container images are pulled only from an approved internal container registry (e.g., registry.internal.corp). Which Kubernetes mechanism can enforce this restriction across all namespaces?

Accepted Answer

Deploying a validating admission policy or webhook to check image registry URLs. A validating admission policy or webhook is the correct mechanism because Kubernetes admission controllers intercept API requests before objects are persisted, allowing enforcement of image registry restrictions cluster-wide. Tools like OPA Gatekeeper, Kyverno, or the built-in ValidatingAdmissionPolicy (K8s 1.26+) can reject any Pod whose image field does not match an approved registry prefix such as registry.internal.corp. This enforcement applies across all namespaces without modifying individual workloads.

Answer

Configuring NodePort service selectors

Answer

Enabling horizontal pod autoscaling

Answer

Modifying the kube-proxy IPVS configuration

Question 4

Which TWO of the following tasks are handled by the kube-scheduler? (Choose TWO)

Accepted Answer

Evaluating pending pods and selecting suitable worker nodes for placement.. Option B is correct because the kube-scheduler's core function is to watch for newly created Pods that have no node assigned (Pending) and select a suitable node for them via its scheduling cycle. Option C is correct because during that scheduling cycle the kube-scheduler applies filtering and scoring predicates that include node taints/tolerations and node/pod affinity and anti-affinity rules to pick the best fit. Option A is not a scheduler task: X.509 client certificates for bootstrapping are issued by the kubelet's TLS bootstrap process via the CSR API and controller-manager signers. Option D is not a scheduler task: etcd encryption keys are managed through the kube-apiserver's EncryptionConfiguration and kube-controller-manager, not the scheduler. Option E is not a scheduler task: liveness probes are executed by the kubelet on each node, not by the scheduler.

Answer

Generating X.509 client certificates for cluster bootstrapping.

Answer

Managing encryption keys inside the etcd database.

Answer

Executing container liveness probes inside running pods.

Question 5

Which NIST framework publication specifically addresses the security of container-based applications and orchestration systems?

Accepted Answer

NIST SP 800-190. NIST SP 800-190, 'Application Container Security Guide', specifically addresses the security of container-based applications and orchestration systems. It provides guidance on container threats, vulnerabilities, and countermeasures, making it the correct publication for this topic.

Answer

NIST SP 800-37

Answer

NIST SP 800-53

Answer

NIST SP 800-88

Question 6

Which TWO tools or built-in Kubernetes features are used to secure container privileges and behaviors?

Accepted Answer

Pod Security Standards. Pod Security Standards (A) are correct because they are built-in Kubernetes policies (Privileged, Baseline, Restricted) enforced via the Pod Security Admission controller to restrict container privileges such as hostPath, hostNetwork, and privileged mode at the namespace level. SecurityContext (C) is correct because it lets you define pod- and container-level security settings like runAsUser, runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation, and Linux capabilities directly in the Pod spec to control container privileges and behaviors. PersistentVolumeClaim (B) is incorrect because it only requests storage resources and has no role in privilege or behavior security. HorizontalPodAutoscaler (D) is incorrect because it scales workloads based on metrics like CPU utilization, not security. IngressController (E) is incorrect because it manages external HTTP/HTTPS routing into the cluster, not container privilege enforcement.

Answer

PersistentVolumeClaim

Answer

HorizontalPodAutoscaler

Answer

IngressController

Question 7

Under the cloud native shared responsibility model for a managed Kubernetes service, which TWO tasks are typically the responsibility of the cloud provider? (Choose TWO)

Accepted Answer

Provisioning and securing physical data center facilities and hardware. Option C is correct because in the shared responsibility model the cloud provider owns the physical layer — data center facilities, power, cooling, physical security, and the underlying hardware hosts — which customers cannot access or control in a managed Kubernetes service. Option D is correct because with a managed Kubernetes offering (e.g., EKS, AKS, GKE) the provider operates, patches, and maintains the control plane components such as the API server, etcd, scheduler, and controller manager, including their high availability and version upgrades. Option A is not the provider's responsibility because application source code is always authored and maintained by the customer. Option B is not the provider's responsibility because RBAC rules governing who can access the cluster and its resources are configured by the customer. Option E is not the provider's responsibility because NetworkPolicies controlling pod-to-pod traffic within the customer's namespaces are defined and applied by the customer.

Answer

Writing custom application microservice source code

Answer

Configuring Kubernetes Role-Based Access Control (RBAC) rules

Answer

Applying Kubernetes NetworkPolicies between customer pods

Question 8

You want to write a NetworkPolicy that allows backend pods to communicate with an external database located outside the cluster at IP address '203.0.113.50'. Which NetworkPolicy section must you configure?

Accepted Answer

egress with an ipBlock matching '203.0.113.50/32'. Traffic from backend pods to an external database at 203.0.113.50 is outbound traffic leaving the cluster, so it must be governed by the egress section of the NetworkPolicy. The ipBlock selector with CIDR 203.0.113.50/32 precisely matches that single external IP, since ipBlock is designed for destinations outside the cluster where podSelector and namespaceSelector do not apply. The policy must also list 'Egress' in policyTypes for the rule to be enforced.

Answer

ingress with a namespaceSelector matching the external network

Answer

ExternalName service mapped to an egress policy

Answer

policyTypes set to ["Ingress"] with externalIPs

Question 9

Which THREE of the following criteria should be evaluated when reviewing Kubernetes RBAC policies to ensure least privilege? (Choose THREE)

Accepted Answer

Carefully audit permissions that allow impersonation or binding of roles.. Option A is correct because permissions such as impersonate and bind/escalate on users, groups, serviceaccounts, or roles let a subject assume other identities or grant themselves broader rights, directly undermining least privilege and requiring careful audit. Option B is correct because ClusterRoleBindings grant permissions across all namespaces and cluster-scoped resources, so they should be reserved for cases where a namespaced RoleBinding cannot provide the needed access. Option D is correct because wildcard (*) verbs or resources on sensitive objects like secrets, roles, and clusterroles can silently grant far more access than intended, violating least privilege. Option C is incorrect because anonymous write access to all namespaces is a severe over-permission and the opposite of least privilege. Option E is incorrect because granting cluster-admin to every service account by default is excessive privilege and a well-known anti-pattern.

Answer

Ensure anonymous users have write access to all namespaces.

Answer

Grant cluster-admin permissions to every service account by default.

Question 10

Which TWO of the following are valid ways to harden etcd against unauthorized access and data corruption? (Choose TWO)

Accepted Answer

Require mutual TLS (mTLS) for all client and peer connections.. Option C is correct because requiring mutual TLS (mTLS) for all client and peer connections ensures that both ends of every etcd connection present valid certificates, so only authenticated clients and peers can read or write keys and participate in raft consensus, preventing unauthorized access. Option D is correct because taking regular encrypted snapshots with etcdctl snapshot save (typically combined with encryption at rest or encrypting the snapshot file) preserves a recoverable copy of the datastore, allowing restoration after data corruption or compromise. Option A is wrong because exposing etcd over unencrypted HTTP on port 2379 sends credentials and data in cleartext and is exactly the insecure default that hardening must avoid. Option B is wrong because disabling client certificate verification removes authentication entirely, allowing unrestricted access. Option E is wrong because granting public anonymous write access to the raft log lets anyone corrupt cluster state and violates the principle of least privilege.

Answer

Expose etcd directly over unencrypted HTTP on port 2379.

Answer

Disable client certificate verification to allow unrestricted access.

Answer

Grant public anonymous write access to the etcd raft log.

Question 11

An external penetration tester managed to achieve remote code execution inside a container. They attempt to query the Kubernetes API server using the service account token mounted inside the container. To minimize the blast radius of such an attack, which setting should be explicitly configured on the Pod spec?

Accepted Answer

automountServiceAccountToken: false. By default, Kubernetes mounts a service account token into every pod at /var/run/secrets/kubernetes.io/serviceaccount/token, which an attacker with RCE can read and use to authenticate to the API server. Setting automountServiceAccountToken: false on the Pod spec prevents that token from being mounted, removing the credential the attacker needs to pivot to the API server. This directly shrinks the blast radius of a container compromise.

Answer

shareProcessNamespace: false

Answer

hostIPC: false

Answer

hostNetwork: false

Question 12

An auditor is assessing compliance with NIST SP 800-53 controls for access control (AC) within a managed Kubernetes cluster. Which API object enforces fine-grained authorization decisions directly at the Kubernetes API server?

Accepted Answer

ClusterRoleBinding. ClusterRoleBinding is the Kubernetes RBAC API object that binds a ClusterRole (or Role) to subjects (users, groups, service accounts) cluster-wide, and the API server evaluates these bindings during authorization. It directly enforces fine-grained authorization decisions at the API server, satisfying NIST SP 800-53 AC controls for least privilege and role-based access. Without a binding, a role grants nothing — the binding is what activates the permissions.

Answer

ValidatingWebhookConfiguration

Answer

NetworkPolicy

Answer

ResourceQuota

Question 13

Which TWO configuration practices improve container runtime security on Kubernetes nodes? (Choose two)

Accepted Answer

Enforcing non-root execution via container securityContext. Option A is correct because setting runAsNonRoot: true (and typically runAsUser to a non-zero UID) in the pod/container securityContext prevents processes from running as UID 0, so a container breakout or exploited app cannot gain root privileges on the node. Option C is correct because mounting the container's root filesystem with readOnly: true blocks writes to system binaries and libraries, thwarting tampering or persistence attempts inside the container. Option B is wrong because mounting /var/run/docker.sock gives the container full control over the Docker daemon, effectively granting node-level root access. Option D is wrong because disabling seccomp and AppArmor removes syscall and mandatory-access-control restrictions that harden the runtime. Option E is wrong because CAP_SYS_ADMIN is a highly privileged capability that enables mount, namespace, and other administrative operations, vastly expanding the attack surface.

Answer

Mounting the Docker socket inside application containers

Answer

Disabling all seccomp and AppArmor profiles

Answer

Granting CAP_SYS_ADMIN to all containers by default

Question 14

A DevOps team uses mutable image tags like `:latest` in their deployment manifests. Under supply chain threat modeling, what vulnerability does this practice introduce?

Accepted Answer

Image Tag Hijacking / Malicious substitution without manifest updates. Using mutable tags like :latest introduces the risk of image tag hijacking, where an attacker replaces the image referenced by that tag with a malicious one. Because the deployment manifest still references the same tag, Kubernetes will pull the new malicious image on the next pod restart or reschedule without any manifest change, leading to supply chain compromise. This is a classic supply chain threat in containerized environments.

Answer

Automatic revocation of TLS certificates issued by cert-manager

Answer

Exposition of etcd database credentials on public DNS servers

Answer

Escalation of RBAC permissions from Role to ClusterRole

Question 15

A cluster administrator wants to implement admission control auditing to record all mutating and validating requests made to the API server. Which component configuration handles this requirement?

Accepted Answer

Configure an audit policy file and pass its path to the API server via --audit-policy-file.. The Kubernetes API server is the only component that processes admission control requests (mutating and validating webhooks, plus built-in admission plugins). To record these requests for auditing, you must configure the API server with an audit policy file using the --audit-policy-file flag, which defines what events to record and at what level (e.g., Metadata, Request, RequestResponse). This flag, along with --audit-log-path or --audit-webhook-config-file, enables audit logging of all API requests, including those that go through admission controllers.

Answer

Configure the kubelet audit webhook via /etc/kubernetes/audit.json.

Answer

Enable kube-proxy audit mode using --audit-proxy=true.

Answer

Set etcd logging level to DEBUG in the etcd configuration yaml.