Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 601–675

997 questions total · 14pages · All types, answers revealed

Take a mock examExam hub
Page 8

Page 9 of 14

Page 10
601
MCQeasy

An administrator runs 'kubectl get pods' and sees that a pod is in 'Pending' state. What is the most likely reason for this state?

A.The pod has been deleted
B.The container inside the pod is crashing
C.The pod is waiting to be scheduled to a node
D.The pod has completed its execution
AnswerC

Pending indicates the pod has not been scheduled yet.

Why this answer

A pod enters the 'Pending' state when it has been accepted by the API server but is not yet running. The most common reason is that the scheduler has not yet assigned the pod to a node, often due to insufficient resources (CPU/memory), node selector mismatches, taints/tolerations, or a failed scheduler itself. This is the initial phase before the pod transitions to 'Running' or 'ContainerCreating'.

Exam trap

CNCF often tests the distinction between 'Pending' (scheduling issue) and 'ContainerCreating' (image pull or container start delay), so the trap here is confusing a pending scheduling state with a container runtime issue.

How to eliminate wrong answers

Option A is wrong because a deleted pod would not appear in 'kubectl get pods' output at all, or would show as 'Terminating' briefly before removal. Option B is wrong because a crashing container inside the pod would result in a 'CrashLoopBackOff' or 'Error' state, not 'Pending'. Option D is wrong because a pod that has completed its execution (e.g., a Job) would show as 'Completed' or 'Succeeded', not 'Pending'.

Full explanation →
602
MCQeasy

A security best practice for Dockerfiles is to avoid hardcoded secrets. Which Dockerfile instruction is MOST likely to contain a hardcoded secret?

A.ENV
B.EXPOSE
C.RUN
D.FROM
AnswerA

ENV sets environment variables that can contain hardcoded secrets.

Why this answer

The 'ENV' instruction can set environment variables, but secrets should not be hardcoded. However, 'ARG' is often used for passing build-time variables, but can also contain secrets if not careful. The most common culprit is 'ENV' with a secret value.

Full explanation →
603
MCQhard

You need to configure Kubernetes audit logging to log all requests at the Metadata level except for requests to the 'kube-system' namespace, which should be logged at Request level. How should you structure the audit policy?

A.Default level Metadata with a rule that has 'level: Request' and 'namespaces: [kube-system]'
B.Use two rules with 'level: Request' and 'level: Metadata' without default
C.Default level Request with a rule for kube-system at Metadata
D.Default level Metadata with a rule for kube-system at Request
AnswerA

The rule for kube-system overrides the default for that namespace.

Why this answer

The policy defines rules with levels and optional namespaces. Rules are evaluated in order; the first matching rule applies.

Full explanation →
604
MCQhard

You need to create a ClusterRole that allows listing secrets, but only in namespaces that have a specific label 'security-level=high'. Which approach should you use?

A.Create a ClusterRole and bind it with RoleBindings in each labeled namespace
B.Create a Role in each namespace, then aggregate them into a ClusterRole
C.Create a ClusterRole and bind it with a ClusterRoleBinding; add a namespace condition in the role
D.Create a ClusterRole with a namespaceSelector: matchLabels: security-level: high
AnswerA

ClusterRole can be used with RoleBindings to grant permissions only in selected namespaces.

Why this answer

Option A is correct because ClusterRoleBindings grant permissions cluster-wide, but RoleBindings can bind a ClusterRole to subjects within specific namespaces. By creating a ClusterRole with the necessary rules (e.g., 'list secrets') and then creating RoleBindings only in namespaces that have the label 'security-level=high', you effectively restrict the permission to those namespaces. This approach leverages the fact that a ClusterRole can be used with RoleBindings to scope permissions to individual namespaces.

Exam trap

The trap here is that candidates often confuse ClusterRoleBindings with RoleBindings, assuming a ClusterRole must always be bound with a ClusterRoleBinding, or they mistakenly think that a ClusterRole can include a namespace selector to limit its scope, which is not supported in Kubernetes RBAC.

How to eliminate wrong answers

Option B is wrong because aggregating Roles into a ClusterRole does not solve the namespace-scoping requirement; the aggregated ClusterRole would still apply cluster-wide if bound with a ClusterRoleBinding, and if bound with RoleBindings, you would still need to create RoleBindings per namespace, making the aggregation unnecessary. Option C is wrong because a ClusterRoleBinding grants permissions across all namespaces, and Kubernetes RBAC does not support adding a namespace condition inside a ClusterRole; namespace restrictions are enforced only via RoleBindings or by using a Role. Option D is wrong because ClusterRoles do not support a 'namespaceSelector' field; that field is only available in NetworkPolicy and certain admission webhooks, not in RBAC resources.

Full explanation →
605
MCQmedium

A security audit reveals that a container image running in production contains a critical vulnerability (CVE-2024-1234). The image was built from a base image that had the vulnerability. What is the MOST effective long-term solution to prevent such issues?

A.Use a runtime security tool like Falco to detect exploitation attempts.
B.Patch the vulnerability by installing a security update inside the running container.
C.Add an admission controller that rejects images with vulnerabilities.
D.Rebuild the image using a patched base image and integrate vulnerability scanning into the CI pipeline.
E.Switch to a different container runtime that is immune to the vulnerability.
AnswerD

Fixing the base image and scanning prevent vulnerable images from being built.

Why this answer

Option D is the most effective long-term solution because it addresses the root cause by rebuilding the image from a patched base image, eliminating the vulnerability at the source. Integrating vulnerability scanning into the CI pipeline ensures that future images are automatically checked for known CVEs before deployment, preventing vulnerable images from reaching production. This aligns with the principle of shifting security left in the software supply chain.

Exam trap

CNCF often tests the distinction between reactive runtime detection (Falco) and proactive supply chain fixes (rebuilding with patched base images), leading candidates to choose a runtime tool instead of addressing the root cause in the CI/CD pipeline.

How to eliminate wrong answers

Option A is wrong because Falco is a runtime security tool that detects exploitation attempts but does not prevent the vulnerable image from being deployed or fix the underlying vulnerability; it only provides detection and alerting. Option B is wrong because patching a running container is a temporary, non-repeatable fix that violates immutable infrastructure principles; the patch will be lost on container restart and does not address the base image issue. Option C is wrong because an admission controller that rejects images with vulnerabilities is a preventive control, but it does not fix the existing vulnerable images already in production and relies on a policy that may block legitimate updates; it also does not address the root cause in the CI pipeline.

Option E is wrong because switching to a different container runtime does not fix the vulnerability in the image; the runtime is not responsible for image content, and the CVE would still be present regardless of the runtime used.

Full explanation →
606
MCQeasy

A cluster is using kubeadm and the control plane components are running as static pods. Where are the static pod manifests for the API server located by default?

A./var/lib/kubelet/
B./etc/kubernetes/manifests/
C./etc/kubernetes/admin.conf
D./etc/kubernetes/
AnswerB

Default static pod manifest directory.

Why this answer

In a kubeadm-deployed cluster, the control plane components (API server, controller manager, scheduler) run as static pods. The kubelet watches a specific directory for pod manifests to create these static pods. By default, kubeadm places the manifests for the API server (and other control plane components) in /etc/kubernetes/manifests/.

This directory is specified via the --pod-manifest-path or staticPodPath in the kubelet configuration.

Exam trap

The trap here is that candidates confuse the static pod manifest directory (/etc/kubernetes/manifests/) with the kubelet's working directory (/var/lib/kubelet/) or the general cluster configuration directory (/etc/kubernetes/), leading them to pick a plausible but incorrect path.

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/ is the default directory for kubelet's internal data (e.g., pod volumes, plugins, and the device plugin directory), not for static pod manifests. Option C is wrong because /etc/kubernetes/admin.conf is the kubeconfig file used by kubectl and administrators to authenticate to the cluster, not a directory for manifests. Option D is wrong because /etc/kubernetes/ is the parent directory containing cluster configuration files (like admin.conf, kubelet.conf, and the manifests subdirectory), but the static pod manifests themselves reside specifically in the /etc/kubernetes/manifests/ subdirectory, not directly in /etc/kubernetes/.

Full explanation →
607
MCQmedium

You run 'crictl ps' and see a container with state CONTAINER_RUNNING. What does this indicate?

A.The container has exited
B.The container is paused
C.The container is starting up
D.The container is running normally
AnswerD

CONTAINER_RUNNING is the normal running state.

Why this answer

crictl ps shows containers managed by the runtime; CONTAINER_RUNNING means the container is actively running.

Full explanation →
608
MCQeasy

Which annotation is used to apply an AppArmor profile named 'custom-profile' to a container named 'app' in a pod?

A.apparmor.security.beta.kubernetes.io/container.app: localhost/custom-profile
B.security.beta.kubernetes.io/apparmor: localhost/custom-profile
C.pod.apparmor.security.beta.kubernetes.io/app: localhost/custom-profile
D.container.apparmor.security.beta.kubernetes.io/app: localhost/custom-profile
AnswerD

This is the correct annotation format to apply an AppArmor profile to a specific container.

Why this answer

