CCNA Platform Security Questions

Multi-Selecteasy

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

Select 2 answers

A.Running all container processes as the root user by default

B.Disabling container registry authentication

C.Storing plain-text passwords inside image environment variables

D.Using minimal base images (e.g., Distroless or Alpine) to reduce attack surface

E.Scanning container images for known CVEs during the CI/CD pipeline

AnswersD, E

Minimal base images such as Distroless or Alpine strip package managers, shells and unused libraries, directly shrinking the exploitable attack surface that supply chain vulnerabilities could target. Fewer installed components mean fewer known CVEs shipped inside the image, satisfying the stem's requirement to secure container images against supply chain vulnerabilities.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse 'minimal base image' (reduces attack surface) with 'running as non-root' (reduces privilege) — both are important but answer different questions, and the exam expects you to pick the supply-chain-specific controls.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Configuring ingress TLS certificates

B.Monitoring active Kubernetes node CPU utilization

C.Checking for insecure configuration settings or exposed secrets within image layers

D.Updating cluster network policies

E.Analyzing OS packages and application dependencies against known CVE databases

AnswersC, E

Scanning inspects image layers for misconfigurations and embedded secrets, such as hardcoded credentials or overly permissive file settings, satisfying the stem's requirement for tasks performed during container image vulnerability scanning. This static analysis of layer contents complements package vulnerability detection, addressing the configuration and secret exposure risks that image scanning tools routinely report.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse build-time image scanning (static analysis of layers, packages, and secrets) with runtime cluster monitoring (node metrics, network policies, TLS), so picking runtime controls is the classic wrong-answer trap.

Practice this question →

Multi-Selecthard

Which THREE of the following practices are recommended when securing container images to prevent supply chain attacks in a Kubernetes environment? (Choose THREE)

Select 3 answers

A.Always run container processes as the root user (UID 0) to ensure maximum compatibility with host mounts.

B.Integrate automated vulnerability scanning into the CI/CD pipeline before pushing images to the container registry.

C.Disable container image pull policies entirely so nodes only rely on locally cached images.

D.Utilize minimal base images (such as distroless or Alpine) to reduce the potential attack surface and remove unnecessary package managers.

E.Reference images by their immutable cryptographic digest (SHA256) rather than mutable tags like latest.

AnswersB, D, E

Scanning within CI/CD catches vulnerabilities before the image reaches the registry, blocking compromised artefacts at build time. This shifts detection left, so supply chain flaws are remediated before any cluster can pull the image, satisfying the requirement to prevent rather than merely detect attacks post-deployment.

Why this answer

Option B is correct because integrating automated vulnerability scanning (e.g., Trivy, Clair, or Grype) into the CI/CD pipeline catches known CVEs in OS packages and application dependencies before an image is pushed to the registry, blocking compromised artifacts at the earliest supply-chain stage. Option D is correct because minimal base images such as distroless or Alpine contain far fewer packages, libraries, and tools (often no shell or package manager), which shrinks the attack surface and denies attackers post-exploitation utilities. Option E is correct because referencing images by their immutable SHA256 digest guarantees the exact bits that were scanned and approved are what get deployed, preventing tag-mutation or tag-poisoning attacks where a mutable tag like latest is repointed to a malicious image.

Option A is not recommended: running as root (UID 0) violates least privilege, enables container-escape and host-mount abuse, and should be replaced with a non-root user plus runAsNonRoot and dropped capabilities. Option C is not recommended: disabling image pull policies undermines the registry as the trusted source of truth, prevents digest verification and signature checks, and lets stale or tampered local caches run unchecked.

Exam trap

KCSA often tests whether candidates conflate 'convenience' practices (root user, cached images) with security best practices — the trap is picking options that sound operationally simpler but directly undermine least privilege and patch velocity.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Integration with Linux security modules (Seccomp, AppArmor, SELinux)

B.Management of Kubernetes RBAC roles and cluster permissions

C.Namespace isolation (PID, network, mount, user namespaces) for containers

D.Automatic deployment of service mesh sidecar proxies

E.Automatic generation of Kubernetes Ingress TLS certificates

AnswersA, C

containerd and CRI-O apply Linux security modules such as Seccomp, AppArmor and SELinux profiles to constrain container syscalls and file access, enforcing mandatory access control at the kernel level. This integration hardens containers beyond namespace isolation alone, satisfying the security-feature requirement.

Why this answer

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.

Exam trap

KCSA often tests whether candidates attribute cluster-level controls (RBAC, ingress, service mesh) to the container runtime — only kernel-level isolation and LSM integration belong to the runtime.

Practice this question →

MCQeasy

An auditor is reviewing container image registries used by a Kubernetes cluster. They notice that public images are pulled directly without verification. Which security best practice should be implemented for image registries?

A.Grant cluster-admin permissions to all developers

B.Store plaintext passwords in ConfigMaps

C.Disable all network policies in the cluster

D.Use private registries with integrated vulnerability scanning and image pull policies

AnswerD

Private registries with integrated vulnerability scanning satisfy the stem's unverified public image pulls by enforcing authenticated access and admission control. Image pull policies such as Always ensure nodes retrieve vetted, scanned images rather than cached or unvetted layers, closing the supply-chain gap the auditor identified.

Why this answer

Using private registries with integrated vulnerability scanning and image pull policies ensures that only vetted, scanned images are deployed, and that the cluster enforces image provenance. This directly addresses the auditor's finding that public images are pulled without verification, because private registries can require authentication, enforce image signing (e.g., Cosign/Notary), and integrate scanners like Trivy or Clair. Kubernetes admission controllers (e.g., OPA Gatekeeper, Kyverno) can then enforce imagePullPolicy and registry allowlists.

Exam trap

KCSA often tests the misconception that Kubernetes natively verifies image signatures or that pulling from Docker Hub is inherently safe; candidates must recognize that verification requires external tooling and private registry controls.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all developers violates least privilege and massively expands the attack surface, having nothing to do with image verification. Option B is wrong because storing plaintext passwords in ConfigMaps exposes credentials to anyone with read access to the namespace and is explicitly discouraged by Kubernetes security guidance. Option C is wrong because disabling network policies removes microsegmentation and lateral-movement controls, which is the opposite of a security best practice.

Practice this question →

MCQhard

An enterprise cluster utilizes a service mesh with AuthorizationPolicies. You need to configure a policy that allows GET requests from service A to service B while explicitly denying DELETE requests on all paths. How are Istio AuthorizationPolicies evaluated when both allow and deny rules are present?

A.Only the most recently created authorization policy is evaluated

B.DENY rules take precedence and are evaluated before ALLOW rules

C.ALLOW rules take precedence and override any DENY rules

D.Rules are evaluated in alphabetical order of their object names

AnswerB

Istio evaluates DENY rules before ALLOW rules, so a matching DENY always overrides any ALLOW. The DELETE request is denied regardless of allow policies, while GET requests proceed only if an ALLOW rule also matches, giving deny precedence.

Why this answer

Istio AuthorizationPolicies follow a deny-first evaluation model: any matching DENY rule is enforced before ALLOW rules are considered. If a request matches a DENY rule, it is rejected regardless of whether an ALLOW rule would otherwise permit it. This ensures that explicit denials act as hard security boundaries that cannot be overridden by permissive allow policies.

Exam trap

The trap here is assuming ALLOW rules override DENY rules (as in some RBAC models), when Istio explicitly evaluates DENY first — a classic zero-trust gotcha.

How to eliminate wrong answers

Option A is wrong because Istio does not use creation timestamps to determine policy precedence; all policies are evaluated on every request. Option C is wrong because ALLOW rules do not override DENY rules — the opposite is true, and this misconception would create a security hole. Option D is wrong because Istio does not evaluate policies alphabetically by object name; evaluation is based on rule semantics (deny before allow), not naming conventions.

Practice this question →

MCQmedium

An administrator notices that a container in a Kubernetes cluster running containerd is attempting to write files to the root filesystem (/), which should be strictly immutable. Which configuration in the Pod's securityContext should be enforced to prevent this?

A.Set securityContext.allowPrivilegeEscalation to false

B.Set securityContext.readOnlyRootFilesystem to true

C.Set securityContext.privileged to false

D.Add the SYS_ADMIN capability to securityContext.capabilities.drop

AnswerB

Setting readOnlyRootFilesystem to true mounts the container's root filesystem read-only, so any write attempt to / fails with a filesystem error. This enforces immutability at the container level, satisfying the requirement without altering the underlying node or image.

Why this answer

securityContext.readOnlyRootFilesystem: true causes the container runtime to mount the container's root filesystem as read-only, so any write attempt to / (or any path not backed by a writable volume) fails with EROFS. This is the direct, purpose-built control for making the root filesystem immutable.

Exam trap

The trap here is that candidates see 'immutable filesystem' and pick allowPrivilegeEscalation or privileged: false because they sound security-related — the exam tests whether you know the exact securityContext field that controls root filesystem writability.

How to eliminate wrong answers

