KCSA Platform Security Practice Test 3 — 15 Questions

Question 1

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?

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

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 2

An organization mandates that all traffic entering the service mesh must be decrypted at the ingress gateway, inspected by a Web Application Firewall (WAF), and then re-encrypted using mTLS before reaching backend pods. What is this architectural pattern called within service mesh security?

Accepted Answer

TLS re-encryption (or edge termination with backend mTLS). TLS re-encryption (also called edge termination with backend mTLS) is the pattern where the ingress gateway terminates external TLS, passes traffic to a WAF or inspection layer in plaintext, then re-encrypts with mTLS before forwarding to backend pods. This preserves end-to-end encryption inside the mesh while allowing inspection at the edge.

Answer

HTTP plaintext tunneling

Answer

Pod security standard restriction

Answer

DNS-based load balancing

Question 3

What is the primary purpose of vulnerability scanning databases (such as Trivy, Grype, or Clair) when integrated into a container platform?

Accepted Answer

To match package versions inside container images against known CVE databases and report vulnerabilities. Vulnerability scanning databases like Trivy, Grype, and Clair work by extracting the installed package inventory (OS packages, language libraries) from a container image and matching those versions against known CVE feeds such as NVD, GHSA, and vendor advisories. They report CVEs with severity, fixed versions, and package paths so teams can remediate before deployment. This is the core function of an image scanner — it is not a runtime enforcement or networking tool.

Answer

To enforce network microsegmentation rules

Answer

To balance incoming web traffic across backend replicas

Answer

To automatically rotate cluster TLS certificates

Question 4

Which TWO practices are essential for securing container images against supply chain vulnerabilities? (Choose two)

Accepted Answer

Using minimal base images (e.g., Distroless or Alpine) to reduce attack surface. Option D is correct because using minimal base images such as Distroless or Alpine reduces the number of installed packages, libraries, and utilities, which directly shrinks the attack surface and lowers the chance that a vulnerable component is present in the image. Option E is correct because scanning container images for known CVEs during the CI/CD pipeline catches vulnerable dependencies and OS packages before deployment, enabling remediation or blocking of the build. Option A is wrong because running container processes as root by default violates least privilege and increases the impact of a container compromise. Option B is wrong because disabling container registry authentication exposes images to unauthorized pulls and tampering. Option C is wrong because storing plain-text passwords in image environment variables leaks secrets to anyone who can inspect the image or container metadata.

Answer

Running all container processes as the root user by default

Answer

Disabling container registry authentication

Answer

Storing plain-text passwords inside image environment variables

Question 5

Which THREE configurations should be applied to a Kubernetes Pod Security Standard 'restricted' profile compliance checklist? (Choose three)

Accepted Answer

Restricting container capabilities to drop ALL and only permit essential ones like NET_BIND_SERVICE. The Kubernetes Pod Security Standard 'restricted' profile is the most hardened policy, so option B is correct because it mandates dropping ALL Linux capabilities and only adding back the minimal ones actually needed (e.g., NET_BIND_SERVICE), which follows the least-privilege principle. Option C is correct because the restricted profile explicitly requires allowPrivilegeEscalation: false in the container securityContext to prevent processes from gaining more privileges than their parent (e.g., via setuid binaries or file capabilities). Option E is correct because runAsNonRoot: true is required so the kubelet validates that containers do not run as UID 0, blocking root-owned processes. Option A does not belong because privileged: true is forbidden by the restricted profile, as it grants nearly all host capabilities and device access. Option D does not belong because mounting the host root filesystem read-write is prohibited; the restricted profile disallows hostPath volumes and requires read-only root filesystems where applicable.

Answer

Allowing privileged: true for all application containers

Answer

Mounting the host root filesystem in read-write mode

Question 6

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 7

Which THREE security controls can be enforced by admission webhook policy engines (like Kyverno or OPA Gatekeeper) regarding container images? (Choose three)

Accepted Answer

Verifying cryptographic image signatures using tools like Cosign. Admission webhook policy engines such as Kyverno and OPA Gatekeeper intercept Kubernetes API admission requests and can validate container image attributes before a workload is persisted. Option A is correct because policies can invoke signature verification (e.g., Cosign keyless or key-based attestations) and reject pods whose images lack a valid cryptographic signature. Option B is correct because these engines can enforce registry allow-lists, rejecting any image reference whose registry does not match the approved enterprise registries. Option E is correct because policies can query vulnerability scan results (e.g., from Trivy or Grype reports) and block deployment of images containing unmitigated high-severity CVEs. Option C is not applicable because admission webhooks only validate Kubernetes API objects; they cannot modify kernel modules on worker nodes. Option D is likewise outside their scope, since restarting unhealthy pods is a runtime remediation handled by controllers like the kubelet or ReplicaSet, not by an admission policy.

Answer

Automatically updating kernel modules on the underlying worker node

Answer

Manually restarting unhealthy pods across worker nodes

Question 8

Which TWO features are typically provided by service mesh architectures to enhance platform security? (Choose two)

Accepted Answer