Option D is correct because the annotation for applying an AppArmor profile to a specific container in a pod follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>`. This annotation targets the container named 'app' with the profile 'custom-profile', which is loaded locally on the node.

Exam trap

The trap here is that candidates confuse the annotation prefix order (e.g., `apparmor.security.beta.kubernetes.io` vs. `container.apparmor.security.beta.kubernetes.io`) or mistakenly use a pod-level annotation instead of the correct container-level annotation.

How to eliminate wrong answers

Option A is wrong because the prefix `apparmor.security.beta.kubernetes.io/container.app` is incorrect; the correct prefix is `container.apparmor.security.beta.kubernetes.io`. Option B is wrong because `security.beta.kubernetes.io/apparmor` is a generic annotation that does not specify a container name, and it is not the correct format for per-container AppArmor profiles. Option C is wrong because `pod.apparmor.security.beta.kubernetes.io/app` uses a `pod.` prefix, which is not a valid annotation; AppArmor annotations are per-container, not per-pod.

Full explanation →
609
Multi-Selectmedium

Which TWO of the following are best practices for Dockerfile security according to CKS guidelines?

Select 2 answers
A.RUN useradd -m myuser && USER root
B.COPY --from=builder /app /app
C.RUN adduser -D myuser && USER myuser
D.FROM scratch
E.FROM alpine:latest
AnswersC, D

This creates a non-root user and switches to it, following security best practice.

Why this answer

Correct answers: B and D. Using a non-root user reduces container privilege. Using a minimal base image reduces attack surface.

Option A (root user) is insecure. Option C (latest tag) is not reproducible. Option E (multi-stage build) is a best practice for image size but not strictly a security practice; it's more about efficiency.

However, multi-stage builds can reduce attack surface by not including build tools. But the most direct security practices are B and D.

Full explanation →
610
MCQmedium

An administrator wants to disable anonymous authentication to the Kubernetes API server. Which flag should be added to the kube-apiserver configuration?

A.--disable-anonymous
B.--authorization-mode=RBAC
C.--anonymous-auth=false
D.--enable-admission-plugins=DenyAnonymous
AnswerC

This flag disables anonymous authentication.

Why this answer

Option C is correct because the `--anonymous-auth=false` flag explicitly disables anonymous authentication to the Kubernetes API server. When set to false, requests without valid authentication credentials are rejected with a 401 Unauthorized error, preventing unauthenticated access. This is the standard Kubernetes mechanism to disable anonymous authentication as documented in the kube-apiserver reference.

Exam trap

The trap here is that candidates confuse authentication flags with authorization modes or admission plugins, and may invent non-existent flags like `--disable-anonymous` or assume `DenyAnonymous` is a valid admission plugin name.

How to eliminate wrong answers

Option A is wrong because `--disable-anonymous` is not a valid kube-apiserver flag; Kubernetes uses `--anonymous-auth` (boolean) to control anonymous access. Option B is wrong because `--authorization-mode=RBAC` controls authorization (what authenticated users can do), not authentication (who can access); anonymous users can still be authorized via RBAC if anonymous authentication is enabled. Option D is wrong because `DenyAnonymous` is not a valid admission plugin name; the correct admission plugin for denying anonymous requests is `DenyServiceExternalIPs` or similar, and anonymous authentication is controlled at the authentication layer, not via admission plugins.

Full explanation →
611
MCQmedium

An administrator wants to enable audit logging for the Kubernetes API server. Which of the following is required?

A.Enable the AuditLogging feature gate
B.Set --audit-log-path and --audit-policy-file flags on the kube-apiserver
C.Create a ClusterRoleBinding with audit permissions
D.Set --audit-log-path flag on the kubelet
AnswerB

Enabling audit logging requires specifying the log path via --audit-log-path and a policy file via --audit-policy-file.

Why this answer

Audit logging in Kubernetes is configured directly on the kube-apiserver component. The `--audit-log-path` flag specifies the file path where audit logs are written, and the `--audit-policy-file` flag points to a YAML file that defines which events (e.g., requests, responses, metadata) should be logged and at what level (e.g., Metadata, Request, RequestResponse). These flags are required to enable and control audit logging; no feature gate is needed because audit logging is built-in since Kubernetes 1.8.

Exam trap

The trap here is that candidates may think audit logging requires a feature gate (Option A) or confuse the kube-apiserver's audit flags with kubelet flags (Option D), or mistakenly believe RBAC permissions are needed to enable audit logging (Option C).

How to eliminate wrong answers

Option A is wrong because the AuditLogging feature gate was removed as a beta feature in Kubernetes 1.8 and is now always enabled; no feature gate is required to activate audit logging. Option C is wrong because a ClusterRoleBinding grants RBAC permissions to users or service accounts, but it does not enable or configure audit logging on the API server; audit logging is a server-side configuration, not a permission. Option D is wrong because the kubelet does not serve the Kubernetes API and does not handle audit logging; the `--audit-log-path` flag is only valid for the kube-apiserver, not the kubelet.

Full explanation →
612
Multi-Selecthard

Which THREE of the following are required components to enable audit logging in Kubernetes? (Select three.)

Select 3 answers
A.The --audit-policy-file flag on kube-apiserver
B.The --audit-log-path flag on kube-apiserver
C.An audit policy YAML file
D.The --audit-dynamic-configuration flag
E.An audit webhook backend
AnswersA, B, C

Why this answer

Audit logging requires an audit policy file, the --audit-policy-file flag, and a log backend like --audit-log-path.

Full explanation →
613
MCQeasy

You are tasked with creating a ConstraintTemplate in OPA/Gatekeeper that denies pods running with the 'latest' image tag. Which Rego rule should the ConstraintTemplate include?

A.admit[{"msg": msg}] { ... }
B.violation[{"msg": msg}] { ... }
C.reject[{"msg": msg}] { ... }
D.deny[{"msg": msg}] { ... }
AnswerB

In OPA/Gatekeeper ConstraintTemplates, the violation rule is used to deny admission. If the rule evaluates to true, the request is denied.

Why this answer

Gatekeeper ConstraintTemplates use a Rego rule named 'violation' to define admission violations. When the rule evaluates to true, the request is denied.

Full explanation →
614
Multi-Selecthard

Which THREE of the following are valid capabilities that should be dropped for a container running a typical non-privileged application to adhere to the principle of least privilege?

Select 3 answers
A.CHOWN
B.SYS_ADMIN
C.NET_RAW
D.SETUID
E.NET_ADMIN
AnswersB, C, E

Highly privileged; almost never needed in containers and should be dropped.

Why this answer

The principle of least privilege suggests dropping all capabilities except those absolutely needed. For most applications, capabilities like NET_RAW, SYS_ADMIN, and SETUID are unnecessary and should be dropped. NET_ADMIN is also dangerous.

Dropping these reduces attack surface.

Full explanation →
615
MCQmedium

Which of the following is the correct way to apply an AppArmor profile named 'my-profile' to a pod using the annotation?

A.annotations: { apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }
B.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'my-profile' }
C.annotations: { container.apparmor.security.beta.kubernetes.io/app: 'localhost/my-profile' }
D.annotations: { container.seccomp.security.beta.kubernetes.io/app: 'localhost/my-profile' }
AnswerC

Correct format.

Why this answer

Option C is correct because the AppArmor profile annotation must follow the format `container.apparmor.security.beta.kubernetes.io/<container_name>`, and the profile value must be prefixed with `localhost/` to indicate a locally loaded profile. This annotation applies the 'my-profile' AppArmor profile to the container named 'app' in the pod.

Exam trap

CNCF often tests the distinction between the `container.` prefix for per-container annotations versus the deprecated pod-level annotation, and the mandatory `localhost/` prefix for locally loaded profiles, causing candidates to omit one or both.

How to eliminate wrong answers

Option A is wrong because it uses the deprecated `apparmor.security.beta.kubernetes.io/app` annotation format (without the `container.` prefix), which is not the correct way to apply a profile to a specific container. Option B is wrong because it omits the required `localhost/` prefix in the profile value, which would cause the profile to be treated as an unqualified name and likely fail to load. Option D is wrong because it uses the `seccomp` annotation (`container.seccomp.security.beta.kubernetes.io/`) instead of the AppArmor annotation, which is a completely different security mechanism.

Full explanation →
616
MCQhard

A microservice container needs to perform DNS lookups using TCP rather than UDP. Which Kubernetes security context setting should be configured to allow this?

A.Add `DAC_OVERRIDE` capability
B.Add `NET_RAW` capability
C.Add `NET_ADMIN` capability
D.Add `NET_BIND_SERVICE` capability
AnswerB

TCP DNS may require raw socket access on some configurations.

Why this answer

Option B is correct because DNS queries typically use UDP, but when a response is truncated or when zone transfers are involved, TCP is required. The `NET_RAW` capability allows a container to create raw sockets, which is necessary for crafting and sending TCP packets for DNS lookups at the transport layer. Without this capability, the container's network stack may be restricted to only UDP-based DNS resolution.

Exam trap

The trap here is that candidates often confuse `NET_RAW` (needed for raw sockets and TCP-level operations) with `NET_ADMIN` (which is for network administration tasks), or incorrectly assume that DNS always uses UDP and that no capability is needed for TCP fallback.

How to eliminate wrong answers

Option A is wrong because `DAC_OVERRIDE` capability bypasses file permission checks and has no relevance to network protocol selection for DNS lookups. Option C is wrong because `NET_ADMIN` capability grants broad network administration privileges (e.g., interface configuration, firewall rules) which is excessive and not specifically required for enabling TCP-based DNS queries. Option D is wrong because `NET_BIND_SERVICE` capability allows binding to privileged ports (below 1024) and does not control the ability to use TCP for DNS lookups.

Full explanation →
617
MCQmedium

You have a pod that is in CrashLoopBackOff. You want to inspect the logs from the previous instance of the container. Which flag should you use with kubectl logs?

A.--previous
B.--tail
C.--all-containers
D.--since
AnswerA

--previous shows logs from the previous container instance.

Why this answer

The --previous flag retrieves logs from the previous instance of the container before it crashed.

Full explanation →
618
Multi-Selectmedium

Which THREE stages can be configured for Kubernetes audit logging?

Select 3 answers
A.RequestProcessed
B.ResponseComplete
C.Panic
D.ResponseStarted
E.RequestReceived
AnswersB, D, E

Standard stage.

Why this answer

The audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic.

Full explanation →
619
MCQmedium

An administrator wants to secure etcd communication. Which of the following is required?

A.Set --etcd-servers to use HTTPS
B.Use SSH tunneling between etcd members
C.Enable TLS with client certificate authentication
D.Enable etcd RBAC
AnswerC

etcd can be configured to require TLS client certificates for all connections.

Why this answer

Option C is correct because etcd, as a distributed key-value store, requires TLS encryption with mutual authentication (client certificates) to secure communication between the API server and etcd, as well as between etcd peers. The `--etcd-servers` flag in kube-apiserver must point to HTTPS endpoints, and `--etcd-certfile` and `--etcd-keyfile` enable client certificate authentication, ensuring that only authenticated clients can access etcd data.

Exam trap

The trap here is that candidates often assume HTTPS alone (Option A) is sufficient for securing etcd, overlooking the requirement for mutual TLS authentication with client certificates to prevent unauthorized clients from connecting to etcd.

How to eliminate wrong answers

Option A is wrong because simply setting `--etcd-servers` to use HTTPS without enabling TLS with client certificate authentication does not secure etcd communication; HTTPS alone only encrypts the channel but does not authenticate the client, leaving etcd vulnerable to unauthorized access. Option B is wrong because SSH tunneling between etcd members is not a standard or recommended practice for securing etcd in Kubernetes; etcd natively supports TLS encryption and mutual authentication, and SSH tunnels add unnecessary complexity and are not part of the Kubernetes security model. Option D is wrong because etcd RBAC controls authorization for etcd operations (e.g., read/write access to keys) but does not encrypt or authenticate the communication channel; TLS with client certificates is required to secure the transport layer.

Full explanation →
620
MCQmedium

A pod's container tries to read environment variables that contain database credentials. The cluster has an external secrets manager (HashiCorp Vault) integrated via a sidecar. Which approach is MOST secure for exposing secrets to the container?

A.Mount the secrets as a volume using a CSI driver
B.Set the secrets as environment variables using the 'env' field
C.Embed the secrets directly in the container image
D.Use a ConfigMap to store the secrets
AnswerA

Correct. Volume mounts are more secure and avoid exposure.

Why this answer

Mounting secrets as volumes is more secure than environment variables because they are not exposed in process listings or logs.

Full explanation →
621
Drag & Dropmedium

Arrange the steps to configure and use Trivy to scan container images for vulnerabilities in a CI/CD pipeline.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Trivy scanning involves installation, building/pushing image, scanning, parsing results, and enforcing policies.

Full explanation →
622
MCQmedium

You are configuring Kubernetes audit logging. You want to log all requests to the `secrets` resource in the `kube-system` namespace at the `RequestResponse` level, while logging all other requests at the `Metadata` level. Which audit policy configuration achieves this?

A.rules: [- level: RequestResponse, resources: [group: '', resources: [*]], - level: Metadata]
B.rules: [- level: RequestResponse, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: Metadata]
C.rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], - level: RequestResponse]
D.rules: [- level: Metadata, resources: [group: '', resources: [secrets]], namespaces: [kube-system], omitStages: [RequestReceived], - level: RequestResponse]
AnswerB

Correct: first rule matches secrets in kube-system with RequestResponse, second rule catches all other requests with Metadata.

Why this answer

Option A is correct because it defines a rule for secrets in kube-system with level RequestResponse, then a default rule for all other resources with level Metadata. Option B incorrectly uses `omitStages` instead of `level`. Option C does not target the specific resource.

Option D reverses the levels.

Full explanation →
623
MCQmedium

An administrator creates a custom seccomp profile and places it at /var/lib/kubelet/seccomp/myprofile.json. Which securityContext field is used to apply this profile to a container?

A.seccompProfile: type: Localhost localhostProfile: "/var/lib/kubelet/seccomp/myprofile.json"
B.seccompProfile: type: Localhost localhostProfile: "myprofile.json"
C.seccompProfile: type: RuntimeDefault localhostProfile: "myprofile.json"
D.seccompProfile: type: Unconfined localhostProfile: "myprofile.json"
AnswerB

Correct. This references the custom profile.

Why this answer

The seccompProfile field under securityContext with type: Localhost and localhostProfile: "myprofile.json" applies the custom profile.

Full explanation →
624
MCQhard

You are responsible for a production Kubernetes cluster running critical workloads. The cluster uses containerd as the container runtime. The security team has deployed Falco with default rules and it is running as a DaemonSet. Recently, the team noticed that several pods have been unexpectedly terminated by the OOMKiller. You suspect a container is performing a fork bomb attack, exhausting memory. You need to detect and prevent such attacks in real-time. Falco is already installed. Which single action should you take to best address this threat?

A.Enable the Falco rule that detects rapid process creation (fork bomb) and configure an alert.
B.Adjust the OOM score of critical pods to prevent them from being killed.
C.Apply a seccomp profile that blocks the fork and clone syscalls.
D.Set resource quotas on all namespaces to limit memory usage.
AnswerA

Falco has a built-in rule for fork bombs.

Why this answer

Falco's default rules include a rule for 'Fork Bomb' that detects rapid process creation by monitoring the `clone` and `fork` syscalls. Enabling this rule and configuring an alert allows real-time detection of fork bomb attacks, which is the most direct and effective action to address the threat. This leverages Falco's existing capability to identify anomalous syscall patterns without requiring additional tooling or configuration changes.

Exam trap

The trap here is that candidates may choose option C (blocking fork/clone syscalls) thinking it prevents the attack, but they overlook that this would break essential container functionality, whereas Falco's existing rule provides detection without breaking applications.

How to eliminate wrong answers

Option B is wrong because adjusting the OOM score of critical pods only influences which pod gets killed first when memory pressure occurs, but it does not detect or prevent the fork bomb attack itself; the attack would still exhaust memory and potentially kill other pods. Option C is wrong because applying a seccomp profile that blocks `fork` and `clone` syscalls would break legitimate container operations that rely on process creation (e.g., starting new processes, running scripts), making it an impractical and overly restrictive solution. Option D is wrong because setting resource quotas on namespaces limits total memory usage but does not detect or prevent a fork bomb in real-time; the attack could still cause OOM kills within the quota or affect other pods in the same namespace before the quota is enforced.

Full explanation →
625
MCQhard

You have built a custom seccomp profile at /var/lib/kubelet/seccomp/audit.json. Which YAML snippet correctly applies this profile to a container?

A.securityContext: seccompProfile: type: RuntimeDefault
B.securityContext: seccompProfile: type: Localhost localhostProfile: "profiles/audit.json"
C.securityContext: seccomp: type: Localhost profile: "audit.json"
D.securityContext: seccompProfile: type: Localhost localhostProfile: "audit.json"
AnswerB

The profile is stored in /var/lib/kubelet/seccomp/profiles/audit.json. The relative path from the seccomp directory is 'profiles/audit.json'.

Full explanation →
626
MCQmedium

You need to encrypt secrets at rest in a Kubernetes cluster. What must be configured?

A.Create an EncryptionConfiguration object in the cluster and pass it to kube-apiserver via --encryption-provider-config
B.Set the environment variable ENCRYPT_SECRETS=true on the kube-controller-manager
C.Use a MutatingWebhookConfiguration to encrypt secrets before storage
D.Enable the 'SecretEncryption' feature gate on all control plane components
AnswerA

Kubernetes supports encryption at rest via EncryptionConfiguration resource, which is provided to the API server using the --encryption-provider-config flag.

Why this answer

EncryptionConfiguration is a Kubernetes resource that defines how to encrypt resources (like Secrets) at rest. The API server reads this configuration via the --encryption-provider-config flag.

Full explanation →
627
MCQmedium

You want to drop all Linux capabilities from a container. Which securityContext field should you set?

A.capabilities.allow
B.capabilities.add: ["ALL"]
C.capabilities.drop: ["ALL"]
D.dropCapabilities: true
AnswerC

Drops all capabilities, minimizing privilege.

Why this answer

Option C is correct. The 'capabilities.drop' field with a list of all capabilities (or using ['ALL']) drops all capabilities. Option A adds capabilities.

Option B is a field for defining allowed capabilities. Option D is not a valid field.

Full explanation →
628
MCQeasy

Which of the following is the correct flag to enable audit logging on the kube-apiserver?

A.--audit-file
B.--audit-log-path
C.--audit-policy-file
D.--audit-log-file
AnswerB

This flag specifies the path for audit log output.

Why this answer

Option B is correct because `--audit-log-path` is the flag used to specify the file path where the kube-apiserver writes audit log entries. This flag is defined in the Kubernetes API server component and is required to enable audit logging; without it, no audit logs are written.

Exam trap

The trap here is that candidates confuse `--audit-policy-file` (which defines what to log) with the flag that actually enables logging, or misremember the exact flag name as `--audit-log-file` instead of the correct `--audit-log-path`.

How to eliminate wrong answers

Option A is wrong because `--audit-file` is not a valid kube-apiserver flag; the correct flag for specifying the audit log file path is `--audit-log-path`. Option C is wrong because `--audit-policy-file` specifies the path to the audit policy YAML file that defines which events to log, but it does not enable audit logging by itself—it must be used together with `--audit-log-path`. Option D is wrong because `--audit-log-file` is not a recognized flag; the correct flag name uses `--audit-log-path` as per the Kubernetes API server command-line options.

Full explanation →
629
MCQmedium

You run 'crictl ps' and see no output, but the node has running pods. What is the most likely cause?

A.The --runtime-endpoint flag is not set or points to the wrong socket
B.The container runtime is not Docker
C.The pod uses a different container runtime than CRI-O
D.The containers are in a different namespace
AnswerA

Why this answer

crictl uses a socket to communicate with the container runtime; if the socket is wrong, it won't list containers.

Full explanation →
630
MCQhard

A security policy requires that all container images must reference a specific SHA256 digest instead of a tag. You need to enforce this using Kyverno. Which Kyverno rule type and pattern would you use?

A.A generate rule that creates a ConfigMap with allowed digests
B.A mutate rule that replaces the image tag with a digest
C.A validate rule with a pattern that the image field matches '@sha256:'
D.A validate rule checking the annotation 'image.openshift.io/triggers'
AnswerC

A validate rule can enforce that the image string contains a digest. Example: pattern: spec.containers[*].image: "*@sha256:*"

Why this answer

Option C is correct. A validate rule with a pattern that matches the image field to a regular expression requiring '@sha256:' ensures digest reference. Option A mutates the image but does not validate.

Option B validates annotation, not image. Option D is for generating resources, not validation.

Full explanation →
631
Multi-Selecthard

Which TWO of the following are effective measures to harden the Kubernetes API server against unauthorized access?

Select 2 answers
A.Enable the NodeRestriction admission controller
B.Set --anonymous-auth=true to allow all users
C.Enable audit logging to detect unauthorized attempts
D.Disable all authentication mechanisms and rely on network policies
E.Configure the API server to use TLS certificates for client authentication
AnswersA, E

Limits what nodes can modify, reducing attack surface.

Why this answer

The NodeRestriction admission controller limits the Node and Pod objects a kubelet can modify, preventing compromised nodes from accessing or modifying resources beyond their own. This is a key hardening measure because it enforces the principle of least privilege directly within the API server's admission chain, reducing the blast radius of a node compromise.

Exam trap

CNCF often tests the distinction between preventive controls (like admission controllers and authentication) and detective controls (like audit logging), so candidates mistakenly select audit logging as a hardening measure when it only detects, not prevents, unauthorized access.

Full explanation →
632
MCQeasy

Which crictl command lists all running containers on a node?

A.crictl pods
B.crictl images
C.crictl ps
D.crictl stats
AnswerC

Correct: crictl ps lists containers.

Why this answer

crictl ps lists running containers, similar to docker ps.

Full explanation →
633
MCQmedium

An administrator runs 'trivy image --severity HIGH,CRITICAL myapp:v1.0' and sees no vulnerabilities. However, a security scan of the same image using a different tool reports several HIGH severity CVEs. What is the MOST likely reason for this discrepancy?

A.Trivy only scans the application layer and ignores the base image
B.The image was scanned with an outdated vulnerability database
C.Trivy cannot scan images stored in private registries
D.The other tool has false positives
AnswerB

Trivy's vulnerability database may be outdated or not include all databases, leading to missing CVEs.

Why this answer

Trivy uses different vulnerability databases and may not include all sources (e.g., Red Hat OVAL, OSV). The other tool might use a broader set of databases, explaining the additional found CVEs.

Full explanation →
634
Multi-Selectmedium

Which TWO admission plugins are recommended to be enabled for security hardening?

Select 2 answers
A.AlwaysPullImages
B.NodeRestriction
C.NamespaceLifecycle
D.PodSecurity
E.DefaultStorageClass
AnswersB, D

Limits node modifications.

Why this answer

NodeRestriction is correct because it limits the Node object modifications a kubelet can make, preventing compromised nodes from modifying other nodes or escalating privileges. PodSecurity is correct because it enforces Pod Security Standards (baseline, restricted) via admission, replacing the deprecated PodSecurityPolicy with a built-in, stable mechanism for controlling pod security contexts.

Exam trap

CNCF often tests the distinction between plugins that are 'enabled by default' (like NamespaceLifecycle) versus those that are specifically 'recommended for security hardening' (like NodeRestriction and PodSecurity), causing candidates to pick default plugins that are not security-focused.

Full explanation →
635
MCQmedium

Which kubectl command can you use to view the logs of a specific container in a multi-container pod?

A.kubectl logs <pod> -c <container>
B.kubectl logs <pod> --container <container>
C.kubectl logs <pod> <container>
D.kubectl logs <pod> --all-containers
AnswerA, B

-c is the short form for --container; both are correct.

Why this answer

kubectl logs with the -c flag allows you to specify a container name within a pod. The other options are incorrect: --container is not a valid flag, and the others miss the required container specification.

Full explanation →
636
MCQhard

An administrator wants to restrict which nodes a pod can be scheduled on using the NodeRestriction admission plugin. Which flag must be set on the kube-apiserver to enable this plugin?

A.--admission-control=NodeRestriction
B.--enable-admission-plugins=PodNodeSelector
C.--authorization-mode=Node
D.--enable-admission-plugins=NodeRestriction
AnswerD

This flag enables the NodeRestriction admission plugin, which enforces node restrictions on pods.

Why this answer

The NodeRestriction admission plugin limits the labels and taints that a kubelet running on a node can modify on its own Node object. To enable it, the `--enable-admission-plugins=NodeRestriction` flag must be set on the kube-apiserver, as admission plugins are enabled via this flag. This plugin works in conjunction with the Node authorizer and the NodeRestriction admission controller to enforce node-level restrictions.

Exam trap

The trap here is that candidates confuse the deprecated `--admission-control` flag with the current `--enable-admission-plugins` flag, or they mix up the NodeRestriction plugin with the Node authorizer or the PodNodeSelector plugin.

How to eliminate wrong answers

Option A is wrong because `--admission-control` is a deprecated flag; the correct flag is `--enable-admission-plugins`. Option B is wrong because `PodNodeSelector` is a different admission plugin that enforces namespace-level node selector constraints, not the NodeRestriction plugin. Option C is wrong because `--authorization-mode=Node` enables the Node authorizer, which authorizes kubelet API requests, but does not enable the NodeRestriction admission plugin.

Full explanation →
637
MCQeasy

Which flag enables the PodSecurity admission plugin in kube-apiserver?

A.--enable-admission-plugins=PodSecurity
B.--admission-control=PodSecurity
C.--feature-gates=PodSecurity=true
D.--pod-security-policy=true
AnswerA

The PodSecurity plugin is enabled by adding it to the --enable-admission-plugins flag.

Why this answer

The PodSecurity admission plugin is enabled via the --enable-admission-plugins flag on the API server. It replaced the deprecated PodSecurityPolicy.

Full explanation →
638
MCQhard

An admin runs 'kubectl run test-pod --image=nginx:latest' and the Pod is created but immediately enters 'CrashLoopBackOff'. 'kubectl describe pod test-pod' shows 'Back-off restarting failed container'. Which admission controller might cause this if misconfigured?

A.ValidatingAdmissionWebhook
B.MutatingAdmissionWebhook
C.PodSecurity
D.PersistentVolumeClaimResize
AnswerB

A mutating webhook could modify the Pod spec (e.g., adding a sidecar or changing command) causing the container to fail.

Why this answer

ImagePolicyWebhook can reject images based on policy, but this causes a different error (e.g., 'ImagePullBackOff'). The failure to start repeatedly could be due to a MutatingAdmissionWebhook that modifies the Pod spec in a way that causes the container to fail (e.g., injecting a sidecar that crashes).

Full explanation →
639
MCQmedium

A Falco rule is triggered when a shell is spawned inside a container. Which syscall is typically used to detect shell execution?

A.clone
B.open
C.read
D.execve
AnswerD

execve is the syscall used to execute a new program, such as a shell.

Why this answer

Falco detects shell execution by monitoring the execve syscall. The rule usually checks for a process named 'bash', 'sh', etc., and the evt.type=execve condition.

Full explanation →
640
MCQmedium

An OPA Gatekeeper ConstraintTemplate uses a Rego rule that denies pods without a specific label. The Constraint is created but pods without the label are still being allowed. What is the MOST likely cause?

A.The Rego policy has a syntax error
B.Gatekeeper is not installed in the cluster
C.The Constraint object has not been created
D.The namespace is excluded via Gatekeeper configuration
AnswerC

Correct. The Constraint instantiates the template.

Why this answer

Gatekeeper requires both a ConstraintTemplate and a Constraint instance. Without the Constraint, the template does not enforce.

Full explanation →
641
MCQmedium

A pod runs with a service account that has a ClusterRoleBinding granting cluster-admin. What is the best practice to reduce the risk of privilege escalation?

A.Use a PodSecurityPolicy to restrict the service account
B.Delete the service account and create a new one without any roles
C.Create a more restrictive Role/ClusterRole with only required permissions and bind it to the service account, removing the cluster-admin binding
D.Add a NetworkPolicy to block outbound traffic from the pod
AnswerC

This follows the principle of least privilege.

Why this answer

Option C is correct because the principle of least privilege dictates that a service account should only have the permissions necessary for its function. By creating a more restrictive Role/ClusterRole with only required permissions and binding it to the service account, you remove the excessive cluster-admin privileges, directly reducing the risk of privilege escalation. This aligns with Kubernetes RBAC best practices for hardening cluster setup.

Exam trap

CNCF often tests the distinction between RBAC (who can do what) and other security controls like PodSecurityPolicy or NetworkPolicy, expecting candidates to recognize that only RBAC changes can directly reduce service account permissions.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (PSP) is a deprecated admission controller that controls pod security contexts (e.g., privileged containers, host namespaces), not RBAC permissions; it cannot restrict what a service account can do via ClusterRoleBindings. Option B is wrong because deleting the service account and creating a new one without any roles would break the pod's functionality entirely, as it would have no permissions to perform any API operations, which is not a practical security fix. Option D is wrong because NetworkPolicy controls network traffic at the pod level (e.g., ingress/egress rules), not RBAC permissions; it cannot prevent a service account from abusing its cluster-admin privileges to escalate privileges via the Kubernetes API.

Full explanation →
642
MCQmedium

You run 'kubectl auth can-i --list --as=admin' and see that the admin user has full cluster-admin access. Which command would create a ClusterRoleBinding for a user named 'viewer' with read-only access to all resources?

A.kubectl create rolebinding viewer-binding --clusterrole=view --user=viewer
B.kubectl create clusterrole viewer --verb=get,list,watch --resource=*
C.kubectl create clusterrolebinding viewer-binding --role=view --user=viewer
D.kubectl create clusterrolebinding viewer-binding --clusterrole=view --user=viewer
AnswerD

This binds the 'view' ClusterRole to user 'viewer'.

Why this answer

Option D is correct because it uses `kubectl create clusterrolebinding` to bind the built-in `view` ClusterRole (which grants read-only access: get, list, watch) to the user `viewer` at the cluster scope. A ClusterRoleBinding is required to grant permissions across all namespaces, and the `--clusterrole` flag correctly references the ClusterRole, not a Role.

Exam trap

The trap here is that candidates confuse `rolebinding` with `clusterrolebinding` and `--role` with `--clusterrole`, leading them to pick options that either limit permissions to a single namespace or use incorrect syntax for binding a ClusterRole.

How to eliminate wrong answers

Option A is wrong because `kubectl create rolebinding` creates a namespaced RoleBinding, which only grants permissions within a specific namespace (default if not specified), not across all resources cluster-wide. Option B is wrong because it creates a new ClusterRole with `*` as the resource, which is invalid syntax (resources must be specific, e.g., `'*'` is not a valid resource name) and it does not bind the role to the user. Option C is wrong because it uses `--role=view` instead of `--clusterrole=view`; `--role` expects a namespaced Role, not a ClusterRole, and a ClusterRoleBinding cannot reference a namespaced Role.

Full explanation →
643
MCQeasy

Which flag on the kubelet disables anonymous access?

A.--anonymous-auth=false
B.--disable-anonymous
C.--no-anonymous
D.--enable-anonymous-auth=false
AnswerA

This is the correct flag on kubelet.

Why this answer

The `--anonymous-auth` flag on the kubelet controls whether anonymous requests are allowed. Setting `--anonymous-auth=false` explicitly disables anonymous access, requiring all requests to present valid authentication credentials. This is a critical hardening measure to prevent unauthenticated users from interacting with the kubelet API.

Exam trap

CNCF often tests the exact flag name and syntax, so candidates may confuse `--anonymous-auth` with `--enable-anonymous-auth` or invent non-existent flags like `--disable-anonymous` or `--no-anonymous`.

How to eliminate wrong answers

Option B is wrong because `--disable-anonymous` is not a valid kubelet flag; the kubelet uses `--anonymous-auth` to control anonymous access. Option C is wrong because `--no-anonymous` is not a recognized flag; the kubelet does not support a `--no-` prefix for this setting. Option D is wrong because `--enable-anonymous-auth=false` is not a valid flag; the correct flag is `--anonymous-auth`, and setting it to `false` disables anonymous access, not `--enable-anonymous-auth`.

Full explanation →
644
MCQhard

A developer creates a Dockerfile with 'FROM ubuntu:latest'. The security team recommends using a minimal base image. Which change minimizes the attack surface?

A.FROM gcr.io/distroless/base:latest
B.FROM alpine:latest
C.FROM scratch
D.FROM ubuntu:20.04
AnswerA

Distroless images contain only the necessary runtime dependencies, greatly reducing the attack surface.

Why this answer

Using a distroless image reduces the number of packages and thus the attack surface. Option B is correct.

Full explanation →
645
MCQmedium

An administrator wants to restrict a service account to only be able to create pods in the 'development' namespace. Which RBAC configuration should be used?

A.Create a Role in the default namespace and a RoleBinding that binds the service account to that Role.
B.Create a Role in the 'development' namespace and a RoleBinding that binds the service account to that Role.
C.Create a ClusterRole and a ClusterRoleBinding that binds the service account to that ClusterRole.
D.Create a ClusterRole and a RoleBinding in the 'development' namespace.
AnswerB

Role and RoleBinding are namespaced and provide the correct scoping.

Why this answer

Option B is correct because a Role is namespace-scoped and can only grant permissions within the namespace where it is created. By creating a Role in the 'development' namespace and binding the service account to it via a RoleBinding, the service account is restricted to creating pods only in that namespace, as required.

Exam trap

CNCF often tests the distinction between Role and ClusterRole scoping, and the trap here is that candidates may incorrectly choose a ClusterRole with a RoleBinding (Option D) thinking it restricts to a namespace, but the ClusterRole itself may grant broader permissions or include cluster-scoped resources, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because creating a Role in the default namespace and binding it to the service account would grant permissions only in the default namespace, not in the 'development' namespace. Option C is wrong because a ClusterRole combined with a ClusterRoleBinding grants permissions cluster-wide, across all namespaces, which is too permissive and does not restrict the service account to the 'development' namespace. Option D is wrong because while a RoleBinding in the 'development' namespace scopes the binding to that namespace, a ClusterRole is not namespace-scoped; using a ClusterRole in a RoleBinding still grants permissions defined in the ClusterRole, which could include cluster-scoped resources or be overly broad, and the question specifically requires restricting to pod creation only, which a Role can handle more precisely.

Full explanation →
646
MCQeasy

You want to isolate a compromised pod by blocking all network traffic to and from it. Which NetworkPolicy would you apply?

A.A policy with podSelector matching the pod, and only ingress rules denying from all
B.A policy with podSelector matching the pod, and policyTypes: [Ingress, Egress] with no rules
C.A policy with podSelector matching the pod, and egress rules allowing to 0.0.0.0/0
D.A policy with podSelector: {} and no rules
AnswerB

Why this answer

A NetworkPolicy that selects the pod with no ingress or egress rules will default to denying all traffic. Option B is correct. Option A denies ingress only.

Option C allows all. Option D allows egress to all.

Full explanation →
647
MCQmedium

A developer created a ClusterRoleBinding that grants cluster-admin to a service account. What is the security concern?

A.Service accounts must use RoleBindings only
B.ClusterRoleBindings are deprecated
C.Service accounts cannot use ClusterRoleBindings
D.It gives the service account full cluster-wide permissions, which is excessive
AnswerD

Cluster-admin grants unrestricted access to all resources.

Why this answer

Option D is correct because granting a service account cluster-admin via a ClusterRoleBinding provides unrestricted, cluster-wide permissions, violating the principle of least privilege. This is a significant security risk as it allows the service account to perform any action on any resource in any namespace, including modifying RBAC rules, secrets, or node configurations. In Kubernetes, service accounts should be bound only to the minimal roles required for their function, typically using RoleBindings scoped to a specific namespace.

Exam trap

CNCF often tests the misconception that service accounts are restricted to namespace-scoped bindings, leading candidates to incorrectly choose Option A or C, when in fact Kubernetes allows any subject to be bound to any ClusterRole.

How to eliminate wrong answers

Option A is wrong because service accounts can use both RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped) depending on the required scope; there is no Kubernetes restriction limiting them to RoleBindings only. Option B is wrong because ClusterRoleBindings are not deprecated; they remain a core, actively supported RBAC resource for granting cluster-wide permissions. Option C is wrong because service accounts can absolutely use ClusterRoleBindings; the Kubernetes API allows binding any subject (user, group, or service account) to a ClusterRole via a ClusterRoleBinding.

Full explanation →
648
MCQmedium

A cluster administrator wants to ensure that pods cannot modify node objects. Which admission plugin should be enabled?

A.PodSecurityPolicy
B.NodeAffinity
C.PodNodeSelector
D.NodeRestriction
AnswerD

This plugin restricts node modifications.

Why this answer

The NodeRestriction admission plugin limits the kubelet's ability to modify node and pod objects to only those nodes it is authorized to manage. This prevents a compromised or misconfigured kubelet from modifying arbitrary node objects, enforcing the principle of least privilege. Option D is correct because it directly addresses the requirement to restrict node object modifications.

Exam trap

The trap here is that candidates often confuse admission plugins that affect pod scheduling (like NodeAffinity or PodNodeSelector) with those that enforce node-level security restrictions, leading them to overlook NodeRestriction as the correct answer.

How to eliminate wrong answers

Option A is wrong because PodSecurityPolicy (deprecated in Kubernetes 1.21 and removed in 1.25) controls security-sensitive aspects of pod specs (e.g., privileged containers, host namespaces) but does not restrict modifications to node objects. Option B is wrong because NodeAffinity is a scheduling constraint that influences pod placement based on node labels, not an admission plugin that enforces node object modification restrictions. Option C is wrong because PodNodeSelector is an admission plugin that enforces namespace-level node selector constraints on pods, but it does not prevent pods or kubelets from modifying node objects.

Full explanation →
649
MCQmedium

A pod runs with an immutable root filesystem (readOnlyRootFilesystem: true). The application attempts to write to /tmp. What is the expected behavior?

A.The write fails with a permission error unless a writable volume is mounted at /tmp
B.The application can write to any directory because /tmp is always writable
C.The container crashes immediately
D.The write succeeds and is silently dropped
AnswerA

Why this answer

When readOnlyRootFilesystem is true, the container's filesystem is read-only. However, if an emptyDir volume is mounted at /tmp, the application can write to that location. Option C is correct.

Option A is wrong because write operations are not silently dropped; they fail with an error. Option B is wrong because the container may still run if it doesn't need to write to the root filesystem. Option D is false because the application can write to mounted volumes.

Full explanation →
650
MCQmedium

A pod manifests with securityContext: { runAsNonRoot: true, runAsUser: 1001 }. However, the container image expects to run as root (UID 0). What will happen when the pod is created?

A.The container runs as root because runAsUser overrides runAsNonRoot
B.The container fails to start because it cannot run as root
C.The container runs as user 1001
D.The pod runs, but the securityContext is ignored
AnswerB

runAsNonRoot: true prevents running as root; if the image requires root, the container will fail.

Why this answer

runAsNonRoot: true prevents the container from running as UID 0. If the image user is root, the container will not start. The pod might be rejected by admission control or fail to run.

It will not run as root or switch to user 1001 automatically if the image entrypoint expects root.

Full explanation →
651
MCQhard

An attacker exploited a container escape vulnerability. The team wants to mitigate such attacks by restricting containers from accessing the host's kernel capabilities. Which set of capabilities should be dropped from all containers?

A.SYS_ADMIN, SYS_MODULE, SYS_PTRACE
B.CHOWN, DAC_OVERRIDE, FOWNER
C.KILL, SETPCAP, SYS_CHROOT
D.NET_RAW, NET_ADMIN, NET_BIND_SERVICE
AnswerA

These capabilities allow kernel module loading, system administration, and process tracing, which can be exploited for escape.

Why this answer

Option A is correct because SYS_ADMIN, SYS_MODULE, and SYS_PTRACE are the most dangerous capabilities that enable container escape. SYS_ADMIN grants broad administrative privileges (e.g., mounting filesystems, accessing /proc/1/environ), SYS_MODULE allows loading kernel modules, and SYS_PTRACE permits tracing processes outside the container. Dropping these three capabilities is a key mitigation against kernel-level escapes.

Exam trap

CNCF often tests the misconception that all capabilities are equally dangerous, but the trap here is that candidates may choose networking or file capabilities (options B, C, D) because they sound security-relevant, while the actual escape vector relies on the three kernel-focused capabilities in option A.

How to eliminate wrong answers

Option B is wrong because CHOWN, DAC_OVERRIDE, and FOWNER are file permission capabilities that control ownership and access control, not kernel-level escape vectors; they are less critical for preventing container escapes. Option C is wrong because KILL, SETPCAP, and SYS_CHROOT are not primary escape enablers: KILL sends signals, SETPCAP manages capability sets, and SYS_CHROOT is a legacy syscall that is already restricted by default in modern runtimes. Option D is wrong because NET_RAW, NET_ADMIN, and NET_BIND_SERVICE are networking capabilities that affect packet crafting and interface configuration, not direct kernel access or module loading.

Full explanation →
652
MCQeasy

Which of the following is a static analysis tool for Kubernetes manifests?

A.Kubesec
B.Cosign
C.Trivy
D.Syft
AnswerA

Kubesec analyzes Kubernetes resource manifests and scores them based on security best practices.

Why this answer

Kubesec is a static analysis tool that evaluates Kubernetes resources against security best practices. The others are not static analysis tools for manifests.

Full explanation →
653
MCQhard

You are configuring ImagePolicyWebhook admission controller to reject images not signed by a trusted authority. After deploying the webhook, you notice that pods are being rejected even for images that are properly signed. Which configuration change is MOST likely to fix this?

A.Increase the memory limit of the API server
B.Change the webhook from 'MutatingAdmissionWebhook' to 'ValidatingAdmissionWebhook'
C.Set failurePolicy to Ignore in the webhook configuration
D.Grant the webhook service account cluster-admin role
AnswerC

When the webhook cannot be reached, the API server rejects the request. Setting failurePolicy: Ignore allows pods to be admitted even if the webhook is unavailable, but this is a temporary fix. The root cause might be network connectivity to the webhook service.

Why this answer

Option C is correct. The ImagePolicyWebhook admission controller uses an external webhook that must be reachable. If the webhook fails, the default behavior is to reject the request unless failurePolicy is set to Ignore.

Option A is about resource limits. Option B is about RBAC. Option D is irrelevant.

Full explanation →
654
MCQmedium

A DevOps team is deploying a new microservice that processes sensitive payment data. The security policy requires that all file system writes outside the /tmp directory be logged and alerted. Which runtime security tool and configuration best achieves this requirement with minimal performance impact?

A.Use Seccomp profiles to block write syscalls outside /tmp
B.Implement an OPA Gatekeeper constraint to reject pods that write outside /tmp
C.Deploy Falco with a rule: 'evt.type=open and evt.dir=< and fd.name startswith / and not fd.name startswith /tmp'
D.Configure AppArmor to deny writes outside /tmp
AnswerC

Falco monitors system calls and can generate alerts for file writes outside /tmp with minimal overhead.

Why this answer

Option C is correct because Falco is a runtime security tool that monitors system calls in real time. The provided rule specifically triggers an alert when a file is opened for writing (evt.dir=<) outside of /tmp, meeting the logging and alerting requirement with minimal performance impact since it only inspects syscalls without blocking them.

Exam trap

CNCF often tests the distinction between runtime monitoring (Falco) and enforcement tools (Seccomp, AppArmor, OPA Gatekeeper), and the trap here is that candidates choose blocking tools (A or D) or admission control (B) instead of the tool that specifically logs and alerts at runtime with minimal performance impact.

How to eliminate wrong answers

Option A is wrong because Seccomp profiles block syscalls at the kernel level, which would prevent the microservice from writing anywhere (including legitimate writes), and blocking syscalls has higher performance overhead than monitoring; also, Seccomp cannot selectively allow writes only to /tmp based on file path. Option B is wrong because OPA Gatekeeper is an admission controller that rejects pods at deployment time, but it cannot monitor or alert on runtime file system writes after the pod is running. Option D is wrong because AppArmor denies writes at the kernel level, which would block the writes entirely rather than logging and alerting, and it imposes a performance penalty on every write attempt.

Full explanation →
655
MCQeasy

An admin runs 'crictl ps' on a node and sees multiple containers. Which command should they use to view the logs of a specific container?

A.crictl logs <container-id>
B.crictl exec <container-id> logs
C.crictl inspect <container-id>
D.crictl ps -a <container-id>
AnswerA

crictl logs fetches logs of the specified container.

Why this answer

crictl logs is the correct command to retrieve logs from a container. crictl ps lists containers, crictl exec runs a command inside a container, and crictl inspect shows detailed info.

Full explanation →
656
Multi-Selecthard

Which THREE of the following are recommended measures to reduce the attack surface of Kubernetes nodes?

Select 3 answers
A.Disable unnecessary system services on nodes
B.Minimize host access from containers (avoid hostPID, hostNetwork, hostIPC)
C.Open all ports on nodes to allow easy debugging
D.Run all containers as root user
E.Apply Pod Security Standards to enforce least privilege
AnswersA, B, E

Reduces attack surface by removing unused services.

Why this answer

Disabling unnecessary services (e.g., SSH if not needed), minimizing host access from containers (avoid hostPID, hostNetwork, hostIPC), and using Pod Security Standards to enforce least privilege are all effective hardening measures. Running containers as root is not recommended, and opening all ports increases the attack surface.

Full explanation →
657
Multi-Selecteasy

Which TWO of the following are valid modes for an AppArmor profile?

Select 2 answers
A.unconfined
B.complain
C.enforce
D.permissive
E.audit
AnswersB, C

In complain mode, violations are logged but not blocked.

Why this answer

AppArmor profiles operate in two primary modes: 'complain' (also known as 'learning' mode) and 'enforce' (also known as 'confined' mode). In complain mode, policy violations are logged but not blocked, allowing administrators to test and refine profiles. In enforce mode, violations are both logged and blocked, actively restricting the application's behavior according to the profile.

Exam trap

CNCF often tests the distinction between AppArmor and SELinux terminology, where candidates mistakenly apply SELinux concepts (like 'permissive' or 'enforcing') to AppArmor, which uses 'complain' and 'enforce' as its only two valid modes.

Full explanation →
658
MCQeasy

A security engineer needs to ensure that all communication between nodes and the control plane is encrypted. Which component must be configured with a TLS certificate to achieve this?

A.kube-proxy
B.etcd
C.kube-scheduler
D.kube-apiserver
AnswerD

The API server serves HTTPS; configuring its TLS certificate encrypts all communication to/from it.

Why this answer

The kube-apiserver is the central gateway for all cluster operations, and it must be configured with a TLS certificate to encrypt communication between nodes (kubelets) and the control plane. The kube-apiserver presents this certificate to authenticate itself and establish encrypted HTTPS connections, ensuring that all traffic from node components (e.g., kubelets, kube-proxy) and other control plane components is secured in transit.

Exam trap

CNCF often tests the misconception that etcd is the primary component for encryption because it stores sensitive data, but the question specifically asks about encrypting communication between nodes and the control plane, which is handled by the kube-apiserver's TLS certificate, not etcd's internal encryption.

How to eliminate wrong answers

Option A is wrong because kube-proxy is a network proxy that runs on each node and handles service routing, but it does not terminate TLS for node-to-control-plane communication; it relies on the kube-apiserver's TLS for secure connections. Option B is wrong because etcd stores cluster data and can be configured with its own TLS certificates for peer and client communication, but it is not the component that encrypts node-to-control-plane traffic; it is a data store accessed by the kube-apiserver. Option C is wrong because kube-scheduler is a control plane component that assigns pods to nodes, but it communicates with the kube-apiserver via TLS (using the apiserver's certificate) and does not itself present a certificate for node-to-control-plane encryption.

Full explanation →
659
Multi-Selecteasy

You are asked to secure a set of microservices running in a Kubernetes cluster. Which TWO of the following practices help minimize vulnerabilities in microservices?

Select 2 answers
A.Manually inject sidecar proxies into every pod to enforce mTLS.
B.Run containers in privileged mode to allow them to perform necessary system calls.
C.Ensure containers run with a non-root user.
D.Use a read-only root filesystem for containers.
E.Store secrets directly in container images for easy access.
AnswersC, D

Running as non-root limits the permissions available to an attacker if the container is compromised.

Why this answer

Option C is correct because running containers with a non-root user (via the `securityContext.runAsNonRoot: true` field or a specific `runAsUser` directive) prevents privilege escalation and limits the blast radius of a container compromise. This aligns with the principle of least privilege, a core mitigation against container breakout attacks in Kubernetes.

Exam trap

CNCF often tests the misconception that sidecar proxies must be manually injected to enforce mTLS, but the correct approach is to use automated injection via admission controllers to avoid misconfiguration and ensure consistent policy enforcement.

Full explanation →
660
MCQhard

A security scan reports that the etcd data directory is not encrypted at rest. The cluster uses etcd v3.5. Which steps are required to enable encryption?

A.Use etcdctl to encrypt the data directory
B.Create an EncryptionConfiguration resource with aescbc, restart API server with --encryption-provider-config
C.Set --encryption-provider=secretbox on etcd
D.Set ETCD_ENABLE_ENCRYPTION=true environment variable
AnswerB

This is the correct procedure for enabling encryption at rest.

Why this answer

Option B is correct because etcd data encryption at rest in Kubernetes is implemented via an EncryptionConfiguration resource that specifies a provider (e.g., aescbc) and a key. The kube-apiserver must be restarted with the --encryption-provider-config flag pointing to that configuration file, which instructs the API server to encrypt resources before writing them to etcd. This is the only supported method for enabling encryption at rest in Kubernetes clusters using etcd v3.5.

Exam trap

The trap here is that candidates often assume encryption at rest is configured directly on etcd (via flags or environment variables), when in fact it is a kube-apiserver-level feature that uses an EncryptionConfiguration resource and the --encryption-provider-config flag.

How to eliminate wrong answers

Option A is wrong because etcdctl does not have a command to encrypt the entire data directory; encryption is handled at the Kubernetes API server level, not by directly manipulating etcd. Option C is wrong because --encryption-provider is not a valid flag for etcd; etcd itself does not natively support encryption at rest via a flag, and the encryption provider configuration is applied to the kube-apiserver, not etcd. Option D is wrong because ETCD_ENABLE_ENCRYPTION is not a recognized environment variable in etcd v3.5; encryption at rest is not enabled by setting an environment variable on etcd.

Full explanation →
661
MCQmedium

You are implementing a Gatekeeper policy to deny pods that run as root. Which Rego rule should you include in the ConstraintTemplate?

A.allow[{"msg": msg}] { msg := "container runs as root"; input.spec.containers[_].securityContext.runAsNonRoot == false }
B.deny[msg] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
C.deny[{"msg": msg}] { msg := "container runs as root"; not input.spec.containers[_].securityContext.runAsNonRoot }
D.deny[msg] { input.spec.containers[_].securityContext.runAsNonRoot == false }
AnswerC

This Rego rule denies pods where runAsNonRoot is not set to true.

Why this answer

Option A is correct. The deny rule in Rego returns a violation message when the condition is true. To deny pods running as root, the rule should check if runAsNonRoot is set to false (or not set).

Option B is syntactically incorrect (missing 'msg'). Option C allows root. Option D is not a valid Rego rule structure.

Full explanation →
662
MCQmedium

You need to isolate a compromised pod named 'malicious-pod' in the 'default' namespace so that it cannot communicate with any other pod, but can still receive traffic from a specific monitoring pod. Which NetworkPolicy should you apply?

A.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - from: - podSelector: matchLabels: app: monitoring-pod policyTypes: - Ingress - Egress
B.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod egress: - {} policyTypes: - Egress
C.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod policyTypes: - Ingress - Egress
D.apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: isolate-pod spec: podSelector: matchLabels: app: malicious-pod ingress: - {} policyTypes: - Ingress
AnswerA

Allows ingress only from monitoring-pod, and blocks all egress by default. This isolates the pod while allowing monitoring.

Why this answer

Option B specifies podSelector: matchLabels: app: malicious-pod, ingress from a specific pod (monitoring-pod), and no egress rules, so egress is denied by default. Option A denies all ingress as well (no ingress rules). Option C allows all ingress.

Option D allows all egress.

Full explanation →
663
MCQeasy

Which kubectl command would you use to create a ValidatingWebhookConfiguration from a YAML file?

A.kubectl run webhook --image=webhook --restart=Never
B.kubectl apply -f webhook.yaml
C.kubectl create -f webhook.yaml
D.kubectl expose deployment webhook --port=443
AnswerB

This is the standard command to create or update resources from a file.

Why this answer

The correct command is `kubectl apply -f webhook.yaml` to create or update the resource from a file.

Full explanation →
664
MCQeasy

Which kubectl command would you use to create a Secret from a file named 'db-password.txt'?

A.kubectl apply -f db-password.txt
B.kubectl create configmap db-password --from-file=db-password.txt
C.kubectl create secret tls db-password --cert=db-password.txt
D.kubectl create secret generic db-password --from-file=db-password.txt
AnswerD

This creates a Secret named 'db-password' with the file contents.

Full explanation →
665
MCQeasy

Which kubelet flag should be set to ensure the kubelet does not allow anonymous requests?

A.--authentication-token-webhook=true
B.--read-only-port=0
C.--anonymous-auth=false
D.--protect-kernel-defaults=true
AnswerC

Setting this flag to false on the kubelet disables anonymous requests to the kubelet.

Why this answer

Option C is correct because setting `--anonymous-auth=false` explicitly disables anonymous requests to the kubelet. By default, anonymous authentication is enabled, which allows unauthenticated users to access the kubelet API. Disabling this flag ensures that only authenticated requests are processed, aligning with the principle of least privilege and hardening the cluster.

Exam trap

The trap here is that candidates often confuse `--anonymous-auth=false` with `--authentication-token-webhook=true`, thinking token webhook alone blocks anonymous requests, but anonymous auth must be explicitly disabled as a separate step.

How to eliminate wrong answers

Option A is wrong because `--authentication-token-webhook=true` enables webhook-based token authentication (e.g., for service accounts), but it does not affect anonymous requests; anonymous auth is controlled by a separate flag. Option B is wrong because `--read-only-port=0` disables the read-only port (10255), which reduces exposure but does not prevent anonymous requests on the secure port (10250). Option D is wrong because `--protect-kernel-defaults=true` ensures kernel-level security settings (e.g., sysctl parameters) are enforced, but it has no impact on kubelet authentication or anonymous request handling.

Full explanation →
666
MCQmedium

An administrator needs to preserve evidence from a compromised container. Which approach is BEST for capturing the container's filesystem and memory for later analysis?

A.Use 'crictl export <container-id>' to create a tar archive of the container's filesystem
B.Use 'runc checkpoint' to create a checkpoint of the container
C.Use 'kubectl cp' to copy files from the container to the node
D.Use 'crictl save' to save the container image
AnswerA

crictl export exports the container's filesystem, which preserves file evidence.

Why this answer

crictl export exports the container's filesystem as a tar archive. For memory dump, tools like gcore or /proc/.../mem are needed. Option A is the closest match for filesystem preservation among the options.

Option B is for runc, not typical. Option D is for images.

Full explanation →
667
MCQhard

A pod is stuck in Pending state. 'kubectl describe pod' shows the event: '0/4 nodes are available: 1 node had taint {node-role.kubernetes.io/control-plane: }, that the pod didn't tolerate, 3 Insufficient memory.' The pod YAML does not specify any tolerations. Which command would allow the pod to schedule on the control-plane node?

A.kubectl taint nodes control-plane node-role.kubernetes.io/control-plane-
B.kubectl cordon control-plane
C.Edit the pod YAML to add tolerations for node-role.kubernetes.io/control-plane
D.kubectl delete pod --all
AnswerC

Adding the appropriate toleration allows the pod to schedule on tainted nodes.

Why this answer

To schedule on a control-plane node, you need to add a toleration for the node-role.kubernetes.io/control-plane taint. The other options are incorrect or incomplete.

Full explanation →
668
Multi-Selectmedium

Which TWO of the following are valid Pod Security Standards levels?

Select 2 answers
A.secure
B.default
C.privileged
D.baseline
E.strict
AnswersC, D

Valid level.

Why this answer

The three Pod Security Standard levels are privileged, baseline, and restricted. The other options are not valid.

Full explanation →
669
MCQeasy

To reduce the attack surface, a security best practice is to drop all capabilities from a container and add only those required. Which securityContext field is used to drop all capabilities?

A.capabilities.disable: ["ALL"]
B.capabilities.remove: ["ALL"]
C.capabilities.drop: ["ALL"]
D.privileged: false
AnswerC

This correctly drops all capabilities from the container.

Why this answer

In Kubernetes, the `capabilities.drop` field in the securityContext is used to explicitly remove Linux capabilities from a container. Setting `capabilities.drop: ["ALL"]` drops all capabilities, effectively reducing the attack surface by ensuring the container starts with no privileges, and then specific capabilities can be added back via `capabilities.add` if needed.

Exam trap

CNCF often tests the exact Kubernetes API field name `capabilities.drop` versus common but incorrect synonyms like `disable` or `remove`, and candidates may confuse dropping all capabilities with simply disabling privileged mode.

How to eliminate wrong answers

Option A is wrong because `capabilities.disable` is not a valid field in the Kubernetes securityContext; the correct field is `capabilities.drop`. Option B is wrong because `capabilities.remove` is not a recognized field in the Kubernetes API; the field is specifically named `drop`. Option D is wrong because `privileged: false` only disables privileged mode, but the container still retains its default set of capabilities; it does not drop all capabilities.

Full explanation →
670
MCQmedium

You want to ensure that the Kubernetes Dashboard is accessed only by authenticated users with specific permissions. What is the BEST approach?

A.Expose Dashboard via NodePort and rely on network firewalls
B.Create a ClusterRoleBinding granting cluster-admin to all service accounts
C.Set Dashboard to use HTTP instead of HTTPS
D.Use an ingress with authentication, and create RBAC roles for Dashboard users
AnswerD

This ensures secure access with authentication and least privilege.

Why this answer

Option D is correct because the Kubernetes Dashboard should be secured using an Ingress controller with authentication (e.g., OIDC, basic auth, or client certificate) combined with fine-grained RBAC roles to restrict what each authenticated user can do. This ensures that only authorized users with specific permissions can access the Dashboard, following the principle of least privilege and cluster hardening best practices.

Exam trap

The trap here is that candidates often think network-level controls (NodePort + firewall) are sufficient for securing the Dashboard, but the CKS exam emphasizes that Kubernetes security requires authentication and authorization at the API level, not just network segmentation.

How to eliminate wrong answers

Option A is wrong because exposing the Dashboard via NodePort bypasses authentication and authorization, relying solely on network firewalls which do not provide user-level access control or audit logging. Option B is wrong because granting cluster-admin to all service accounts would give every service account full administrative privileges, violating the principle of least privilege and creating a massive security risk. Option C is wrong because setting the Dashboard to use HTTP instead of HTTPS exposes all traffic in plaintext, allowing man-in-the-middle attacks and credential theft, and does not address authentication or authorization.

Full explanation →
671
MCQmedium

A Kubernetes cluster has Kyverno installed. A policy requires that all images come from a trusted registry 'trusted.example.com'. A Deployment uses the image 'nginx:latest'. When the Deployment is created, it is blocked. What Kyverno policy action is being used?

A.validate with failureAction: enforce
B.audit
C.mutate
D.generate
AnswerA

Enforce validation blocks non-compliant resources.

Why this answer

Kyverno policies can use 'validate' to enforce rules; the 'enforce' failure action causes the resource to be blocked.

Full explanation →
672
MCQmedium

A DevOps engineer runs 'trivy image myapp:latest' and finds a critical CVE in the base image. Which Dockerfile change would BEST address this?

A.Use an Alpine base image with the latest tag
B.Set USER root in the Dockerfile
C.Switch to a distroless base image with a SHA digest
D.Add a non-root user in the Dockerfile
AnswerC

Distroless images are minimal and have fewer CVEs. Using SHA prevents unexpected changes.

Why this answer

Using a minimal distroless base image reduces attack surface and typically has fewer CVEs. Pinning to a specific SHA ensures repeatability and avoids pulling an updated tag that may introduce different vulnerabilities.

Full explanation →
673
MCQhard

A Kyverno policy is written to require all images to use SHA256 digests instead of tags. The policy uses a 'validate' rule with 'pattern' on 'spec.containers[*].image'. Which pattern would match an image reference like 'registry.example.com/myapp@sha256:abc123...'?

A."*@sha256:*"
B."*@*"
C."*@sha256:*"
D."*:*"
AnswerC

This glob pattern matches any image that contains '@sha256:'.

Why this answer

The policy should use a regular expression that requires an '@sha256:' in the image field. Option C correctly matches the digest format.

Full explanation →
674
MCQeasy

In a CI/CD pipeline, which step is MOST effective for detecting known vulnerabilities in a container image before deployment?

A.Run a vulnerability scan on the container image
B.Check the image size
C.Run unit tests on the application code
D.Lint the Dockerfile
AnswerA

Scanning the image for CVEs identifies known security issues.

Why this answer

Running an image vulnerability scanner like Trivy in the pipeline detects CVEs before deployment. Option B is correct.

Full explanation →
675
MCQeasy

Which command scans a Docker image for CVEs using Trivy?

A.trivy cve myapp:latest
B.trivy check myapp:latest
C.trivy image myapp:latest
D.trivy scan myapp:latest
AnswerC

This is the correct Trivy command to scan a container image for vulnerabilities.

Why this answer

The correct command to scan an image for vulnerabilities with Trivy is `trivy image <image>`. Option A is correct.

Full explanation →
Page 8

Page 9 of 14

Page 10

All pages

1234567891011121314

Practice CKS by domain

Target a specific domain to shore up weak areas.

Monitoring Logging and Runtime SecurityCluster Setup and HardeningSystem HardeningMinimize Microservice VulnerabilitiesSupply Chain SecurityMonitoring, Logging and Runtime SecurityCluster SetupCluster Hardening
See all domains with question counts →