Option A is wrong because allowPrivilegeEscalation: false prevents a process from gaining more privileges than its parent (e.g., via setuid binaries), but it does not make the filesystem read-only. Option C is wrong because privileged: false simply means the container is not running in privileged mode — it still has a writable root filesystem by default. Option D is wrong because adding SYS_ADMIN grants additional capabilities (mount, namespace manipulation) and is a privilege escalation, not a filesystem restriction; capabilities.drop is the correct field for removing capabilities, not adding them.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Automatic kernel patch management for worker nodes

B.Fine-grained Layer 7 authorization policies between services

C.Provisioning of persistent block storage volumes

D.Automatic mutual TLS (mTLS) encryption for pod-to-pod communication

E.Managing container registry authentication tokens

AnswersB, D

Service meshes enforce Layer 7 policy at the sidecar proxy, evaluating HTTP method, path and identity per request rather than merely permitting a TCP connection. This delivers the fine-grained, identity-aware authorisation between services that network-level controls cannot express.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse service mesh security features (mTLS, L7 authorization) with infrastructure concerns (kernel patching, storage, registry auth), so picking non-mesh options is the common mistake.

Practice this question →

MCQhard

You are configuring an Ingress resource using the NGINX Ingress Controller to expose a sensitive internal application. To prevent unauthorized clients from connecting, you want to enable mutual TLS authentication at the ingress layer. Which annotation is required in the Ingress resource definition to specify the Kubernetes Secret containing the trusted Client CA certificate?

A.ingress.kubernetes.io/backend-protocol

B.nginx.ingress.kubernetes.io/auth-tls-secret

C.kubernetes.io/ingress.class

D.nginx.ingress.kubernetes.io/ssl-redirect

AnswerB

The auth-tls-secret annotation names the Kubernetes Secret holding the trusted Client CA bundle, enabling the NGINX Ingress Controller to verify client certificates during the mutual TLS handshake, satisfying the stem's requirement to authenticate clients at the ingress layer.

Why this answer

The annotation nginx.ingress.kubernetes.io/auth-tls-secret is the NGINX Ingress Controller directive that specifies the Kubernetes Secret containing the CA certificate used to verify client certificates for mutual TLS. When set, the controller enforces client certificate authentication at the ingress layer, rejecting connections that do not present a certificate signed by the trusted CA. This is the correct annotation for enabling mTLS with a trusted Client CA.

Exam trap

KCSA often tests the confusion between annotations that control TLS termination (ssl-redirect, backend-protocol) and those that enforce client certificate verification (auth-tls-secret), causing candidates to pick a TLS-related but incorrect annotation.

How to eliminate wrong answers

Option A is wrong because ingress.kubernetes.io/backend-protocol controls how the ingress communicates with the backend (HTTP, HTTPS, GRPC), not client certificate verification. Option C is wrong because kubernetes.io/ingress.class selects which ingress controller handles the resource — it has nothing to do with mTLS. Option D is wrong because nginx.ingress.kubernetes.io/ssl-redirect forces HTTP-to-HTTPS redirection, which is unrelated to client certificate authentication.

Practice this question →

MCQmedium

You need to ensure that an ingress controller processing TLS termination uses strong cryptographic ciphers and disables outdated protocols such as TLSv1.0 and TLSv1.1. Where are these TLS configuration settings typically managed in an NGINX Ingress deployment?

A.Ingress controller ConfigMap parameters such as ssl-ciphers and ssl-protocols

B.The core DNS configuration map

C.The kube-apiserver static pod manifest file

D.Persistent Volume Claim storage classes

AnswerA

NGINX Ingress reads TLS policy from controller-level ConfigMap keys, specifically `ssl-ciphers` and `ssl-protocols`, which set the cipher suite list and minimum protocol version for every server block. This satisfies the requirement to disable TLSv1.0 and TLSv1.1 and enforce strong ciphers centrally, rather than per-Ingress resource annotations.

Why this answer

In an NGINX Ingress deployment, TLS settings for the ingress controller are configured globally via ConfigMap parameters such as ssl-ciphers and ssl-protocols. These parameters allow administrators to specify the cipher suite and the minimum TLS version (e.g., TLSv1.2) that the controller will accept, ensuring strong cryptography and disabling outdated protocols like TLSv1.0 and TLSv1.1. This ConfigMap is typically named nginx-configuration and resides in the ingress-nginx namespace, and changes are applied by reloading the controller.

Exam trap

KCSA often tests the misconception that TLS settings for ingress are configured in the Ingress resource itself or in the API server, when in fact they are managed globally via the ingress controller's ConfigMap.

How to eliminate wrong answers

Option B is wrong because the core DNS configuration map (CoreDNS ConfigMap) is used to configure cluster DNS resolution, not ingress TLS settings. Option C is wrong because the kube-apiserver static pod manifest defines the API server's runtime parameters, not the ingress controller's TLS configuration. Option D is wrong because Persistent Volume Claim storage classes define storage provisioning policies, not cryptographic settings for ingress.

Practice this question →

MCQhard

An enterprise Kubernetes cluster uses a service mesh with strict authorization policies configured. A developer complains that their frontend service cannot communicate with the backend database service. Upon inspecting the mesh configuration, you notice a PeerAuthentication resource set to STRICT mode. What does this setting enforce?

A.Pod security standards must be enforced at the baseline level

B.Network policies must block all traffic from outside the namespace

C.All external ingress traffic must pass through a Web Application Firewall

D.All incoming traffic to the targeted workloads must use mutual TLS encryption

AnswerD

PeerAuthentication STRICT mode enforces mutual TLS on all inbound connections to the targeted workloads, so the frontend must present a valid mesh certificate before the backend accepts traffic. Plaintext connections are rejected, satisfying the strict encryption requirement that blocks the developer's unauthenticated request.

Why this answer

A PeerAuthentication resource in STRICT mode enforces mutual TLS (mTLS) for all incoming traffic to the targeted workloads, meaning both client and server must present valid certificates. This ensures encryption and identity verification between services in the mesh, and plaintext traffic is rejected. It is a core Istio security primitive for zero-trust service-to-service communication.

Exam trap

KCSA often tests candidates who confuse PeerAuthentication (mTLS enforcement) with AuthorizationPolicy (access control) or NetworkPolicy (L3/L4 filtering), leading them to pick network or WAF-related answers.

How to eliminate wrong answers

Option A is wrong because Pod Security Standards are enforced by Pod Security Admission, not by PeerAuthentication, which deals with transport security. Option B is wrong because network policies are Kubernetes NetworkPolicy or Cilium resources controlling L3/L4 traffic, not mTLS enforcement. Option C is wrong because WAF integration for external ingress is handled by ingress gateways or external WAF services, not by PeerAuthentication, which governs mesh-internal mTLS.

Practice this question →

Multi-Selectmedium

Which TWO actions should be taken when an image vulnerability scanner reports a critical CVE in a running production container? (Choose two)

Select 2 answers

A.Scale the vulnerable deployment replicas to maximum capacity

B.Rebuild the container image with updated base image or patched software packages

C.Redeploy the updated, patched image across the cluster workloads

D.Change all Kubernetes service account tokens to anonymous mode

E.Delete all Kubernetes NetworkPolicies to allow emergency patching traffic

AnswersB, C

Rebuilding with an updated base image or patched packages removes the vulnerable library version from the image layers, eliminating the CVE at its source. This satisfies remediation by producing a clean artefact rather than merely suppressing the scanner's report.

Why this answer

Option B is correct because the only durable way to remove a critical CVE from a container image is to rebuild it from a patched base image or updated software packages, since running containers are immutable and cannot be patched in place. Option C is correct because after rebuilding, the updated image must be redeployed to replace the vulnerable running containers across the cluster workloads, ensuring the fix is actually in production. Option A is wrong because scaling replicas to maximum capacity multiplies the number of vulnerable instances and does nothing to remediate the CVE.

Option D is wrong because setting service account tokens to anonymous mode would break authentication and massively weaken cluster security rather than fix the image flaw. Option E is wrong because deleting NetworkPolicies removes segmentation controls and exposes workloads, which is a security regression, not a remediation step.

Exam trap

KCSA often tests the misconception that scaling, deleting network policies, or changing authentication modes can mitigate a vulnerability, when the only correct remediation is rebuilding and redeploying the patched image.

Practice this question →

MCQeasy

What role does image scanning play in a shift-left security strategy for platform security?

A.Detecting vulnerabilities and misconfigurations in container images during development and CI/CD

B.Automatically encrypting secrets stored in etcd

C.Generating TLS certificates for ingress controllers

D.Enforcing role-based access control policies

AnswerA

Scanning container images during development and CI/CD catches vulnerabilities and misconfigurations before deployment, shifting detection left. This satisfies the stem's shift-left requirement by enforcing security earlier in the pipeline rather than at runtime, reducing remediation cost and exposure.

Why this answer

Image scanning in a shift-left strategy involves analyzing container images during development and CI/CD to detect vulnerabilities and misconfigurations before deployment. This early detection reduces risk and remediation costs by catching issues before they reach production.

Exam trap

KCSA often tests the scope of image scanning — candidates may confuse it with runtime security or secret management, but the question specifically ties it to shift-left and development phases.