Fine-grained Layer 7 authorization policies between services. Option B is correct because service meshes such as Istio and Linkerd enforce fine-grained Layer 7 authorization policies (for example, Istio AuthorizationPolicy or Linkerd's HTTPRoute-based policies) that control which services may call specific HTTP methods, paths, or gRPC methods, providing identity-aware, request-level access control between workloads. Option D is correct because service meshes automatically provision and rotate mutual TLS (mTLS) certificates for pod-to-pod communication, typically via a sidecar proxy (Envoy) or ambient node proxy, giving each workload a SPIFFE-based cryptographic identity and encrypting all east-west traffic without application changes. Option A is not a service mesh feature; kernel patching of worker nodes is handled by node OS update tooling or managed Kubernetes node image upgrades. Option C is not a service mesh feature; persistent block storage volumes are provisioned by CSI drivers and storage classes, not by the mesh data plane. Option E is not a service mesh feature; container registry authentication tokens are managed by Kubernetes image pull secrets, kubelet credential providers, or registry-level IAM, not by the service mesh.

Answer

Automatic kernel patch management for worker nodes

Answer

Provisioning of persistent block storage volumes

Answer

Managing container registry authentication tokens

Question 9

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 10

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 11

Which THREE advanced container runtime or image security features help prevent container breakout exploits? (Choose three)

Accepted Answer

Using sandboxed container runtimes (such as Kata Containers or gVisor) for strong isolation. Option A is correct because sandboxed runtimes such as Kata Containers and gVisor insert a lightweight VM or user-space kernel boundary between the container and the host kernel, so a kernel exploit inside the container does not directly compromise the host. Option D is correct because restrictive Seccomp profiles filter the syscall table and block sensitive calls (for example, ptrace, mount, or unshare) that container breakout exploits rely on to escape isolation. Option E is correct because dropping dangerous Linux capabilities such as CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE removes the privileges needed to mount filesystems, craft raw packets, or inject into host processes, which are common breakout primitives. Option B is wrong because privileged mode disables isolation and grants all capabilities plus host device access, dramatically increasing breakout risk. Option C is wrong because mounting host /proc and /sys read-write exposes host kernel and process information and allows tampering, which weakens rather than strengthens isolation.

Answer

Running all containers in privileged mode

Answer

Mounting host /proc and /sys directories in read-write mode

Question 12

Which TWO tasks are typically performed during container image vulnerability scanning? (Choose two)

Accepted Answer

Checking for insecure configuration settings or exposed secrets within image layers. Option C is correct because image vulnerability scanning inspects the contents of each image layer for misconfigurations such as running as root, hardcoded credentials, API keys, or other exposed secrets embedded in the filesystem. Option E is correct because scanners extract the installed OS packages (e.g., from dpkg/rpm/APK databases) and application dependencies (e.g., from package-lock.json, requirements.txt, go.mod) and compare their versions against CVE feeds like the NVD, vendor advisories, or distro security trackers. Option A is incorrect because ingress TLS certificates are configured at the Kubernetes Ingress/runtime layer, not discovered by scanning image layers. Option B is incorrect because node CPU utilization is a runtime monitoring concern handled by tools like Prometheus or metrics-server, not image scanning. Option D is incorrect because cluster network policies are runtime Kubernetes configuration objects, not artifacts contained within a container image.

Answer

Configuring ingress TLS certificates

Answer

Monitoring active Kubernetes node CPU utilization

Answer

Updating cluster network policies

Question 13

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 14

Which THREE practices are critical for securing container registries and image distribution pipelines? (Choose three)

Accepted Answer

Enabling automated vulnerability scanning upon image push. Option A is correct because automated vulnerability scanning on image push (e.g., via Trivy, Clair, or registry-native scanners like Amazon ECR or Harbor) detects known CVEs in base images and dependencies before vulnerable artifacts propagate through the pipeline. Option B is correct because enforcing RBAC on registry repositories ensures least-privilege access, so only authorized identities can push, pull, or delete specific images, preventing unauthorized tampering or exfiltration. Option E is correct because image signing and verification with Notary or Cosign (using the OCI signature spec and tools like cosign verify) cryptographically guarantees artifact integrity and provenance, blocking tampered or untrusted images from being deployed. Option C is wrong because embedding admin credentials in plaintext Dockerfiles exposes secrets in image layers and version control, violating secret-management best practices. Option D is wrong because anonymous write access to public repositories allows anyone to push malicious images, enabling supply-chain attacks and image poisoning.

Answer

Storing registry admin credentials in plaintext inside Dockerfiles

Answer

Allowing anonymous write access to public repositories

Question 15

Which TWO security features are provided by modern container runtimes like containerd or CRI-O? (Choose two)

Accepted Answer

Integration with Linux security modules (Seccomp, AppArmor, SELinux). Option A is correct because modern container runtimes such as containerd and CRI-O integrate with Linux security modules — Seccomp profiles to filter syscalls, AppArmor profiles, and SELinux labels — to constrain what container processes can do at the kernel level. Option C is correct because these runtimes rely on Linux namespaces (PID, network, mount, user, IPC, UTS) to provide process, network, filesystem, and user isolation between containers and the host. Option B is incorrect because Kubernetes RBAC roles and cluster permissions are managed by the Kubernetes API server and its authorization stack, not by the container runtime. Option D is incorrect because service mesh sidecar injection is handled by the service mesh control plane (for example, Istio's sidecar injector admission webhook), not by containerd or CRI-O. Option E is incorrect because Ingress TLS certificate generation is performed by cert-manager or similar controllers, not by the container runtime.

Answer

Management of Kubernetes RBAC roles and cluster permissions

Answer

Automatic deployment of service mesh sidecar proxies

Answer

Automatic generation of Kubernetes Ingress TLS certificates