How to eliminate wrong answers

Option B is wrong because encrypting secrets in etcd is a runtime data protection measure, not image scanning. Option C is wrong because generating TLS certificates is a PKI task, unrelated to image scanning. Option D is wrong because enforcing RBAC policies is an access control function, not image scanning.

Practice this question →

MCQhard

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?

A.Pod Disruption Budgets

B.Kubernetes NetworkPolicies

C.ResourceQuotas

D.Seccomp profiles

AnswerD

Seccomp profiles apply a predefined syscall filter to containers, blocking calls such as init_module and kexec_load. This directly satisfies the requirement to prevent module loading and debugging syscalls, since seccomp operates at the kernel syscall level per workload.

Why this answer

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.

Exam trap

KCSA often tests the distinction between syscall-level controls (seccomp) and network-level controls (NetworkPolicy), so candidates mistakenly choose NetworkPolicies when the question mentions syscalls like init_module.

How to eliminate wrong answers

Option A is wrong because Pod Disruption Budgets control voluntary disruptions during maintenance or scaling, not syscall filtering. Option B is wrong because NetworkPolicies govern pod-to-pod and pod-to-external network traffic at L3/L4, not system call execution. Option C is wrong because ResourceQuotas limit namespace-level resource consumption (CPU, memory, object counts), not syscall behavior.

Practice this question →

MCQeasy

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

A.To match package versions inside container images against known CVE databases and report vulnerabilities

B.To enforce network microsegmentation rules

C.To balance incoming web traffic across backend replicas

D.To automatically rotate cluster TLS certificates

AnswerA

Scanners extract installed package versions from image layers and compare them against CVE feeds, reporting matches. This satisfies the stem by identifying known vulnerabilities in image contents before deployment, rather than blocking runtime behaviour or enforcing policy.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse image scanning (build-time CVE detection) with runtime security controls like seccomp, AppArmor, or network policies — the scanner finds vulnerabilities, it does not prevent exploitation.

How to eliminate wrong answers

Option B is wrong because network microsegmentation is enforced by CNI plugins and Kubernetes NetworkPolicies, not by image scanners. Option C is wrong because traffic balancing across backend replicas is the job of a Service, Ingress controller, or load balancer, not a CVE database. Option D is wrong because TLS certificate rotation is handled by cert-manager, kubelet certificate rotation, or the cloud provider's control plane — vulnerability scanners do not manage certificates.

Practice this question →

MCQeasy

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?

A.Container runtime shim

B.Kube-proxy

C.Ingress controller

D.Sidecar proxy

AnswerD

The sidecar proxy is injected alongside each application container and transparently intercepts inbound and outbound traffic, performing mTLS handshakes and encryption. Applications need no code changes, satisfying the stem's constraint of enforcing mutual TLS across all microservices automatically.

Why this answer

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.

Exam trap

KCSA often tests the confusion between north-south traffic components (ingress controllers) and east-west traffic components (sidecar proxies), leading candidates to pick the ingress controller for internal service-to-service encryption.

How to eliminate wrong answers

Option A is wrong because the container runtime shim (e.g., containerd-shim) manages container lifecycle and low-level runtime operations, not application-layer traffic encryption. Option B is wrong because kube-proxy implements Kubernetes Service abstraction (iptables/IPVS rules) for load balancing, but it does not perform mTLS or application-layer encryption. Option C is wrong because an ingress controller handles north-south traffic entering the cluster (HTTP/HTTPS routing), not east-west mTLS between microservices.

Practice this question →

MCQeasy

A platform engineer wants to configure a container runtime security tool that monitors system calls and sends alerts about potential threats in a Kubernetes cluster. Which component of the container runtime architecture intercepts these system calls?

A.eBPF kernel probes

B.The coreDNS plugin

C.The Kubernetes storage controller

D.The kube-apiserver admission webhook

AnswerA

eBPF probes attach to kernel tracepoints and syscall hooks, letting the runtime security tool observe every system call a container makes without modifying kernel source or loading a module. This satisfies the requirement to intercept syscalls for threat alerting.

Why this answer

eBPF (extended Berkeley Packet Filter) kernel probes are the correct answer because they allow programs to run in the Linux kernel without changing kernel source code or loading modules. In container runtime security, tools like Falco, Tetragon, and Cilium use eBPF to hook into system calls (syscalls) and other kernel events, monitoring container behavior for threats. This interception happens at the kernel level, providing deep visibility into syscalls made by containers.

Exam trap

KCSA often tests the misconception that Kubernetes control plane components like admission webhooks or controllers handle runtime security, confusing API-level policy enforcement with kernel-level syscall monitoring.

How to eliminate wrong answers

Option B is wrong because CoreDNS is a DNS server that provides service discovery in Kubernetes; it does not intercept system calls. Option C is wrong because the Kubernetes storage controller manages persistent volumes and storage classes, not runtime security or syscall monitoring. Option D is wrong because the kube-apiserver admission webhook intercepts API requests to the Kubernetes API server for policy enforcement, not system calls made by containers.

Practice this question →

MCQeasy

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?

A.The Kubernetes Scheduler

B.An Admission Controller webhook

C.The kube-proxy daemonset

D.The container runtime (e.g., containerd)

AnswerB

Admission controllers sit in the API server request path, so a validating webhook can inspect each pod spec, query the image scanner, and reject the deployment when CVEs exceed the threshold. This satisfies the requirement to block non-compliant images before admission rather than detecting them post-deployment.

Why this answer

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.

Exam trap

KCSA often tests the admission control chain, tricking candidates into choosing the scheduler or runtime — components that act after admission — when the question specifically asks about pre-admission interception and blocking.

How to eliminate wrong answers

Option A is wrong because the Kubernetes Scheduler only decides which node a Pod runs on — it does not evaluate image security or block deployments based on CVE scans. Option C is wrong because kube-proxy is a network component that implements Service abstraction via iptables/IPVS rules; it has no role in admission decisions. Option D is wrong because the container runtime (containerd, CRI-O) pulls and runs images after scheduling — by the time the runtime is involved, the Pod has already been admitted, so it cannot serve as the primary pre-admission gate.

Practice this question →

MCQeasy

When configuring a Pod to run securely, which setting in the container's securityContext should be used to explicitly drop all default Linux capabilities and only retain required ones?

A.capabilities.drop: ["ALL"]

B.runAsNonRoot: true

C.capabilities.add: ["ALL"]

D.privileged: true

AnswerA

Dropping ALL first removes every default capability, then specific ones can be added back via capabilities.add. This satisfies the stem's requirement to explicitly drop all defaults while retaining only what the container genuinely needs, following least privilege.

Why this answer

In the container's securityContext, capabilities.drop: ["ALL"] removes every default Linux capability (like NET_RAW, CHOWN, SETUID) from the container process, after which you can selectively add back only what the workload needs via capabilities.add. This follows the principle of least privilege and is the canonical hardening pattern for Pods.

Exam trap

KCSA often tests whether candidates conflate runAsNonRoot with capability dropping — both are securityContext settings, but only capabilities.drop: ["ALL"] removes Linux capabilities.

How to eliminate wrong answers

Option B is wrong because runAsNonRoot only enforces that the container does not run as UID 0 — it does not touch Linux capabilities at all. Option C is wrong because capabilities.add: ["ALL"] grants every capability, which is the opposite of least privilege and effectively equivalent to privileged mode. Option D is wrong because privileged: true disables all capability restrictions and gives the container full access to the host, which is the least secure setting possible.

Practice this question →

MCQeasy

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?

A.readOnlyRootFilesystem: false

B.allowPrivilegeEscalation: false

C.privileged: true

D.runAsNonRoot: false

AnswerB

Setting `allowPrivilegeEscalation: false` applies the kernel's `no_new_privs` flag to the container process, preventing it from gaining additional privileges through setuid or setgid binaries, file capabilities, or similar mechanisms. This satisfies the stem's requirement that no new privileges can be acquired during the container's lifecycle, even when running as root.

Why this answer

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.

Exam trap

KCSA often tests the confusion between runAsNonRoot and allowPrivilegeEscalation — candidates mistakenly think that running as non-root alone prevents privilege escalation, but setuid binaries can still elevate privileges without no_new_privs.

How to eliminate wrong answers

Option A is wrong because readOnlyRootFilesystem: false actually disables the read-only root filesystem protection, which is unrelated to privilege escalation and would weaken security. Option C is wrong because privileged: true grants the container nearly all host capabilities and device access, which is the opposite of restricting privilege escalation. Option D is wrong because runAsNonRoot: false merely permits running as root; it does not prevent a process from gaining new privileges via setuid binaries or capabilities.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.Modifying CoreDNS forwarding upstream servers

B.PeerAuthentication resources enforcing STRICT mTLS mode between workloads

C.Configuring Horizontal Pod Autoscalers

D.Kubernetes PersistentVolumeClaim storage resize operations

E.Istio AuthorizationPolicy resources specifying allowed source principals and methods

AnswersB, E

PeerAuthentication with STRICT mTLS mode satisfies the in-mesh traffic restriction constraint by cryptographically authenticating workloads and rejecting plaintext connections. It enforces mutual TLS at the transport layer, so only workloads presenting valid SPIFFE identities from the mesh's certificate authority can communicate, blocking unauthenticated or spoofed traffic between services.

Why this answer

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.

Exam trap

KCSA often tests the confusion between network-level restrictions (like mTLS and authorization policies) and unrelated operational controls such as DNS, autoscaling, or storage, so candidates must recognize that only identity-based mesh policies restrict service-to-service traffic.

Practice this question →

MCQeasy

Why should container images be built using multi-stage builds in Dockerfiles from a security perspective?

A.They encrypt the container image layer storage in the registry

B.They automatically enable kernel-level eBPF monitoring

C.They exclude build-time tools, package managers, and source code from the final production image, reducing attack surface

D.They enforce mTLS encryption for all container network traffic

AnswerC

Multi-stage builds let the final stage copy only compiled artefacts, so compilers, package managers and source code never reach the production image. This directly satisfies the security goal of a minimal runtime footprint, shrinking the attack surface available to an attacker who compromises the running container.

Why this answer

Multi-stage builds let you use one stage (with compilers, package managers, source code, and build tools) to produce artifacts, then copy only the final binaries into a minimal runtime stage. The production image therefore excludes build-time tooling and source, shrinking the attack surface and eliminating many CVEs that come from build dependencies.

Exam trap

The trap is confusing build-time hygiene (multi-stage builds) with runtime or network security controls — candidates pick options mentioning encryption or monitoring because they sound security-related.

How to eliminate wrong answers

Option A is wrong because multi-stage builds have nothing to do with registry-side encryption — that is handled by registry features like OCI encryption or TLS. Option B is wrong because eBPF monitoring is a runtime kernel feature enabled by tools like Cilium or Falco, not by Dockerfile structure. Option D is wrong because mTLS is a network-layer concern configured via service mesh (Istio, Linkerd) or application code, not a Dockerfile build pattern.

Practice this question →

MCQhard

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?

A.CAP_CHOWN

B.CAP_NET_BIND_SERVICE

C.CAP_SYS_ADMIN

D.CAP_DAC_OVERRIDE

AnswerC

CAP_SYS_ADMIN is the broadest Linux capability, granting mount, namespace and network configuration privileges. Dropping it directly satisfies the stem's constraint that containers must not alter network settings or mount host filesystems, since those operations require this capability rather than narrower ones like CAP_NET_ADMIN alone.

Why this answer

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.

Exam trap

KCSA often tests whether candidates know that CAP_SYS_ADMIN is the 'super-capability' covering mounts and network admin, luring them toward narrower capabilities like CAP_CHOWN or CAP_NET_BIND_SERVICE that sound relevant but lack the required scope.

How to eliminate wrong answers

Option A is wrong because CAP_CHOWN only permits changing file ownership (chown) — it does not enable network reconfiguration or filesystem mounting. Option B is wrong because CAP_NET_BIND_SERVICE merely allows binding to privileged ports below 1024, a narrow networking privilege unrelated to host mounts or network stack changes. Option D is wrong because CAP_DAC_OVERRIDE bypasses file read/write/execute permission checks — dangerous for file access but not the capability that governs mount and network namespace operations.

Practice this question →

MCQhard

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?

A./var/log/containers/

B./etc/kubernetes/manifests/

C./var/lib/kubelet/seccomp/

D./etc/containerd/certs.d/

AnswerC

Placing the profile under /var/lib/kubelet/seccomp/ satisfies the kubelet's default seccomp root path, which is where containerd resolves local profiles referenced by the pod's securityContext. The pod spec then cites it relatively, such as localhost/profiles/block-modules.json, blocking module loading while permitting networking syscalls.

Why this answer

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.

Exam trap

KCSA often tests the confusion between various Kubernetes node directories — candidates must know that seccomp profiles live under /var/lib/kubelet/seccomp/, not in manifest, log, or containerd config directories.

How to eliminate wrong answers

Option A is wrong because /var/log/containers/ holds container log symlinks managed by the kubelet/container runtime, not seccomp profiles. Option B is wrong because /etc/kubernetes/manifests/ is where static pod manifests are placed for the kubelet to run control plane components — it has nothing to do with seccomp. Option D is wrong because /etc/containerd/certs.d/ is used for containerd registry TLS certificate configuration, not seccomp profiles.

Practice this question →

MCQmedium

You are configuring an Ingress object with TLS termination. The TLS certificate and private key are stored in a Kubernetes Secret. Which specific secret type must be used to ensure the ingress controller recognizes and validates the TLS credentials correctly?

A.kubernetes.io/tls

B.kubernetes.io/service-account-token

C.Opaque

D.kubernetes.io/dockerconfigjson

AnswerA

`kubernetes.io/tls` is the dedicated Secret type whose `tls.crt` and `tls.key` keys ingress controllers require for TLS termination. Generic `Opaque` secrets store the same data but lack the type marker, so the controller cannot recognise or validate the credentials, breaking the Ingress TLS configuration.

Why this answer

The kubernetes.io/tls secret type is specifically designed to hold a TLS certificate and its private key, with required keys 'tls.crt' and 'tls.key'. Ingress controllers look for this type to correctly load and validate the certificate for TLS termination.

Exam trap

KCSA often tests the assumption that any secret with the right keys works, but the exam expects knowledge that the kubernetes.io/tls type is required for ingress controllers to properly recognize and validate TLS credentials.

How to eliminate wrong answers

Option B is wrong because kubernetes.io/service-account-token is used to store a token for a service account, not TLS credentials. Option C is wrong because Opaque is a generic secret type for arbitrary data and does not guarantee the presence of the required TLS keys, so the ingress controller may not recognize it. Option D is wrong because kubernetes.io/dockerconfigjson is for storing Docker registry credentials, not TLS certificates.

Practice this question →

MCQhard

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?

A.HTTP plaintext tunneling

B.Pod security standard restriction

C.DNS-based load balancing

D.TLS re-encryption (or edge termination with backend mTLS)

AnswerD

The ingress gateway terminates inbound TLS, passes plaintext to the WAF for inspection, then re-encrypts with mTLS to backend pods. This decrypt-inspect-re-encrypt flow is TLS re-encryption, satisfying the mandate that traffic be inspected and re-encrypted before reaching pods.

Why this answer

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.

Exam trap

KCSA often tests the distinction between TLS termination, passthrough, and re-encryption — candidates may pick 'passthrough' or 'termination' without recognizing the re-encryption requirement.

How to eliminate wrong answers

Option A is wrong because HTTP plaintext tunneling describes unencrypted traffic forwarding, which contradicts the requirement for mTLS to backends and would violate security mandates. Option B is wrong because Pod Security Standards govern pod privilege and runtime settings, not traffic encryption or WAF inspection flows. Option C is wrong because DNS-based load balancing is a traffic distribution mechanism, not an encryption/inspection architecture.

Practice this question →

MCQhard

You are configuring a runtime security agent that uses Falco to detect unexpected shell execution inside containers. The security rule triggers when a process spawns a shell binary (e.g., bash or sh) inside a container namespace. Which underlying Linux kernel mechanism allows Falco to detect this event with minimal overhead?

A.Periodic polling of container logs using kubectl logs

B.eBPF system call tracing and kernel event capture

C.Analyzing CoreDNS lookup history

D.Inspecting etcd database keys every second

AnswerB

eBPF attaches programmes to kernel tracepoints and syscall hooks, capturing execve calls as they occur in the container namespace. This satisfies the minimal-overhead constraint because eBPF runs in-kernel without context-switching to userspace per event, unlike auditd or ptrace-based monitoring, letting Falco detect shell spawns efficiently.

Why this answer

Falco uses eBPF system call tracing and kernel event capture (B) to detect process executions like shell spawning with minimal overhead. eBPF allows Falco to hook into kernel tracepoints and syscalls without modifying the kernel or using heavy agents.

Exam trap

The trap is confusing log-based or API-based monitoring with kernel-level event capture. Candidates might think that kubectl logs or etcd inspection can detect runtime events, but only eBPF (or similar kernel mechanisms) provides the necessary real-time, low-level visibility.

How to eliminate wrong answers

Option A is wrong because periodic polling of container logs using kubectl logs is reactive, high-latency, and cannot reliably detect process execution events; it also misses events if logs are rotated. Option C is wrong because analyzing CoreDNS lookup history only provides DNS query data, not process execution. Option D is wrong because inspecting etcd database keys every second is inefficient, unrelated to runtime process monitoring, and would not detect shell execution inside containers.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Using sandboxed container runtimes (such as Kata Containers or gVisor) for strong isolation

B.Running all containers in privileged mode

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

D.Applying restrictive Seccomp profiles to block sensitive system calls

E.Dropping dangerous capabilities like CAP_SYS_ADMIN, CAP_NET_RAW, and CAP_SYS_PTRACE

AnswersA, D, E

Sandboxed runtimes such as Kata Containers and gVisor interpose a lightweight VM or user-space kernel between the container and the host kernel, so a container breakout exploit reaches only the sandbox boundary, not the shared host kernel.

Why this answer

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.

Exam trap

KCSA often tests the misconception that 'privileged mode' or host mounts improve performance/security; candidates must recognize these as anti-patterns that enable breakout, not prevent it.

Practice this question →

MCQhard

You are troubleshooting a service mesh traffic split policy where telemetry shows that unauthorized external clients are bypassing the service mesh ingress gateway and directly accessing backend services via NodePort services. Which Kubernetes feature should you configure to prevent direct NodePort access to these sensitive pods?

A.Enabling anonymous authentication in kube-apiserver

B.Changing the service type from NodePort to ClusterIP

C.Increasing the API server request rate limit

D.NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector

AnswerD

NetworkPolicies select pods by label and filter ingress at the CNI level, so only traffic from the gateway's pod selector reaches the backends. This blocks NodePort traffic arriving from any other source, closing the bypass the telemetry revealed.

Why this answer

NetworkPolicies restricting pod ingress traffic exclusively to the service mesh gateway pod selector (D) prevents direct NodePort access by only allowing traffic from the gateway. This enforces that all external traffic must go through the mesh ingress, where policies like mTLS and authorization are applied.

Exam trap

The trap is thinking that changing the service type or enabling authentication on the API server solves the bypass. Candidates must understand that NetworkPolicies are the correct tool to restrict pod-level ingress, and that service mesh security depends on enforcing that all traffic goes through the mesh.

How to eliminate wrong answers

Option A is wrong because enabling anonymous authentication on kube-apiserver weakens security and does not restrict NodePort access; it allows unauthenticated API requests. Option B is wrong because changing the service type from NodePort to ClusterIP would prevent external access entirely, but the requirement is to allow access only via the service mesh gateway, not to eliminate external access. Option C is wrong because increasing the API server request rate limit has no effect on NodePort traffic and does not address the security bypass.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Allowing privileged: true for all application containers

B.Restricting container capabilities to drop ALL and only permit essential ones like NET_BIND_SERVICE

C.Setting allowPrivilegeEscalation to false in the container securityContext

D.Mounting the host root filesystem in read-write mode

E.Requiring runAsNonRoot to be true

AnswersB, C, E

Dropping ALL Linux capabilities and adding back only required ones, such as NET_BIND_SERVICE, satisfies the restricted profile's capability constraint. The restricted policy mandates that containers drop every capability, permitting additions solely from a defined allowlist, which prevents privilege escalation through unnecessary kernel privileges.

Why this answer

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.

Exam trap

The trap is selecting options that seem secure but are actually prohibited, like allowing privileged containers or read-write host mounts. Candidates must remember that restricted profile is about denying all but the most essential permissions.

Practice this question →

MCQmedium

An organization requires that all container images pulled into a Kubernetes cluster are cryptographically signed and verified before execution. Which tool integrates with Kubernetes admission control to enforce signature verification using Cosign?

A.Cilium CNI plugin

B.Metrics-server

C.Kyverno policy engine

D.Helm package manager

AnswerC

Kyverno acts as a validating admission webhook, evaluating policies against pod specifications and rejecting workloads whose images lack valid Cosign signatures. This enforces cryptographic verification before execution, directly satisfying the stem's requirement that only signed images run in the cluster.

Why this answer

Kyverno is a Kubernetes-native policy engine that runs as a dynamic admission controller and can validate, mutate, and generate resources. It supports verifying Cosign signatures on container images via its verifyImages rule, rejecting any pod whose image lacks a valid signature from a trusted key or keyless identity. This makes it the correct tool for enforcing cryptographic image verification at admission time.

Exam trap

KCSA often tests candidates who assume any admission-capable tool (like Helm or Cilium) can verify Cosign signatures, when only policy engines with explicit image verification support can do so.

How to eliminate wrong answers

Option A is wrong because Cilium is a CNI and eBPF-based networking/security plugin focused on network policy and observability, not image signature verification. Option B is wrong because metrics-server only collects resource metrics for HPA and kubectl top, with no admission or policy capability. Option D is wrong because Helm is a package manager for templating and deploying Kubernetes manifests, not an admission controller that verifies image signatures.

Practice this question →

MCQmedium

A security engineer wants to inspect container runtime logs for potential security violations or runtime errors. Which log file or mechanism on a worker node managed by systemd and containerd provides container lifecycle events?

A.kubectl get events --all-namespaces

B.journalctl -u containerd

C./var/log/coredns.log

D./var/log/kube-apiserver.log

AnswerB

Containerd runs as a systemd unit, so its lifecycle events, image pulls and runtime errors are captured in the journal. Querying that unit with journalctl retrieves exactly those container events, matching the requirement to inspect runtime logs on a systemd-managed worker node.

Why this answer

On a worker node managed by systemd and containerd, container lifecycle events and runtime logs are captured by the containerd service. Using journalctl -u containerd retrieves these logs from the systemd journal, providing visibility into container start, stop, and errors. This is the correct mechanism for inspecting runtime logs at the node level.

Exam trap

KCSA often tests the difference between Kubernetes-level events (kubectl get events) and node-level runtime logs; candidates may incorrectly choose kubectl commands when the question specifies worker node and containerd.

How to eliminate wrong answers

Option A is wrong because kubectl get events retrieves Kubernetes API events, not container runtime logs, and may not include low-level containerd errors. Option C is wrong because /var/log/coredns.log is specific to CoreDNS, which handles DNS, not container runtime. Option D is wrong because /var/log/kube-apiserver.log is for the API server, not the container runtime on a worker node.

Practice this question →

MCQmedium

An Ingress controller is deployed in a cluster, and security auditors request that incoming traffic must be restricted to specific trusted external CIDR blocks. Which standard Ingress annotation is commonly supported by popular Ingress controllers (such as ingress-nginx) to achieve IP-based allowlisting?

A.ingress.kubernetes.io/allowed-source-cidrs

B.networking.k8s.io/ip-filter

C.nginx.ingress.kubernetes.io/whitelist-source-range

D.kubernetes.io/ingress.allow-ips

AnswerC

The whitelist-source-range annotation accepts a comma-separated list of trusted CIDR blocks, and ingress-nginx enforces it at the controller by rejecting requests whose source IP falls outside those ranges, directly satisfying the auditors' requirement to restrict incoming traffic to specific external networks.

Why this answer

The ingress-nginx controller supports the annotation nginx.ingress.kubernetes.io/whitelist-source-range, which accepts a comma-separated list of CIDR blocks. When set, the controller's NGINX configuration adds allow/deny directives so that only requests originating from those CIDRs are permitted; all other source IPs receive a 403. This is the standard, documented mechanism for IP allowlisting at the Ingress layer in ingress-nginx.

Exam trap

KCSA often tests whether candidates know the exact annotation namespace and syntax for ingress-nginx, baiting them with plausible-looking but non-existent annotations that mix API group names with feature descriptions.

How to eliminate wrong answers

Option A is wrong because ingress.kubernetes.io/allowed-source-cidrs is not a recognized annotation in ingress-nginx or other mainstream controllers — it resembles a plausible but fabricated name. Option B is wrong because networking.k8s.io/ip-filter is not a valid Ingress annotation; the networking.k8s.io API group is used for Ingress resource fields, not for this filtering feature. Option D is wrong because kubernetes.io/ingress.allow-ips is not a real annotation — kubernetes.io annotations exist for other purposes (e.g., ingress.class), but not for source IP allowlisting.

Practice this question →

MCQmedium

Your team is implementing image caching and proxying to protect against external container registry rate limits and security incidents. Which upstream project acts as a CNCF-compliant registry proxy and caching mechanism?

A.Harbor

B.Fluentd

C.Jaeger

D.Prometheus

AnswerA

Harbor is the CNCF-graduated registry that provides proxy caching, pulling and storing upstream images locally. This satisfies the requirement to shield clusters from external registry rate limits while enabling vulnerability scanning and policy enforcement on cached artefacts.

Why this answer

Harbor is a CNCF-graduated project that provides a container image registry with a built-in proxy cache. It can be configured to proxy and cache images from external registries like Docker Hub, mitigating rate limits and ensuring a local copy for security scanning. This makes it the correct answer for a CNCF-compliant registry proxy and caching mechanism.

Exam trap

KCSA often tests the distinction between CNCF projects and their primary functions; candidates may confuse monitoring (Prometheus) or logging (Fluentd) tools with registry solutions, but Harbor is the only registry-focused project among the options.

How to eliminate wrong answers

Option B is wrong because Fluentd is a log collector and processor, not a container registry proxy or cache. Option C is wrong because Jaeger is a distributed tracing system, unrelated to image caching. Option D is wrong because Prometheus is a monitoring and alerting toolkit, not a registry proxy.

Practice this question →

MCQmedium

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?

A.Deploying a validating admission policy or webhook to check image registry URLs

B.Configuring NodePort service selectors

C.Enabling horizontal pod autoscaling

D.Modifying the kube-proxy IPVS configuration

AnswerA

A validating admission policy or webhook intercepts pod creation requests before persistence, rejecting any container image whose registry URL is not registry.internal.corp. Because admission control operates at the API server level, it applies cluster-wide across all namespaces, satisfying the requirement to enforce the approved internal registry restriction.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse admission control (policy enforcement at API level) with networking or scaling mechanisms, so they pick NodePort or HPA options that sound cluster-wide but do not inspect image fields.

How to eliminate wrong answers

Option B is wrong because NodePort service selectors control how Services expose pods on node ports — they have no role in validating container image sources. Option C is wrong because Horizontal Pod Autoscaling adjusts replica counts based on metrics; it does not inspect or restrict image origins. Option D is wrong because kube-proxy IPVS configuration governs service load-balancing behavior at the network layer, not admission-time policy enforcement on Pod specs.

Practice this question →

MCQeasy

What is the primary security benefit of implementing Ingress TLS termination at the ingress controller rather than inside the application pods?

A.Automatically encrypting persistent volume storage

B.Centralized certificate management and reduced cryptographic overhead on application pods

C.Preventing the container runtime from executing untrusted binaries

D.Ensuring that all pod-to-pod communication is blocked

AnswerB

Terminating TLS at the ingress controller centralises certificate storage, rotation, and renewal in one place, and offloads cryptographic handshake work from application pods. This satisfies the goal of centralised certificate management with reduced per-pod cryptographic overhead.

Why this answer

Ingress TLS termination at the ingress controller centralizes TLS certificate management and offloads cryptographic operations from application pods. This means certificates are stored and rotated in one place (the ingress controller), and pods can handle plain HTTP, reducing their CPU overhead and simplifying certificate distribution. It also enables consistent TLS policies across multiple services.

Exam trap

KCSA often tests the misconception that Ingress TLS termination encrypts all traffic, including pod-to-pod or storage, when it only secures client-to-ingress traffic and offloads TLS from pods.

How to eliminate wrong answers

Option A is wrong because Ingress TLS termination does not encrypt persistent volume storage; that requires storage-level encryption (e.g., encrypted PVs or CSI drivers). Option C is wrong because preventing untrusted binary execution is a runtime security concern (e.g., seccomp, AppArmor), not related to TLS termination. Option D is wrong because Ingress TLS termination does not block pod-to-pod communication; network policies are needed for that, and TLS termination actually allows encrypted traffic from clients to the ingress, not blocking internal traffic.

Practice this question →

MCQmedium

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?

A.shareProcessNamespace: false

B.automountServiceAccountToken: false

C.hostIPC: false

D.hostNetwork: false

AnswerB

Setting automountServiceAccountToken to false stops the projected service account token being mounted into the pod's filesystem. Without that credential, code execution inside the container cannot authenticate to the Kubernetes API server, shrinking the blast radius.

Why this answer

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.

Exam trap

KCSA often tests whether candidates know that automountServiceAccountToken is the specific control for removing API credentials from pods, while hostNetwork, hostIPC, and shareProcessNamespace are namespace-isolation controls that do not address token exposure.

How to eliminate wrong answers

Option A is wrong because shareProcessNamespace controls whether containers in a pod share a PID namespace; it has no bearing on API server credentials. Option C is wrong because hostIPC only affects whether the pod shares the host's IPC namespace — it does not remove the mounted service account token. Option D is wrong because hostNetwork controls whether the pod uses the host network stack; while it is a security-relevant setting, it does not prevent the service account token from being mounted and abused.

Practice this question →

MCQmedium

You are troubleshooting a container image vulnerability scan report that flagged a high-severity CVE in a base image layer. The development team wants to ensure that vulnerable container images are automatically prevented from being deployed to any namespace in the cluster. Which Kubernetes mechanism should you implement?

A.Enable resource quotas on the default namespace

B.Rotate the cluster certificate authority

C.Add network policies to restrict outbound CVE database queries

D.Configure a validating admission webhook to inspect image metadata and reject deployments with known CVEs

AnswerD

A validating admission webhook intercepts pod creation requests, queries image metadata against vulnerability data, and rejects any workload whose image contains known CVEs. This enforces prevention cluster-wide at admission time, satisfying the requirement to block deployment automatically.

Why this answer

A validating admission webhook intercepts pod creation requests before they are persisted to etcd and can inspect image metadata (via registries or scanning tools) to reject deployments containing known CVEs. This enforces policy at the cluster level across all namespaces, preventing vulnerable images from ever running.

Exam trap

KCSA often tests whether candidates confuse admission control (pre-deployment enforcement) with runtime controls like NetworkPolicies or quotas — only admission webhooks can block deployments based on image content.

How to eliminate wrong answers

Option A is wrong because resource quotas limit CPU/memory/object counts, not image vulnerability status, and they do not block deployments based on CVE content. Option B is wrong because rotating the cluster certificate authority is a PKI hygiene task unrelated to image vulnerability enforcement. Option C is wrong because network policies control pod-to-pod traffic and cannot inspect image metadata or block deployments; restricting outbound CVE database queries would actually break scanning, not enforce it.

Practice this question →

Multi-Selecthard

Which THREE mechanisms are used in a zero-trust platform security model for cloud-native applications? (Choose three)

Select 3 answers

A.Granting cluster-admin permissions to all application service accounts

B.Implementing microsegmentation via Kubernetes NetworkPolicies and service mesh auth policies

C.Enforcing mutual TLS (mTLS) for all internal service-to-service communications

D.Applying strict admission webhook policies to validate workloads before creation

E.Assuming internal cluster networks are fully secure and trusting all pods by default

AnswersB, C, D

Microsegmentation enforces least-privilege east-west traffic between workloads, satisfying zero trust's assumption of no implicit internal trust. Kubernetes NetworkPolicies filter pod-level IP and port flows, while service mesh authorisation policies add identity-based mTLS verification at layer seven, together restricting lateral movement within the cluster.

Why this answer

Option B is correct because zero-trust requires microsegmentation, and Kubernetes NetworkPolicies restrict pod-to-pod traffic at L3/L4 while service mesh authorization policies (e.g., Istio AuthorizationPolicy) enforce identity-based L7 access controls between workloads. Option C is correct because enforcing mutual TLS for all internal service-to-service communications cryptographically verifies both client and server identities, eliminating implicit trust based on network location. Option D is correct because admission webhooks (ValidatingAdmissionWebhook) intercept API server requests before object persistence, allowing policies to reject non-compliant workloads and enforce security baselines at creation time.

Option A is incorrect because granting cluster-admin to all service accounts violates least privilege and massively expands the blast radius, the opposite of zero-trust. Option E is incorrect because assuming the internal network is secure and trusting all pods by default is the classic perimeter-trust model that zero-trust explicitly rejects.

Exam trap

KCSA often tests whether candidates conflate zero-trust with 'trust everything inside the cluster' — the exam expects you to reject any option that assumes implicit trust based on network location.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.The kube-apiserver etcd storage backend encryption key

B.The coreDNS server managing TLS private keys

C.The persistent volume CSI controller

D.The Ingress resource object defining routing rules and TLS hosts

E.The Ingress Controller pod implementing the reverse proxy logic

AnswersD, E

The Ingress resource holds the routing rules and TLS host definitions that the controller reads and translates into proxy configuration. Without this object, the controller has no host or path mapping to program, so it is a required component in the traffic path.

Why this answer

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.

Exam trap

The trap here is that candidates pick CoreDNS or etcd because they are 'Kubernetes components' — the exam tests whether you know that Ingress routing involves only the Ingress resource and the Ingress Controller, not the control-plane data stores.

Practice this question →

MCQmedium

An administrator needs to configure an Ingress resource to route traffic securely to a backend service using HTTPS (TLS between the ingress controller and the backend pod). Which NGINX Ingress annotation enables this backend HTTPS communication?

A.nginx.ingress.kubernetes.io/ssl-redirect: "true"

B.nginx.ingress.kubernetes.io/proxy-connect-timeout

C.nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"

D.nginx.ingress.kubernetes.io/cors-allow-origin

AnswerC

The `nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"` annotation instructs the NGINX ingress controller to establish TLS when connecting to the backend pod, satisfying the stem's requirement for HTTPS between controller and service. Without it, NGINX defaults to plain HTTP to the backend, so traffic would be unencrypted regardless of the client-facing TLS configuration.

Why this answer

The annotation nginx.ingress.kubernetes.io/backend-protocol: "HTTPS" tells the NGINX Ingress Controller to speak HTTPS when connecting to the backend service, enabling TLS between the controller and the pod. This is the standard way to terminate TLS at the ingress and re-encrypt to the backend, satisfying end-to-end encryption requirements. Without this annotation, NGINX defaults to HTTP for backend connections even if the Service port is named 'https'.

Exam trap

KCSA often tests whether candidates confuse client-side TLS enforcement (ssl-redirect) with backend transport encryption (backend-protocol), causing them to pick the redirect annotation when the question asks about ingress-to-pod TLS.

How to eliminate wrong answers

Option A is wrong because ssl-redirect only forces HTTP clients to redirect to HTTPS at the ingress listener; it does not affect the protocol used between the ingress controller and the backend pod. Option B is wrong because proxy-connect-timeout only controls how long NGINX waits for a TCP connection to the upstream — it has no bearing on whether TLS is used. Option D is wrong because cors-allow-origin configures Cross-Origin Resource Sharing response headers for browser clients, which is unrelated to backend transport security.

Practice this question →

MCQhard

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?

A.By disabling all system calls related to file I/O

B.By routing all device access requests through kube-proxy

C.By applying a default device allowlist that restricts access to essential devices like /dev/null and /dev/random

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

AnswerC

Docker and containerd apply a default device cgroup allowlist permitting only essential nodes such as /dev/null, /dev/zero, /dev/random and tty devices. Without a custom profile, all other host device nodes remain inaccessible, satisfying the restriction requirement.

Why this answer

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.

Exam trap

KCSA often tests the misconception that containers have unrestricted device access by default — candidates may think the host /dev is mounted, but the default allowlist is a key security control.

How to eliminate wrong answers

Option A is wrong because disabling all file I/O syscalls would break the container entirely and is not how device access is restricted. Option B is wrong because kube-proxy handles network routing, not device access. Option D is wrong because mounting the entire host /dev read-write would be a severe security risk and is not the default behavior.

Practice this question →

MCQeasy

Why is running containers as the root user discouraged in Kubernetes platform security best practices?

A.It prevents the kubelet from starting the pod

B.It disables network policy enforcement

C.It stops container image vulnerability scanning

D.It increases the impact of potential container breakout or compromise by granting root privileges inside the container

AnswerD

Root inside a container maps to a privileged UID; if the container escapes via a kernel or runtime flaw, the attacker inherits those root capabilities on the host. Running as a non-root user constrains the privileges available after compromise.

Why this answer

Running containers as root is discouraged because if an attacker compromises the container, they gain root privileges inside it. This significantly increases the impact of a container breakout or lateral movement, as root can modify files, install tools, and potentially exploit kernel vulnerabilities to escape to the host. Kubernetes security best practices, such as those in the CIS Benchmarks and Pod Security Standards, therefore recommend running containers as non-root users to enforce least privilege.

Exam trap

KCSA often tests the misconception that running as root directly causes pod failure or disables security features like network policies, when the real risk is the increased blast radius upon compromise.

How to eliminate wrong answers

Option A is wrong because the kubelet does not prevent pods from starting based on the user ID; it starts containers regardless of whether they run as root or non-root. Option B is wrong because network policy enforcement is handled by the CNI plugin and is independent of the user ID inside the container; running as root does not disable it. Option C is wrong because container image vulnerability scanning is performed by external tools (e.g., Trivy, Clair) and is not affected by the runtime user; scanning occurs on the image, not the running container.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Exposing all internal debugging endpoints via unencrypted HTTP on port 80

B.Enforcing TLS termination with strong cipher suites and valid certificates

C.Disabling all authentication mechanisms at the ingress gateway

D.Restricting ingress controller exposure and using Web Application Firewalls (WAF)

E.Storing TLS private keys in plaintext ConfigMaps

AnswersB, D

Enforcing TLS termination with strong cipher suites and valid certificates encrypts data in transit at the Ingress controller, satisfying the requirement to secure external traffic entering the cluster. This prevents eavesdropping and man-in-the-middle attacks on HTTP routes, directly addressing the stem's Ingress security constraint.

Why this answer

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.

Exam trap

KCSA often tests the assumption that any HTTP exposure is acceptable if internal, or that authentication can be safely disabled at the edge, when in fact encryption, authentication, and exposure restriction are all required for secure ingress.

Practice this question →

MCQhard

A platform engineer needs to secure an Ingress resource using TLS termination, ensuring that sensitive private keys are stored securely within the cluster and referenced safely. Which Kubernetes resource should be created to store the TLS certificate and private key pair?

A.Secret of type kubernetes.io/tls

B.PersistentVolumeClaim

C.CertificateSigningRequest

D.ConfigMap

AnswerA

A kubernetes.io/tls Secret holds the certificate and private key as base64-encoded data, and the Ingress controller reads it directly for TLS termination. This satisfies the stem's constraint that keys stay inside the cluster and are referenced safely rather than embedded in the Ingress spec.

Why this answer

A Secret of type kubernetes.io/tls is the correct resource because it is specifically designed to hold a TLS certificate and its private key. The Ingress resource references this Secret in its tls section, and the ingress controller uses it to terminate TLS. Kubernetes treats this Secret type with appropriate handling for the required tls.crt and tls.key fields.

Exam trap

KCSA often tests the confusion between Secrets and ConfigMaps for sensitive data, and between CertificateSigningRequest (for issuing certs) and kubernetes.io/tls Secrets (for storing cert/key pairs used by Ingress).

How to eliminate wrong answers

Option B is wrong because a PersistentVolumeClaim provides storage, not secret storage — it cannot hold certificate/key data. Option C is wrong because a CertificateSigningRequest is used to request a certificate from a CA (e.g., for client certs or kubelet certs), not to store an existing TLS key pair for Ingress. Option D is wrong because a ConfigMap stores non-sensitive configuration data in plaintext and is not appropriate for private keys; using it would expose the key.

Practice this question →

Multi-Selectmedium

Which TWO of the following mechanisms are standard methods used by container runtimes (such as containerd or CRI-O) to isolate container workloads from the host kernel and other containers? (Choose TWO)

Select 2 answers

A.Disabling the Linux virtual memory manager cluster-wide

B.Hypervisor-based hardware virtualization for every container instance

C.Executing all container processes inside the host root process namespace

D.Control Groups (cgroups)

E.Linux Namespaces

AnswersD, E

Control groups limit and account for CPU, memory, and I/O consumed by container processes, preventing one workload from starving the host or neighbours. This resource-isolation mechanism complements namespace isolation, satisfying the stem's requirement for standard runtime isolation methods.

Why this answer

Option D (Control Groups, cgroups) is correct because container runtimes such as containerd and CRI-O use cgroups to limit and account for resources like CPU, memory, block I/O, and PIDs, preventing one container from starving or affecting others. Option E (Linux Namespaces) is correct because runtimes use namespaces (PID, mount, network, UTS, IPC, user, cgroup) to give each container its own isolated view of processes, filesystems, networking, and other kernel resources. Together, cgroups and namespaces are the foundational Linux kernel primitives that standard container runtimes rely on for isolation.

Option A is wrong because disabling the virtual memory manager cluster-wide is neither possible nor a container isolation mechanism; it would break the host. Option B is wrong because standard runtimes like containerd and CRI-O share the host kernel and do not spin up a hypervisor per container (that describes VM-based sandboxes such as Kata Containers). Option C is wrong because running all container processes in the host root PID namespace would remove PID isolation rather than provide it.

Exam trap

KCSA often tests whether candidates confuse container isolation primitives (namespaces + cgroups) with VM-based isolation (hypervisors), so the trap is picking 'hypervisor-based virtualization' as a standard container runtime mechanism.

Practice this question →

MCQhard

A security engineer is configuring a service mesh using Istio to ensure that all east-west traffic between microservices is mutually authenticated and encrypted. Which custom resource must be configured with a STRICT mTLS mode to enforce this requirement cluster-wide?

A.PeerAuthentication

B.EnvoyFilter

C.AuthorizationPolicy

D.DestinationRule

AnswerA

PeerAuthentication enforces mutual TLS between sidecar proxies, and setting its mtls.mode to STRICT cluster-wide (via the mesh-wide policy in the istio-system namespace) rejects all plaintext east-west traffic. This directly satisfies the requirement that every microservice-to-microservice connection be mutually authenticated and encrypted, unlike RequestAuthentication, which only validates end-user JWTs.

Why this answer

PeerAuthentication is the Istio custom resource used to configure mTLS settings for workloads. Setting its mTLS mode to STRICT enforces mutual TLS for all traffic to and from the selected workloads, ensuring east-west traffic is authenticated and encrypted.

Exam trap

The trap is confusing PeerAuthentication with DestinationRule or AuthorizationPolicy. Candidates might think DestinationRule enforces mTLS, but it only configures outbound TLS settings; PeerAuthentication is the resource that enforces mTLS on the server side.

How to eliminate wrong answers

Option B is wrong because EnvoyFilter is used to customize the Envoy proxy configuration, not to enforce mTLS policies directly. Option C is wrong because AuthorizationPolicy controls access based on identities and conditions, but it does not enforce encryption; it assumes mTLS is already in place. Option D is wrong because DestinationRule configures traffic policies like load balancing and connection pools, and while it can specify TLS settings for outbound traffic, it does not enforce mTLS cluster-wide; PeerAuthentication is the correct resource for mTLS enforcement.

Practice this question →

Multi-Selecthard

Which THREE of the following features or configurations are associated with securing Ingress traffic in a Kubernetes cluster? (Choose THREE)

Select 3 answers

A.Configuring TLS blocks in the Ingress resource referencing a kubernetes.io/tls Secret.

B.Directly exposing internal Pod clusterIPs to the public internet via kube-proxy bypass rules.

C.Integrating Web Application Firewall (WAF) modules or OAuth/OIDC authentication filters via Ingress annotations or middleware.

D.Removing all network policies so the Ingress controller can freely probe unmanaged host ports.

E.Using annotations to enforce HTTP-to-HTTPS redirection so unencrypted traffic is automatically upgraded.

AnswersA, C, E

TLS blocks in an Ingress reference a kubernetes.io/tls Secret holding the certificate and private key, so the ingress controller terminates HTTPS for the named hosts. This encrypts client-to-cluster traffic, satisfying the requirement to secure Ingress traffic in transit.

Why this answer

Option A is correct because a Kubernetes Ingress resource secures traffic by defining a TLS block that references a kubernetes.io/tls Secret containing the certificate and private key, enabling the Ingress controller to terminate TLS for the specified hosts. Option C is correct because Ingress controllers commonly support annotations or middleware (for example NGINX Ingress annotations or Traefik middleware) that attach WAF modules or OAuth/OIDC authentication filters to protect inbound HTTP(S) traffic before it reaches backend Services. Option E is correct because annotations such as nginx.ingress.kubernetes.io/force-ssl-redirect or ssl-redirect enforce HTTP-to-HTTPS redirection, ensuring clients are automatically upgraded to encrypted connections.

Option B is incorrect because bypassing kube-proxy to expose Pod clusterIPs directly to the internet is not a supported or secure Ingress practice and defeats the purpose of controlled ingress. Option D is incorrect because removing all NetworkPolicies weakens cluster security and is unrelated to securing Ingress traffic; NetworkPolicies govern pod-to-pod traffic, not Ingress TLS or authentication.

Exam trap

KCSA often tests the confusion between Ingress-level security controls (TLS, WAF, redirects) and Pod-level controls (network policies, security contexts) — candidates pick options that sound secure but actually weaken the cluster.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Enabling automated vulnerability scanning upon image push

B.Enforcing role-based access control (RBAC) on registry repositories

C.Storing registry admin credentials in plaintext inside Dockerfiles

D.Allowing anonymous write access to public repositories

E.Using image signing and verification (e.g., Notary or Cosign) to guarantee artifact integrity

AnswersA, B, E

Automated vulnerability scanning on push inspects image layers against known CVE databases immediately, blocking flawed artefacts before they reach production. This satisfies the stem's requirement by securing the distribution pipeline at the earliest registry ingestion point.

Why this answer

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.

Exam trap

The trap is selecting obviously insecure options (plaintext credentials, anonymous write access) as if they were security practices, when the question asks for critical practices — candidates must recognize these as anti-patterns.

Practice this question →

MCQmedium

Your security team has discovered that an application container image contains outdated packages with known remote code execution vulnerabilities. Which phase of the software development lifecycle is the most effective place to initially scan and remediate these vulnerabilities?

A.Node OS package manager updates

B.Kubelet container startup phase

C.CI/CD pipeline build stage

D.Kubernetes API server audit logging

AnswerC

Scanning at the CI/CD build stage catches vulnerable packages before the image is published, so remediation happens once rather than per deployment. This satisfies the requirement to fix outdated packages at the earliest effective point in the lifecycle.

Why this answer

Scanning in the CI/CD pipeline build stage catches vulnerable packages before the image is pushed to a registry or deployed, enabling remediation at the earliest point where the development team can act. This shifts security left, prevents vulnerable artifacts from propagating, and integrates with build gates that fail the pipeline on critical CVEs. Tools like Trivy, Clair, or Snyk run here.

Exam trap

KCSA often tests the misconception that runtime scanning (kubelet startup) or host patching is the 'most effective' place; the exam expects shift-left reasoning, making the CI/CD build stage the correct answer.

How to eliminate wrong answers

Option A is wrong because node OS package manager updates address host-level packages, not application container image contents, and occur after the image is already built. Option B is wrong because kubelet container startup is a runtime phase where scanning would block or delay deployment but not prevent the vulnerable image from being stored and potentially used elsewhere. Option D is wrong because API server audit logging records actions for compliance/forensics and does not scan or remediate image vulnerabilities.

Practice this question →

MCQhard

A security engineer must ensure that a Deployment's pods always run with a read-only root filesystem, drop all Linux capabilities, and are prevented from running as root, without modifying the application's container image or Dockerfile. Which Kubernetes-native mechanism should the engineer use?

A.Create a ValidatingAdmissionPolicy that rejects any pod without the desired security settings.

B.Configure a seccomp profile of type `RuntimeDefault` on the pod and rely on it to drop capabilities and enforce a read-only root filesystem.

C.Apply a PodSecurityPolicy with `readOnlyRootFilesystem: true`, `requiredDropCapabilities: ["ALL"]`, and `runAsNonRoot: true`.

D.Set `securityContext.readOnlyRootFilesystem`, `securityContext.capabilities.drop: ["ALL"]`, and `securityContext.runAsNonRoot: true` in the pod template of the Deployment.

AnswerD

These fields in the pod template's securityContext are applied by the kubelet when starting the container, so they take effect without changing the image. `readOnlyRootFilesystem` mounts the root filesystem read-only, dropping ALL capabilities removes privileged kernel operations, and `runAsNonRoot` forces the kubelet to reject images whose user is root. This meets all three requirements natively.

Why this answer

The pod-level securityContext is the correct native control because the kubelet translates these fields into container runtime settings at start time, achieving read-only root filesystem, capability removal, and non-root execution without rebuilding the image. PodSecurityPolicy is removed, ValidatingAdmissionPolicy only denies rather than mutates, and seccomp governs syscalls, not filesystem or capability state.

Exam trap

The trap here is treating seccomp or admission validation as if it could enforce filesystem and capability restrictions that only the container securityContext actually applies.

Practice this question →

Multi-Selecthard

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

Select 3 answers

A.Verifying cryptographic image signatures using tools like Cosign

B.Requiring container images to be pulled exclusively from approved enterprise registries

C.Automatically updating kernel modules on the underlying worker node

D.Manually restarting unhealthy pods across worker nodes

E.Blocking deployments of images that contain unmitigated high-severity vulnerabilities

AnswersA, B, E

Admission webhooks evaluate pod specs before persistence, so they can verify Cosign signatures against a trusted public key and reject unsigned or tampered images. This enforces cryptographic provenance at admission time, satisfying the image-signature verification control.

Why this answer

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.

Exam trap

The trap is assuming admission webhooks can perform node-level or runtime actions (like kernel updates or pod restarts) when they only enforce policies on API objects at admission time.

Practice this question →

MCQmedium

You are reviewing a security alert indicating that a container running in your Kubernetes cluster attempted to modify host kernel parameters via /proc/sys. Which security configuration was likely missing or misconfigured for this container?

A.The CoreDNS deployment had too few replicas

B.The Ingress controller did not enable TLS termination

C.The PersistentVolumeClaim lacked a storage class

D.The container was run in privileged mode or lacked necessary capability and filesystem hardening

AnswerD

Writing to /proc/sys requires privileged mode or granted CAP_SYS_ADMIN plus a writable proc filesystem. Dropping capabilities, enforcing a read-only root filesystem and applying Pod Security Admission would have blocked the sysctl modification, so hardening was missing.

Why this answer

Modifying host kernel parameters via /proc/sys requires write access to the host's sysctl interface, which is only possible if the container is running in privileged mode or has been granted dangerous capabilities (e.g., CAP_SYS_ADMIN) and lacks filesystem hardening such as a read-only /proc/sys mount or seccomp/AppArmor restrictions. A properly hardened container using Pod Security Standards (restricted) or a securityContext with readOnlyRootFilesystem, dropped capabilities, and no privileged flag would block this.

Exam trap

KCSA often tests whether candidates can map a runtime symptom (host kernel modification) to the correct securityContext misconfiguration — distractors pull toward unrelated Kubernetes components (CoreDNS, Ingress, PVC) to test whether you understand the container isolation model.

How to eliminate wrong answers

Option A is wrong because CoreDNS replica count affects DNS availability and resilience, not a container's ability to write to host kernel parameters — it is unrelated to the alert. Option B is wrong because Ingress TLS termination is about encrypting external traffic to services; it has no bearing on whether a container can modify /proc/sys. Option C is wrong because a missing StorageClass affects PersistentVolumeClaim binding and storage provisioning, not kernel parameter access — it is a storage-layer misconfiguration, not a security-context one.

Practice this question →

Multi-Selecteasy

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

Select 2 answers

A.Enforcing non-root execution via container securityContext

B.Mounting the Docker socket inside application containers

C.Using read-only root filesystems to prevent tampering with binaries

D.Disabling all seccomp and AppArmor profiles

E.Granting CAP_SYS_ADMIN to all containers by default

AnswersA, C

A securityContext with runAsNonRoot and a non-zero runAsUser forces the container process to run unprivileged, blocking root-owned process escapes and privilege escalation on the node. This directly satisfies the stem's requirement for improved container runtime security on Kubernetes nodes.

Why this answer

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.

Exam trap

The trap here is that candidates see 'securityContext' and pick every option that mentions it, forgetting that privileged: true, added capabilities, and socket mounts are anti-patterns — the exam tests whether you recognize hardening versus weakening controls.

Practice this question →