Knowledge + Practice

Certified Kubernetes Security Specialist CKS (CKS) — Questions 1–75

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

Take a mock exam Exam hub

Page 1 of 14

1

MCQmedium

What is the purpose of the --authorization-mode=RBAC flag on the API server?

A.It enables role-based access control for the API server

B.It disables anonymous authentication

C.It enables the NodeRestriction admission plugin

D.It enables audit logging for RBAC events

AnswerA

RBAC is the standard authorization mode for Kubernetes.

Why this answer

The `--authorization-mode=RBAC` flag configures the Kubernetes API server to use Role-Based Access Control (RBAC) as its authorization mode. This means that when a request reaches the API server, after authentication, the authorization module checks the request against RBAC roles and role bindings to determine if the user or service account has permission to perform the requested action. Without this flag, the API server would default to other modes (e.g., AlwaysAllow) or require explicit configuration of a different authorizer.

Exam trap

CNCF often tests the distinction between authorization modes and other API server flags (like admission plugins or audit logging), so candidates may confuse `--authorization-mode=RBAC` with enabling audit logging or admission controllers, when in fact each flag controls a completely separate subsystem.

How to eliminate wrong answers

Option B is wrong because anonymous authentication is controlled by the `--anonymous-auth` flag (defaults to true), not by the `--authorization-mode` flag; disabling anonymous auth is a separate configuration. Option C is wrong because the NodeRestriction admission plugin is enabled via the `--enable-admission-plugins` flag, not through the authorization mode flag. Option D is wrong because audit logging for RBAC events is configured via the `--audit-policy-file` flag and audit policy rules, not by setting the authorization mode to RBAC.

Full explanation →

2

MCQmedium

A security engineer wants to enforce that all containers in a namespace run without any unnecessary Linux capabilities, dropping all capabilities by default and only adding back what is needed. Which Pod Security Standard should be applied to that namespace using PodSecurity admission?

A.Privileged

B.Custom

C.Baseline

D.Restricted

AnswerD

Restricted enforces dropping all capabilities and only adding back required ones, meeting the requirement.

Why this answer

The Restricted Pod Security Standard is the most stringent profile, which enforces dropping all capabilities by default and only allowing those explicitly required. It sets `securityContext.capabilities.drop: ["ALL"]` and restricts `allowedCapabilities` to an empty set, ensuring containers run with minimal Linux capabilities. This directly matches the requirement to drop all capabilities and add back only what is needed.

Exam trap

CNCF often tests the misconception that 'Baseline' is sufficient for strict capability control, but Baseline only blocks known dangerous capabilities (e.g., `CAP_SYS_ADMIN`) and does not require dropping all capabilities, so candidates must recognize that only Restricted enforces a full drop-all policy.

How to eliminate wrong answers

Option A is wrong because the Privileged profile allows unrestricted capabilities and does not enforce dropping any, which is the opposite of the requirement. Option B is wrong because 'Custom' is not a valid Pod Security Standard; the three built-in standards are Privileged, Baseline, and Restricted. Option C is wrong because the Baseline profile only prevents known privilege escalations but does not require dropping all capabilities by default, so it does not enforce the strict capability policy needed.

Full explanation →

3

Multi-Selectmedium

Which TWO of the following are valid approaches to manage secrets in a Kubernetes cluster?

Select 2 answers

A.Pass secrets as environment variables

B.Embed secrets directly in the pod YAML definition

C.Mount secrets as volumes in pods

D.Store secrets as plain text in ConfigMap

E.Use an external secrets manager like HashiCorp Vault with CSI driver

AnswersC, E

This is a best practice; secrets are mounted as files.

Why this answer

Mounting secrets as volumes and using an external secrets manager like HashiCorp Vault are both valid. Storing in ConfigMap is insecure because ConfigMaps are not encrypted. Embedding in YAML is insecure.

Using environment variables is less secure than volumes.

Full explanation →

4

MCQhard

In a Falco rule, you have the condition: 'evt.type=execve and proc.name=bash and container.id!=host'. What does this rule detect?

A.A non-root bash process on the host

B.A bash shell being spawned inside a container

C.An interactive shell session inside a container

D.A bash process reading /etc/shadow

AnswerB

The rule matches execve events where the process name is bash and it is not running on the host (i.e., inside a container).

Why this answer

The rule triggers when a bash shell is executed (execve) inside any container (container.id != host). It does not check for interactive use; it simply detects bash execution.

Full explanation →

5

MCQmedium

A security admin wants to ensure that no container in a specific namespace runs as root. Which Gatekeeper ConstraintTemplate and Constraint configuration should be used?

A.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

B.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsNonRoot != true }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

C.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.capabilities.drop != "ALL" }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

D.ConstraintTemplate: rego `deny[msg] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }`; Constraint: `spec.match.kinds: [{"kinds": ["Pod"]}]`

AnswerB

This correctly denies pods where any container does not set runAsNonRoot to true.

Why this answer

Option A correctly defines a ConstraintTemplate with a Rego rule that checks `runAsNonRoot` is true, and a Constraint that matches all pods in the namespace. Option B checks the wrong field. Option C uses `securityContext.capabilities` which is unrelated.

Option D uses an incorrect Rego condition.

Full explanation →

6

MCQeasy

To ensure a container's filesystem is read-only, which field should be set to 'true' in the container spec?

A.securityContext.readOnlyRootFilesystem

B.securityContext.runAsNonRoot

C.container.fsGroup

D.podSpec.containers.readonly

AnswerA

This is the correct field in the container's security context.

Why this answer

The securityContext field readOnlyRootFilesystem controls whether the container's root filesystem is read-only. The other options are either non-existent or have different effects.

Full explanation →

7

Multi-Selecteasy

Which THREE of the following are tools used for static analysis of Kubernetes manifests?

Select 3 answers

A.kubesec

B.checkov

C.kube-score

D.trivy

E.syft

AnswersA, B, C

kubesec scans Kubernetes resources for security issues.

Why this answer

kubesec, checkov, and kube-score are static analysis tools. Trivy and Syft focus on container images and SBOMs.

Full explanation →

8

Multi-Selecthard

A security auditor recommends limiting the use of host namespaces in pods. Which THREE of the following fields, if set to true, expose the host namespace to a container?

Select 3 answers

A.hostPID

B.hostIPC

C.hostFS

D.hostUsers

E.hostNetwork

AnswersA, B, E

Sharing the host's PID namespace lets the container see all host processes.

Why this answer

Setting `hostPID: true` in a Pod spec allows the container to share the host's process ID namespace. This means the container can see and interact with all processes running on the host node, which breaks process isolation and can lead to privilege escalation or information leakage.

Exam trap

CNCF often tests the distinction between actual Pod spec fields (`hostPID`, `hostIPC`, `hostNetwork`) and non-existent or runtime-specific fields like `hostFS` or `hostUsers`, which candidates might confuse with host namespace options.

Full explanation →

9

MCQhard

After running kube-bench, you see a failing check: '1.1.1 Ensure that the API server pod specification file permissions are set to 600 or more restrictive'. What is the remediation?

A.Change permissions of /var/lib/kubelet/config.yaml to 600

B.Change permissions of /var/log/audit.log to 600

C.Change permissions of /etc/kubernetes/manifests/kube-apiserver.yaml to 600

D.Change permissions of /etc/kubernetes/manifests/kube-controller-manager.yaml to 600

AnswerC

This file contains the API server's static pod definition; restrictive permissions prevent unauthorized changes.

Why this answer

Check 1.1.1 from kube-bench specifically targets the API server pod specification file, which is located at /etc/kubernetes/manifests/kube-apiserver.yaml. The remediation is to set its permissions to 600 or more restrictive to prevent unauthorized read or write access, as this file contains critical configuration parameters for the API server.

Exam trap

CNCF often tests the exact mapping between kube-bench check IDs and their corresponding file paths, so the trap here is confusing the API server pod spec file with other static pod manifests (like controller-manager) or configuration files (like kubelet config or audit logs).

How to eliminate wrong answers

Option A is wrong because /var/lib/kubelet/config.yaml is the kubelet configuration file, not the API server pod spec, and its permissions are covered by a different kube-bench check (e.g., 4.1.1). Option B is wrong because /var/log/audit.log is an audit log file, not a pod specification file, and its permissions are addressed by checks related to audit logging, not check 1.1.1. Option D is wrong because /etc/kubernetes/manifests/kube-controller-manager.yaml is the controller manager pod spec, which is a separate component; check 1.1.1 is specific to the API server pod spec file.

Full explanation →

10

Multi-Selectmedium

Which TWO of the following are valid methods to secure the etcd datastore in a Kubernetes cluster?

Select 2 answers

A.Enable TLS encryption for client-to-server communication.

B.Enable peer authentication using TLS certificates.

C.Use HTTP instead of HTTPS for better performance.

D.Disable client authentication to simplify configuration.

E.Expose the etcd port (2379) on a public IP for easier monitoring.

AnswersA, B

TLS encrypts data in transit between etcd and clients.

Why this answer

Option A is correct because enabling TLS encryption for client-to-server communication ensures that all data transmitted between etcd clients (such as the Kubernetes API server) and the etcd server is encrypted, preventing eavesdropping and man-in-the-middle attacks. This is a fundamental security measure for protecting sensitive cluster state and secrets stored in etcd.

Exam trap

The trap here is that candidates may think enabling TLS for client-to-server communication is optional or that peer authentication is not required, but the CKS exam emphasizes that both client and peer TLS are mandatory for securing etcd in a hardened cluster.

Full explanation →

11

MCQmedium

A developer wants to ensure that a pod always uses a specific version of an image that cannot be changed without updating the manifest. Which image reference should be used?

A.myimage@sha256:abcdef...

B.myimage:latest

C.myimage:v1.0

D.myimage:1.0.0

AnswerA

A digest uniquely identifies the image content; any change results in a different digest.

Why this answer

Using an image digest (SHA256) ensures that the exact image is used, even if the tag is updated. This prevents unauthorized changes to the image without updating the manifest.

Full explanation →

12

MCQmedium

You need to drop all Linux capabilities from a container. Which YAML snippet is correct?

A.capabilities: { remove: ["ALL"] }

B.capabilities: { drop: ["ALL"] }

C.capabilities: { none: true }

D.securityContext: { capabilities: { drop: ["ALL"] } }

AnswerB, D

Correct.

Why this answer

The correct way is to drop ALL capabilities using 'capabilities.drop: ["ALL"]'.

Full explanation →

13

MCQmedium

An administrator wants to enable audit logging on the API server. Which three flags are required to set up basic audit logging?

A.--audit-log-maxage=30

B.--audit-log-format=json

C.--audit-log-path=/var/log/kubernetes/audit.log

D.--audit-policy-file=/etc/kubernetes/audit-policy.yaml

AnswerA, C, D

Sets the number of days to retain old audit log files.

Why this answer

Option A is correct because the `--audit-log-maxage` flag defines the maximum number of days to retain old audit log files. This is a required flag for basic audit logging setup, as it ensures log rotation and prevents disk exhaustion. Without this flag, the API server will not rotate logs, which can lead to data loss or storage issues.

Exam trap

CNCF often tests the misconception that `--audit-log-format=json` is required for basic audit logging, when in fact JSON is the default format and the flag is optional, leading candidates to select it as a required flag.

How to eliminate wrong answers

Option B is wrong because `--audit-log-format=json` is not a required flag for basic audit logging; it is optional and defaults to JSON format if not specified. The basic audit logging setup only requires flags for log path, policy file, and retention settings, not the format. Option C is correct as it specifies the log file path, which is mandatory for enabling audit logging.

Option D is correct as it points to the audit policy file, which defines what events to log and is required for audit logging to function.

Full explanation →

14

MCQhard

You are tasked with securing the kubelet. Which flag must be set on the kubelet to enable the NodeRestriction admission plugin?

A.--admission-control=NodeRestriction on the kubelet

B.--enable-admission-plugins=NodeRestriction on the kubelet

C.--node-restriction=true on the kubelet

D.--enable-admission-plugins=NodeRestriction on the kube-apiserver

AnswerD

The NodeRestriction plugin is an admission controller on the API server, enabled with this flag.

Why this answer

Option D is correct because the NodeRestriction admission plugin is an admission controller that runs on the kube-apiserver, not on the kubelet. It limits the Node and Pod objects a kubelet can modify, enforcing that nodes can only modify their own node object and pods bound to them. The flag `--enable-admission-plugins=NodeRestriction` on the kube-apiserver activates this plugin, which is a key security control for hardening the cluster.

Exam trap

The trap here is that candidates confuse the kubelet's role with the kube-apiserver's role, assuming admission plugins are configured on the kubelet because the NodeRestriction plugin directly affects kubelet behavior, but in reality admission plugins are always server-side components on the kube-apiserver.

How to eliminate wrong answers

Option A is wrong because the kubelet does not have an `--admission-control` flag; admission plugins are configured on the kube-apiserver, and the deprecated `--admission-control` flag was replaced by `--enable-admission-plugins`. Option B is wrong because the kubelet does not support the `--enable-admission-plugins` flag; that flag is exclusive to the kube-apiserver, and the kubelet has no concept of admission plugins. Option C is wrong because there is no `--node-restriction` flag on the kubelet; the NodeRestriction admission plugin is enabled via the kube-apiserver, not through a boolean flag on the kubelet.

Full explanation →

15

MCQmedium

You need to audit all API requests to the cluster. Which set of apiserver flags should be configured?

A.--audit-log-path, --audit-policy-file

B.--audit-log-maxage, --audit-log-maxbackup

C.--audit-webhook-config-file, --audit-webhook-mode

D.--audit-dynamic-configuration

AnswerA

These two enable audit logging.

Why this answer

To audit all API requests to the cluster, you must enable the audit logging feature in the kube-apiserver. The two essential flags are `--audit-log-path` to specify the file where audit events are written and `--audit-policy-file` to define the rules that determine which events are logged. Without both, the apiserver will not generate audit logs at all.

Exam trap

CNCF often tests the distinction between enabling audit logging and configuring its advanced features, so candidates mistakenly pick rotation or webhook options thinking they are the primary enablers.

How to eliminate wrong answers

Option B is wrong because `--audit-log-maxage` and `--audit-log-maxbackup` control log rotation and retention, not the enabling of audit logging itself. Option C is wrong because `--audit-webhook-config-file` and `--audit-webhook-mode` configure a webhook backend for audit events, but they still require `--audit-policy-file` to define which events to send; they are not the minimal set to enable auditing. Option D is wrong because `--audit-dynamic-configuration` enables runtime changes to the audit policy, but it is an additional feature that requires a base audit policy file to be already configured; it does not enable auditing by itself.

Full explanation →

16

MCQeasy

Which tool can be used to generate an SBOM (Software Bill of Materials) for a container image?

A.trivy

B.kubesec

C.checkov

D.syft

AnswerD

Syft generates SBOMs from container images.

Why this answer

Syft is a tool specifically designed for generating SBOMs from container images.

Full explanation →

17

MCQmedium

You need to configure audit logging for the Kubernetes API server to log all requests at the Metadata level. Which flag and value should you set in the kube-apiserver configuration?

A.--audit-policy-file=/etc/kubernetes/audit-policy.yaml

B.--audit-webhook-config=/etc/kubernetes/audit-webhook.yaml

C.--audit-log-path=/var/log/audit.log

D.--audit-log-format=json

AnswerA

This flag specifies the path to the audit policy file, which defines rules including the level.

Why this answer

The --audit-policy-file flag points to a YAML file defining the audit policy. The policy file sets the level (Metadata) and stages. The other options are incorrect: --audit-log-path sets the log file, --audit-log-format sets the format, and --audit-webhook-config is for webhook backend.

Full explanation →

18

MCQmedium

You are managing a Kubernetes cluster that hosts multiple microservices. The cluster uses Kubernetes v1.25. Recently, a security audit identified that containers are running with the default seccomp profile (unconfined). The security team has requested that all containers use a seccomp profile that blocks unnecessary syscalls. You need to implement this cluster-wide without breaking existing applications. The audit also found that the kubelet's anonymous authentication is enabled, which should be disabled. Additionally, you need to ensure that the kubelet's NodeRestriction admission controller is enabled to limit what nodes can do. Which of the following is the most appropriate sequence of actions?

A.Disable anonymous authentication immediately, then enable NodeRestriction, and finally apply the restrictive seccomp profile

B.Apply the 'runtime/default' seccomp profile cluster-wide immediately, then disable anonymous auth, and finally enable NodeRestriction

C.Enable NodeRestriction first, then apply a restrictive seccomp profile, and last disable anonymous authentication

D.First, configure the kubelet to use a seccomp profile that logs violations (e.g., 'runtime/default' with log), then after verifying no breakage, switch to 'runtime/default'. Then disable anonymous authentication and enable NodeRestriction admission controller

AnswerD

This minimizes disruption by testing seccomp before enforcing, and then hardens kubelet.

Why this answer

Option D is correct because it follows the principle of least disruption: first, it applies the 'runtime/default' seccomp profile in logging mode to detect any blocked syscalls without breaking applications. After verifying no breakage, it switches to enforcing mode. Then, it disables anonymous authentication and enables the NodeRestriction admission controller, both of which are non-disruptive configuration changes.

This sequence minimizes risk to existing workloads while meeting all audit requirements.

Exam trap

The trap here is that candidates rush to apply the restrictive seccomp profile immediately (options A, B, C) without considering the need for a gradual rollout via logging mode to avoid breaking existing applications, which is a key CKS focus on safe system hardening.

How to eliminate wrong answers

Option A is wrong because disabling anonymous authentication immediately could break cluster components that rely on it (e.g., kubelet health checks) before verifying dependencies, and applying a restrictive seccomp profile without testing could crash applications. Option B is wrong because applying 'runtime/default' immediately without logging mode first risks breaking existing applications that depend on blocked syscalls. Option C is wrong because enabling NodeRestriction first is safe but applying a restrictive seccomp profile without prior logging validation could cause application failures, and disabling anonymous authentication last leaves a security gap during the process.

Full explanation →

19

MCQmedium

A microservice running as a Deployment in a Kubernetes cluster needs to authenticate to a third-party API using a static API key. Which is the most secure way to store and inject this secret into the container?

A.Store the API key in a ConfigMap and expose it as an environment variable

B.Hardcode the API key in the container image

C.Store the API key in a Kubernetes Secret and mount it as a volume inside the container

D.Store the API key in a Kubernetes Secret and expose it as an environment variable

AnswerC

Secrets are designed for sensitive data; volume mounts avoid exposure in environment variable listings.

Why this answer

Option C is correct because mounting a Kubernetes Secret as a volume provides the most secure method for injecting sensitive data into a container. Unlike environment variables, which can be exposed through process listings, container logs, or `/proc` filesystem, a volume mount stores the secret in the container's filesystem with permissions restricted to the runtime user. This approach also supports automatic rotation of secret values without restarting the pod, as the filesystem is updated in place when the Secret object changes.

Exam trap

CNCF often tests the misconception that environment variables from Secrets are equally secure as volume mounts, but the trap is that environment variables are more exposed to runtime leaks and cannot be rotated without pod restart, whereas volume mounts offer better isolation and live update capabilities.

How to eliminate wrong answers

Option A is wrong because ConfigMaps store data in plaintext and are intended for non-sensitive configuration, not secrets like API keys. Option B is wrong because hardcoding secrets in a container image embeds them in the image layers, making them accessible to anyone with image pull access and violating immutable infrastructure principles. Option D is wrong because exposing a Secret as an environment variable increases the risk of leakage through container logs, debugging endpoints, or the `/proc/self/environ` file, and does not support seamless secret rotation without pod restart.

Full explanation →

20

Multi-Selectmedium

Which TWO of the following are valid Falco rule priorities?

Select 2 answers

A.MEDIUM

B.WARNING

C.HIGH

D.CRITICAL

E.LOW

AnswersB, D

WARNING is a valid priority.

Why this answer

Falco priorities include EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG. HIGH and MEDIUM are not valid.

Full explanation →

21

Multi-Selectmedium

Which TWO of the following are valid audit stages in Kubernetes audit logging?

Select 2 answers

A.Authentication

B.ResponseComplete

C.Authorization

D.RequestReceived

E.ResponseStarted

AnswersB, D

Correct. This stage logs after the full response is sent.

Why this answer

Valid audit stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived and ResponseComplete are correct.

Full explanation →

22

MCQmedium

A security team is hardening a Kubernetes cluster. They need to ensure that all control plane components run with the least privilege. Which approach should they take?

A.Use seccomp profiles to block privilege escalation syscalls

B.Apply AppArmor profiles to all control plane pods

C.Configure control plane containers to run as non-root user and with read-only root filesystem

D.Enable PodSecurityPolicy with 'MustRunAsNonRoot' for control plane namespaces

AnswerC

This directly reduces privileges by avoiding root execution and preventing writes to the filesystem.

Why this answer

Option C is correct because running control plane containers as a non-root user and with a read-only root filesystem directly enforces the principle of least privilege at the container level. This approach limits the ability of an attacker who compromises a control plane component to escalate privileges or modify critical system files, which is a fundamental hardening requirement for the control plane.

Exam trap

CNCF often tests the distinction between runtime security mechanisms (seccomp, AppArmor) and container-level privilege controls (user ID, read-only filesystem), leading candidates to choose a syscall or MAC profile instead of the direct least-privilege configuration.

How to eliminate wrong answers

Option A is wrong because seccomp profiles restrict system calls (syscalls) but do not control the user identity under which a container runs or prevent privilege escalation via user namespace manipulation; they are a complementary measure, not a primary least-privilege approach. Option B is wrong because AppArmor profiles enforce mandatory access control on a per-program basis but do not change the user context of the container process; they also require a profile to be loaded on the node, which may not be available for all control plane components. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21 and removed in 1.25, and even when available, it only enforces policies at the pod admission level, not directly on the container runtime configuration; moreover, control plane components are often managed as static pods or systemd services, not through the Kubernetes API, making PSP inapplicable.

Full explanation →

23

MCQmedium

An administrator creates an EncryptionConfiguration with aescbc and saves it to /etc/kubernetes/enc/enc.yaml. Which flag must be added to the kube-apiserver to enable encryption at rest?

A.--encryption-config=/etc/kubernetes/enc/enc.yaml

B.--enable-encryption

C.--encryption-provider=aescbc

D.--encryption-provider-config=/etc/kubernetes/enc/enc.yaml

AnswerD

This flag specifies the path to the encryption configuration file.

Why this answer

Option D is correct because the kube-apiserver requires the `--encryption-provider-config` flag to specify the path to the EncryptionConfiguration YAML file that defines the encryption provider (e.g., aescbc) and resources to encrypt. This flag enables encryption at rest for Kubernetes secrets and other API data stored in etcd.

Exam trap

The trap here is that candidates confuse the valid `--encryption-provider-config` flag with similar-sounding but invalid flags like `--encryption-config` or `--encryption-provider`, or assume a simple `--enable-encryption` toggle exists, when in reality encryption at rest requires a detailed configuration file.

How to eliminate wrong answers

Option A is wrong because `--encryption-config` is not a valid kube-apiserver flag; the correct flag is `--encryption-provider-config`. Option B is wrong because `--enable-encryption` does not exist; encryption at rest is configured via a provider configuration file, not a boolean flag. Option C is wrong because `--encryption-provider` is not a valid flag; the encryption provider (e.g., aescbc) is specified inside the EncryptionConfiguration YAML, not as a separate command-line argument.

Full explanation →

24

Multi-Selectmedium

Which TWO AppArmor modes are available? (Select 2)

Select 2 answers

A.enforce

B.complain

C.audit

D.allow

E.unconfined

AnswersA, B

Enforce mode actively denies actions not allowed by the profile.

Full explanation →

25

MCQhard

An etcd cluster uses TLS for peer and client communication. Which command correctly tests connectivity to an etcd member with client certificate authentication?

A.etcdctl --endpoints=https://10.0.0.1:2379 --cert=/etc/etcd/etcd-client.crt endpoint health

B.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt --cert=/etc/etcd/etcd-client.crt --key=/etc/etcd/etcd-client.key endpoint health

C.etcdctl --endpoints=https://10.0.0.1:2379 --cacert=/etc/etcd/ca.crt endpoint health

D.etcdctl --endpoints=http://10.0.0.1:2379 endpoint health

AnswerB

Correct command with all necessary TLS flags.

Why this answer

Option B is correct because it provides all three required TLS components for mutual TLS (mTLS) authentication: the CA certificate (`--cacert`) to verify the server's identity, the client certificate (`--cert`) for the client's identity, and the client key (`--key`) to prove possession of the private key. The `endpoint health` command then performs a TLS handshake and checks the etcd member's health over HTTPS. Without any of these three, the connection will fail due to certificate validation errors or missing client authentication.

Exam trap

CNCF often tests the misconception that only the client certificate is needed for mTLS, causing candidates to forget the `--key` flag, or that only the CA certificate is sufficient for client authentication, leading them to omit the client certificate and key entirely.

How to eliminate wrong answers

Option A is wrong because it omits the `--cacert` flag, so the client cannot verify the server's TLS certificate against the trusted CA, causing a TLS handshake failure. Option C is wrong because it omits the `--cert` and `--key` flags, so the client cannot provide its own certificate for mutual TLS authentication, and the etcd server will reject the connection if client certificate authentication is enforced. Option D is wrong because it uses `http://` instead of `https://`, bypassing TLS entirely; if the etcd cluster requires TLS, this command will either be rejected or communicate over an unencrypted channel, failing the connectivity test.

Full explanation →

26

MCQhard

A cluster administrator wants to enforce the Pod Security Standard 'restricted' at the namespace level. Which command applies the PodSecurity admission label to the 'prod' namespace?

A.kubectl label namespace prod pod-security.kubernetes.io/warn=restricted

B.kubectl label namespace prod pod-security.kubernetes.io/audit=restricted

C.kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted

D.kubectl annotate namespace prod security.kubernetes.io/pod-security=restricted

AnswerC

This sets the enforce level to restricted for the namespace.

Why this answer

Option C is correct because the `enforce` label is the only one that actively blocks pods that violate the specified Pod Security Standard (PSS) level. The command `kubectl label namespace prod pod-security.kubernetes.io/enforce=restricted` applies the 'restricted' policy at the namespace level, causing the PodSecurity admission controller to reject any pod that does not comply with the restricted profile.

Exam trap

The trap here is that candidates confuse the three modes (enforce, audit, warn) and often pick `warn` or `audit` thinking they provide enforcement, or they mistakenly use an annotation instead of a label, which is not recognized by the PodSecurity admission controller.

How to eliminate wrong answers

Option A is wrong because the `warn` label only generates a warning message when a non-compliant pod is created, but does not block the pod. Option B is wrong because the `audit` label adds an audit event to the audit log for non-compliant pods, but does not enforce or block them. Option D is wrong because it uses an incorrect annotation key (`security.kubernetes.io/pod-security`) and the `annotate` command instead of `label`; the correct mechanism uses labels with the `pod-security.kubernetes.io/enforce` key.

Full explanation →

27

MCQmedium

A cluster uses RBAC and a ServiceAccount 'monitor' in namespace 'observability'. The account needs to list pods in all namespaces. Which ClusterRole and binding should be created?

A.Role with 'list' on pods, RoleBinding in observability

B.ClusterRole with 'get' on pods, ClusterRoleBinding

C.ClusterRole with 'list' on pods, RoleBinding in observability

D.ClusterRole with 'list' on pods, ClusterRoleBinding

AnswerD

Correct scope and verb for listing pods across all namespaces.

Why this answer

A ServiceAccount that needs to list pods across all namespaces requires a ClusterRole with the 'list' verb on pods, because ClusterRoles are not namespaced and can grant permissions cluster-wide. A ClusterRoleBinding is necessary to bind that ClusterRole to the ServiceAccount, as RoleBindings only apply within a single namespace and cannot grant cluster-scoped permissions.

Exam trap

The trap here is that candidates often confuse RoleBindings with ClusterRoleBindings, thinking a RoleBinding can grant cluster-wide access if the role is a ClusterRole, but in reality the binding's scope (namespace vs. cluster) determines the effective scope of the permissions.

How to eliminate wrong answers

Option A is wrong because a Role is namespaced and cannot grant permissions across all namespaces; also, a RoleBinding only applies within its namespace. Option B is wrong because the verb 'get' only allows retrieving a specific pod, not listing pods; the required verb is 'list'. Option C is wrong because a RoleBinding cannot bind a ClusterRole to grant cluster-wide access; it would only apply the ClusterRole's permissions within the 'observability' namespace, not across all namespaces.

Full explanation →

28

MCQeasy

In a Falco rule, what does the 'priority' field indicate?

A.The syscall filter condition

B.The format of the output message

C.The severity level of the event

D.The rule name

AnswerC

Correct: Priority defines how severe the event is.

Why this answer

The priority field sets the severity level of the rule (e.g., CRITICAL, WARNING). Option B is about output format, option C is for filtering, option D is about the rule name.

Full explanation →

29

MCQmedium

You need to encrypt Kubernetes secrets at rest. Which resource should you configure?

A.EncryptionProvider

B.SecretEncryptionConfig

C.KMSProvider

D.EncryptionConfiguration

AnswerD

Correct. EncryptionConfiguration is an API resource that specifies encryption providers and keys for encrypting resources at rest.

Why this answer

EncryptionConfiguration is the Kubernetes resource that defines how to encrypt resources at rest in etcd, including secrets. It is used with the kube-apiserver flag --encryption-provider-config.

Full explanation →

30

MCQmedium

An administrator wants to ensure that containers in the 'secure-app' namespace cannot write to their own filesystem. Which pod security context setting should be used?

A.securityContext: { runAsNonRoot: true }

B.securityContext: { privileged: false }

C.securityContext: { capabilities: { drop: ["ALL"] } }

D.securityContext: { readOnlyRootFilesystem: true }

AnswerD

Correct. This setting makes the container's root filesystem read-only.

Why this answer

Immutable container filesystem is achieved by setting readOnlyRootFilesystem: true in the securityContext of the container. This prevents writes to the root filesystem.

Full explanation →

31

MCQeasy

A developer wants to verify the signature of a container image before deploying it. Which command should they use along with Cosign?

A.cosign verify

B.cosign generate-key-pair

C.cosign sign

D.cosign attest

AnswerA

cosign verify checks the signature of an image against a public key.

Why this answer

Option D is correct. cosign verify is the command to verify the signature of an image. Option A is for signing. Option B is for generating keys.

Option C is for attaching attestations. Option D is the correct verification command.

Full explanation →

32

MCQeasy

You want to scan a container image for vulnerabilities before deploying it. Which command uses the Trivy tool to scan an image?

A.trivy check nginx:latest

B.trivy image nginx:latest

C.trivy fs nginx:latest

D.trivy scan nginx:latest

AnswerB

trivy image scans the specified container image for vulnerabilities.

Why this answer

The correct command to scan a container image with Trivy is 'trivy image'. Option A uses 'trivy fs' which scans a filesystem, not an image.

Full explanation →

33

MCQhard

A security engineer wants to encrypt secrets at rest in an existing Kubernetes cluster. The cluster is already running with the default encryption configuration. After creating an EncryptionConfiguration resource and updating the kube-apiserver manifest, which command should be used to ensure the new configuration is applied without restarting the API server?

A.kubectl label node control-plane --overwrite encryption=true

B.kubectl rollout restart -n kube-system deployment/kube-apiserver

C.kubectl apply -f encryption-config.yaml

D.kubectl delete pod -n kube-system -l component=kube-apiserver

AnswerB

Restarts the API server deployment, causing it to read the updated EncryptionConfiguration.

Why this answer

Option B is correct. After updating the EncryptionConfiguration, you must restart the kube-apiserver pod or process. The recommended way is to use 'kubectl rollout restart' on the API server pod (if it's managed by a static pod).

Option A is not needed. Option C does not affect encryption. Option D is not a valid command.

Full explanation →

34

MCQmedium

A security auditor runs kube-bench on a Kubernetes node and reports that the check '1.1.1 Ensure that the API server pod specification file permissions are set to 644 or more restrictive' fails. What is the most appropriate remediation?

A.Delete the API server manifest file

B.Run 'chmod 755 /etc/kubernetes/manifests/kube-apiserver.yaml'

C.Restart the kubelet service

D.Run 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml'

AnswerD

Correct. Setting permissions to 644 or more restrictive (e.g., 600) satisfies the benchmark.

Why this answer

Option D is correct because the CIS benchmark for Kubernetes requires the API server manifest file to have permissions of 644 or more restrictive (e.g., 600, 640, or 644) to prevent unauthorized modifications. Running 'chmod 644 /etc/kubernetes/manifests/kube-apiserver.yaml' sets the file to read-write for the owner and read-only for group and others, satisfying the benchmark. The kubelet automatically detects the change and reloads the static pod, so no restart is needed.

Exam trap

The trap here is that candidates often assume a service restart is required after a file permission change, but the kubelet automatically detects manifest file modifications, making a restart redundant and incorrect.

How to eliminate wrong answers

Option A is wrong because deleting the API server manifest file would remove the static pod definition, causing the API server to stop and the cluster to become unavailable. Option B is wrong because 'chmod 755' sets permissions to rwxr-xr-x, which is less restrictive than 644 (it grants execute permissions to all), failing the CIS check. Option C is wrong because restarting the kubelet service is unnecessary; the kubelet watches the manifest directory for changes and automatically reloads the static pod when the file permissions are updated.

Full explanation →

35

MCQmedium

You are investigating a pod that is suspected of being compromised. You need to preserve the container's filesystem for forensic analysis. Which `crictl` command should you use to export the container's filesystem as a tar archive?

A.crictl logs <container-id>

B.crictl export <container-id>

C.crictl inspect <container-id>

D.crictl exec <container-id> tar cvf /tmp/fs.tar /

AnswerB

Correct: crictl export exports the container's filesystem as a tar archive.

Why this answer

`crictl export` exports the container's filesystem as a tar archive. `crictl inspect` shows container metadata, not filesystem content. `crictl logs` retrieves logs. `crictl exec` runs commands in the container but does not export filesystem.

Full explanation →

36

Multi-Selectmedium

You want to use an external secret management system like HashiCorp Vault to manage database credentials for your application. Which of the following are valid approaches to integrate Vault with Kubernetes?

Select 3 answers

A.Use environment variables from Vault with a script

B.Store Vault tokens in a Kubernetes Secret and mount them

C.Use the Vault Agent Sidecar Injector to inject secrets into pods

D.Use the Vault CSI Provider to mount secrets as volumes

E.Store Vault tokens in a ConfigMap and mount them into pods

AnswersB, C, D

A Kubernetes Secret can hold a Vault token, but it's less secure than using Vault directly; however, it is a valid approach.

Full explanation →

37

MCQhard

You have a Kyverno policy that validates images are from a specific registry. However, a pod using an image from that registry is still blocked. The pod YAML includes 'imagePullPolicy: Always'. What could be the issue?

A.The imagePullPolicy is set to Always, causing Kyverno to ignore the registry check

B.The pod uses a different registry name than the one in the policy (e.g., a mirror)

C.Kyverno cannot validate images with a tag

D.The policy is missing the 'validate' rule type

AnswerB

The policy must match the exact image path used.

Why this answer

Kyverno matches against the exact image reference. If the registry is 'registry.example.com' but the pod uses 'docker.io/registry.example.com/image', the check fails.

Full explanation →

38

MCQeasy

Which admission controller is responsible for validating and modifying images based on an external webhook in Kubernetes?

A.MutatingAdmissionWebhook

B.ImagePolicyWebhook

C.PodSecurity

D.ValidatingAdmissionWebhook

AnswerB

ImagePolicyWebhook is specifically designed to enforce image policies.

Why this answer

ImagePolicyWebhook is the dedicated admission controller for image policy enforcement. The others serve different purposes.

Full explanation →

39

MCQeasy

Which field in a PodSecurityContext ensures that the container cannot gain privileges beyond its parent process?

A.privileged

B.readOnlyRootFilesystem

C.runAsNonRoot

D.allowPrivilegeEscalation

AnswerD

allowPrivilegeEscalation: false prevents the container from gaining more privileges than its parent process.

Full explanation →

40

MCQeasy

A DevOps team wants to ensure that all container images are pulled from a trusted registry only. Which cluster-level configuration should be applied?

A.Configure kubelet with --pod-manifest-path pointing to a whitelist

B.Enable PodSecurity with restricted profile

C.Use NetworkPolicy to block traffic to untrusted registries

D.Enable ImagePolicyWebhook admission controller

AnswerD

ImagePolicyWebhook can reject images from untrusted registries based on external policy.

Why this answer

Option D is correct because the ImagePolicyWebhook admission controller allows you to configure a cluster-level admission plugin that intercepts all Pod creation requests and validates the container images against an external webhook backend. This backend can enforce policies such as allowing only images from a trusted registry (e.g., `mytrustedregistry.io/*`), rejecting any image that does not match the whitelist. It operates at the API server level, ensuring that no Pod with an untrusted image can be created in the cluster.

Exam trap

CNCF often tests the distinction between admission controllers that validate image sources (ImagePolicyWebhook) versus those that enforce Pod security contexts (PodSecurity), leading candidates to mistakenly choose PodSecurity when the question is about registry trust.

How to eliminate wrong answers

Option A is wrong because `--pod-manifest-path` is used by the kubelet to load static Pods from a local directory, not to enforce registry whitelisting; it has no mechanism to validate image sources. Option B is wrong because PodSecurity (formerly PodSecurityPolicy) restricts Pod security contexts (e.g., privileged containers, host namespaces), not the registry from which images are pulled. Option C is wrong because NetworkPolicy controls network traffic at the IP/port level (Layer 3/4) and cannot inspect or block the source registry of container images; it cannot prevent a Pod from pulling an image from an untrusted registry.

Full explanation →

41

Multi-Selecteasy

Which TWO container sandboxing technologies are supported in Kubernetes via RuntimeClass? (Choose two)

Select 2 answers

A.gVisor (runsc)

B.Docker

C.containerd

D.runc

E.Kata Containers

AnswersA, E

gVisor provides a sandboxed container runtime and is supported via RuntimeClass.

Why this answer

gVisor and Kata Containers are sandboxed runtimes that provide additional isolation. They are configured via RuntimeClass in Kubernetes.

Full explanation →

42

MCQmedium

A container is running with the following securityContext: securityContext: capabilities: drop: ["ALL"] add: ["NET_BIND_SERVICE"] Which capabilities will the container have?

A.All capabilities except NET_BIND_SERVICE

B.Only NET_BIND_SERVICE

C.No capabilities

D.All default capabilities plus NET_BIND_SERVICE

AnswerB

Correct. Drop ALL removes all capabilities, then add NET_BIND_SERVICE adds it back.

Why this answer

Dropping ALL removes all capabilities, then adding NET_BIND_SERVICE gives only that one capability.

Full explanation →

43

MCQeasy

Which Linux capability should be dropped to prevent a container from gaining new privileges via setuid binaries?

A.CAP_NET_RAW

B.CAP_DAC_OVERRIDE

C.CAP_SETUID

D.CAP_SYS_ADMIN

AnswerC

CAP_SETUID allows changing user ID, which is required for setuid binaries to function.

Why this answer

CAP_SETUID (option C) is the Linux capability that controls whether a process can make arbitrary changes to process UIDs (setuid/setgid). Dropping this capability prevents a container from using setuid binaries (e.g., `su`, `sudo`) to escalate privileges, because the kernel will deny any attempt to change the effective UID. This directly addresses the requirement to prevent gaining new privileges via setuid binaries.

Exam trap

CNCF often tests the distinction between capabilities that control privilege escalation (CAP_SETUID) versus those that grant broad system access (CAP_SYS_ADMIN) or file permission bypass (CAP_DAC_OVERRIDE), leading candidates to pick the more familiar but incorrect option.

How to eliminate wrong answers

Option A (CAP_NET_RAW) is wrong because it controls the ability to use raw and packet sockets (e.g., for crafting custom packets or performing ARP spoofing), not privilege escalation via setuid binaries. Option B (CAP_DAC_OVERRIDE) is wrong because it allows bypassing discretionary access control (file permission checks), which could enable reading/writing arbitrary files but does not directly control the ability to execute setuid binaries to gain new privileges. Option D (CAP_SYS_ADMIN) is wrong because it is a broad capability that grants many system administration operations (e.g., mount, namespace manipulation), but it does not specifically govern the setuid mechanism; dropping it would not prevent a container from using setuid binaries to escalate privileges.

Full explanation →

44

MCQmedium

Which of the following is correct about dropping the 'NET_RAW' capability?

A.It prevents the container from binding to a privileged port (<1024)

B.It prevents the container from using the 'ping' command

C.It prevents the container from creating raw sockets, which can be used for packet crafting attacks

D.It prevents the container from making any network connections

AnswerC

Raw sockets (e.g., for ICMP) are blocked, reducing the attack surface.

Why this answer

The `NET_RAW` capability controls access to raw and packet sockets (AF_PACKET, SOCK_RAW). Dropping it prevents the container from creating raw sockets, which are often used for crafting custom packets, performing ARP spoofing, or launching other network-layer attacks. This is a key hardening measure to reduce the container's ability to manipulate network traffic at the low level.

Exam trap

CNCF often tests the misconception that 'ping' requires `NET_RAW`, but in modern Linux, ping can use a privileged datagram socket (ICMP_ECHO via SOCK_DGRAM) or setuid, so dropping `NET_RAW` does not always break ping.

How to eliminate wrong answers

Option A is wrong because binding to a privileged port (<1024) is controlled by the `CAP_NET_BIND_SERVICE` capability, not `NET_RAW`. Option B is wrong because the `ping` command typically uses ICMP echo requests, which can be sent via a datagram socket (SOCK_DGRAM) or raw socket; on many systems, ping falls back to a privileged datagram socket, so dropping `NET_RAW` does not necessarily prevent ping from working. Option D is wrong because dropping `NET_RAW` does not affect standard TCP/UDP connections; those use socket types (SOCK_STREAM, SOCK_DGRAM) that are governed by other capabilities like `CAP_NET_ADMIN` or `CAP_NET_RAW` only for raw sockets.

Full explanation →

45

MCQmedium

A security engineer runs the following command to inspect a container's security context. What vulnerability does this configuration expose?

A.The container is running without any capabilities

B.The container has all capabilities enabled, which is a security risk

C.The container has dropped all capabilities except NET_BIND_SERVICE

D.The container has default Docker capabilities, which is secure

AnswerB

Full capabilities allow many privileged operations, increasing attack surface.

Why this answer

The command `docker run --privileged` or a similar configuration that grants all capabilities (e.g., `--cap-add=ALL`) removes all kernel-level isolation, giving the container full access to the host's kernel capabilities. This means the container can perform privileged operations like loading kernel modules, modifying network settings, and accessing raw devices, which directly violates the principle of least privilege and exposes the host to container breakout attacks.

Exam trap

CNCF often tests the distinction between 'default Docker capabilities' (which are secure and limited) and 'all capabilities' (which is a severe vulnerability), and the trap here is that candidates may confuse 'all capabilities' with the default set or think that dropping all capabilities is the only insecure state.

How to eliminate wrong answers

Option A is wrong because the container is explicitly configured with all capabilities enabled, not running without any capabilities (which would be the case with `--cap-drop=ALL`). Option C is wrong because the configuration grants all capabilities, not a minimal set like only `NET_BIND_SERVICE`; dropping all but one capability would be a secure practice, not a vulnerability. Option D is wrong because default Docker capabilities (a restricted set like `CHOWN`, `DAC_OVERRIDE`, `FSETID`, `FOWNER`, `MKNOD`, `NET_RAW`, `SETGID`, `SETUID`, `SETFCAP`, `SETPCAP`, `NET_BIND_SERVICE`, `SYS_CHROOT`, `KILL`, `AUDIT_WRITE`) are considered secure for most workloads, but this configuration explicitly grants all capabilities, which is far less restrictive and insecure.

Full explanation →

46

MCQhard

A cluster uses ImagePolicyWebhook admission controller. After configuring it, deployments referencing images from an unauthorized registry are blocked. However, some deployments are still being admitted. What is a possible cause?

A.The ImagePolicyWebhook is configured with a low timeout

B.The registry is allowlisted in the webhook configuration

C.The admission controller is disabled

D.The ImagePolicyWebhook is placed after mutating admission webhooks in the admission chain

AnswerD

If mutating webhooks change the image reference, the ImagePolicyWebhook might evaluate a different image.

Why this answer

The ImagePolicyWebhook must be invoked before mutating webhooks to evaluate the image policy. If it runs after mutating webhooks that change the image reference, the policy may not see the original unauthorized image.

Full explanation →

47

MCQhard

An administrator wants to use AppArmor to confine a container. They have loaded a profile named 'my-custom-profile' using apparmor_parser. Which annotation should be added to the pod to enforce this profile?

A.container.apparmor.kubernetes.io/<container_name>: localhost/my-custom-profile

B.apparmor.security.beta.kubernetes.io/<container_name>: my-custom-profile

C.container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/my-custom-profile

D.container.apparmor.security.beta.kubernetes.io/my-custom-profile: enforce

AnswerC

Correct format: key is container name, value is 'localhost/' followed by profile name.

Why this answer

Option C is correct because the AppArmor annotation for pods follows the format `container.apparmor.security.beta.kubernetes.io/<container_name>` with the value `localhost/<profile_name>`. The `localhost/` prefix is required to indicate that the profile is loaded locally on the node, not a built-in or Kubernetes-managed profile. This annotation enforces the loaded 'my-custom-profile' on the specified container.

Exam trap

CNCF often tests the exact annotation key format and the necessity of the `localhost/` prefix, leading candidates to omit the `container.` prefix or the `localhost/` value, or to confuse the annotation structure with other security contexts like seccomp or SELinux.

How to eliminate wrong answers

Option A is wrong because the annotation prefix is `container.apparmor.security.beta.kubernetes.io/`, not `container.apparmor.kubernetes.io/` — the latter is not a valid Kubernetes annotation key for AppArmor. Option B is wrong because the annotation key is missing the `container.` prefix and the value is missing the `localhost/` prefix; the correct value must be `localhost/my-custom-profile`, not just `my-custom-profile`. Option D is wrong because the annotation key incorrectly places the profile name in the key itself and uses `enforce` as the value; the correct format uses the container name in the key and `localhost/<profile_name>` as the value.

Full explanation →

48

MCQmedium

You need to ensure that the kubelet only serves authenticated and authorized requests. Which flag(s) should be set on the kubelet?

A.--anonymous-auth=false and --authorization-mode=AlwaysAllow

B.--anonymous-auth=true and --authorization-mode=Webhook

C.--authenticated=true and --authorization=RBAC

D.--anonymous-auth=false and --authorization-mode=Webhook

AnswerD

These flags disable anonymous access and use webhook authorization via the API server.

Why this answer

Option D is correct because setting `--anonymous-auth=false` disallows unauthenticated requests to the kubelet, and `--authorization-mode=Webhook` delegates authorization decisions to an external service (e.g., the API server's SubjectAccessReview), ensuring that only authenticated and authorized requests are served. This combination enforces both authentication and authorization, which is required for hardening the kubelet.

Exam trap

CNCF often tests the misconception that `--authorization-mode=RBAC` is a valid kubelet flag, but the kubelet only supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny` for authorization, and RBAC is configured on the API server, not directly on the kubelet.

How to eliminate wrong answers

Option A is wrong because `--authorization-mode=AlwaysAllow` bypasses all authorization checks, allowing any authenticated request to proceed, which violates the requirement to serve only authorized requests. Option B is wrong because `--anonymous-auth=true` allows unauthenticated requests, which directly contradicts the need to serve only authenticated requests. Option C is wrong because `--authenticated` is not a valid kubelet flag; the correct flag is `--anonymous-auth`, and `--authorization=RBAC` is not a valid flag (the correct flag is `--authorization-mode` and RBAC is not a supported mode for the kubelet; the kubelet supports `AlwaysAllow`, `Webhook`, and `AlwaysDeny`).

Full explanation →

49

MCQeasy

What is the primary benefit of using external secret managers (e.g., HashiCorp Vault) in Kubernetes?

A.They ensure that secrets are never stored in etcd

B.They prevent all unauthorized access to secrets

C.They provide better control over secret rotation, auditing, and access policies

D.They eliminate the need for Kubernetes Secrets entirely

AnswerC

External secret managers offer advanced features like automatic rotation and detailed audit logs.

Why this answer

Option B is correct. External secret managers provide centralized secret management, rotation, and auditing. Option A is wrong because secrets are still stored in etcd unless encrypted.

Option C is wrong because secrets are still accessible if RBAC is misconfigured. Option D is wrong because secrets can still be used by pods.

Full explanation →

50

MCQeasy

What is the purpose of the 'seccomp' feature in Kubernetes?

A.To restrict file system access for a container

B.To restrict the system calls a container can make

C.To restrict the Linux capabilities a container can use

D.To restrict network access for a container

AnswerB

Seccomp filters syscalls.

Why this answer

Seccomp (secure computing mode) is a Linux kernel feature that allows a process to specify a filter for the system calls it can make. In Kubernetes, seccomp profiles can be applied to pods or containers to restrict the allowed syscalls, reducing the kernel attack surface. This is a key mechanism for container runtime security, distinct from filesystem, capability, or network controls.

Exam trap

CNCF often tests the distinction between seccomp (syscall filtering) and Linux capabilities (privilege granularity), so candidates may confuse restricting capabilities with restricting syscalls.

How to eliminate wrong answers

Option A is wrong because restricting file system access is achieved via read-only root filesystems, securityContext with readOnlyRootFilesystem, or AppArmor/SELinux profiles, not seccomp. Option C is wrong because restricting Linux capabilities is done via the 'capabilities' field in securityContext (e.g., drop: ALL), while seccomp filters syscalls at a lower level. Option D is wrong because restricting network access is managed by NetworkPolicies, not seccomp.

Full explanation →

51

MCQmedium

You are writing a Falco rule to detect when a container tries to read /etc/shadow. Which condition should you use?

A.fd.name=/etc/shadow and container.id != host

B.fd.name=/etc/passwd

C.container.id != host

D.fd.name=/etc/shadow

AnswerA

Correct: This targets containers accessing the shadow file.

Why this answer

The condition 'fd.name=/etc/shadow and container.id != host' ensures the file accessed is /etc/shadow and it's from a container (not the host). Option A misses the container check, option C is for /etc/passwd, option D is incomplete.

Full explanation →

52

MCQhard

A cluster has been configured with the NodeRestriction admission plugin. A developer tries to create a pod that uses a hostPath volume pointing to /var/log. The pod's nodeSelector is set to 'kubernetes.io/hostname: worker-1'. Which statement is true?

A.The pod will be created only if the node label matches the nodeSelector; the hostPath volume is irrelevant.

B.The pod will be rejected because hostPath volumes are not allowed by NodeRestriction.

C.The pod will be created because NodeRestriction does not restrict hostPath volumes.

D.The pod will be rejected because the nodeSelector conflicts with the NodeRestriction plugin.

AnswerC

NodeRestriction only restricts node self-updates, not hostPath.

Why this answer

The NodeRestriction admission plugin limits the node labels that a kubelet can set and restricts pods from modifying their node affinity to gain access to node-specific resources. However, it does not restrict the use of hostPath volumes. Therefore, a pod with a hostPath volume pointing to /var/log and a nodeSelector for 'worker-1' will be created, as long as the nodeSelector matches an existing node label and the hostPath volume is otherwise permitted by the PodSecurityPolicy or other security contexts.

Exam trap

The trap here is that candidates often confuse NodeRestriction with other admission plugins like PodSecurityPolicy or think it enforces broad security restrictions, when in fact it only targets node label and kubelet certificate behavior.

How to eliminate wrong answers

Option A is wrong because the hostPath volume is relevant: it must be allowed by the cluster's security policies (e.g., PodSecurityPolicy, OPA), but NodeRestriction does not block it. Option B is wrong because NodeRestriction does not restrict hostPath volumes; it only restricts node label modifications and kubelet self-approval of certificates. Option D is wrong because nodeSelector does not conflict with NodeRestriction; NodeRestriction does not evaluate nodeSelector values for conflicts.

Full explanation →

53

MCQeasy

Which tool is used to generate an SBOM (Software Bill of Materials) for a container image?

A.Clair

B.Kubesec

C.Trivy

D.Syft

AnswerD

Syft generates SBOMs from container images.

Why this answer

Syft is a CLI tool to generate SBOMs from container images and filesystems. Cosign attest can also include SBOMs but syft is specifically for generation.

Full explanation →

54

MCQhard

A cluster has a ValidatingWebhookConfiguration that intercepts Pod CREATE requests. The webhook server is unavailable. What happens when a user tries to create a pod?

A.The webhook is automatically disabled

B.The API server crashes

C.The pod creation is rejected until the webhook becomes available

D.The pod is created without webhook validation

AnswerC

Default failurePolicy is Fail, so the API server rejects the request.

Why this answer

By default, if a webhook is unreachable, the API server fails closed (rejects the request) unless the failurePolicy is set to Ignore. The default failurePolicy is Fail.

Full explanation →

55

MCQhard

You have enabled etcd encryption at rest using an EncryptionConfiguration with aescbc provider. After applying the configuration, you create a new Secret. Which of the following is true regarding the encrypted Secret?

A.All Secrets are encrypted because the EncryptionConfiguration applies to all resources.

B.All Secrets in the cluster, including existing ones, are immediately encrypted.

C.Only the new Secret is encrypted; existing Secrets remain in plaintext.

D.The new Secret is stored in plaintext because aescbc is not a valid provider.

AnswerC

Encryption applies to writes; existing data is not re-encrypted without manual intervention.

Why this answer

When you apply an EncryptionConfiguration with aescbc provider, only newly created Secrets are encrypted at rest. Existing Secrets remain in plaintext because encryption is applied at write time; the API server does not retroactively re-encrypt data already stored in etcd. This is why option C is correct.

Exam trap

The trap here is that candidates assume encryption is applied retroactively to all existing data, but Kubernetes only encrypts data at write time, so existing Secrets remain unencrypted until they are updated or re-created.

How to eliminate wrong answers

Option A is wrong because the EncryptionConfiguration applies only to the resources listed in its `resources` field, not to all resources by default. Option B is wrong because etcd encryption is not retroactive; existing Secrets are not automatically re-encrypted when the configuration is applied. Option D is wrong because aescbc is a valid provider in Kubernetes (AES-CBC with PKCS#7 padding) and is commonly used for encryption at rest.

Full explanation →

56

MCQeasy

Which flag must be set on the kube-apiserver to disable anonymous authentication?

A.--anonymous-auth-enabled=false

B.--disable-anonymous-auth

C.--enable-anonymous-auth=false

D.--anonymous-auth=false

AnswerD

Correct. Setting --anonymous-auth=false prevents anonymous requests.

Why this answer

The correct flag to disable anonymous authentication on the kube-apiserver is `--anonymous-auth=false`. This flag explicitly sets the anonymous authentication mode to disabled, preventing unauthenticated requests from being processed. The kube-apiserver uses this boolean flag to control whether anonymous requests (those with no authentication credentials) are allowed, and setting it to `false` disables them entirely.

Exam trap

The trap here is that candidates often confuse the flag name with common patterns like `--enabled` or `--disable-` prefixes, but the kube-apiserver uses a simple boolean flag `--anonymous-auth` that must be set to `false` to disable anonymous access.

How to eliminate wrong answers

Option A is wrong because `--anonymous-auth-enabled=false` is not a valid kube-apiserver flag; the correct flag name is `--anonymous-auth`, not `--anonymous-auth-enabled`. Option B is wrong because `--disable-anonymous-auth` is not a recognized kube-apiserver flag; the kube-apiserver uses a boolean flag `--anonymous-auth` rather than a disable prefix. Option C is wrong because `--enable-anonymous-auth=false` is also not a valid flag; the kube-apiserver does not use an `--enable-` prefix for this setting, and the correct flag is simply `--anonymous-auth`.

Full explanation →

57

MCQeasy

Which kubectl command runs kube-bench against a Kubernetes cluster?

A.kubectl benchmark

B.kube-bench run

C.kube-bench scan

D.kubectl run kube-bench

AnswerB

The correct command to execute kube-bench is 'kube-bench run'. It runs the CIS benchmark checks and outputs results.

Why this answer

Option B is correct because `kube-bench run` is the actual command syntax for executing kube-bench, a CIS Kubernetes Benchmark assessment tool. Kube-bench is a standalone binary, not a kubectl subcommand, and it runs checks against the cluster's configuration files and processes. The `run` subcommand triggers the benchmark evaluation.

Exam trap

CNCF often tests the distinction between kubectl commands and standalone security tools like kube-bench, trapping candidates who assume all security tasks are performed via kubectl subcommands.

How to eliminate wrong answers

Option A is wrong because `kubectl benchmark` is not a valid kubectl command; kubectl has no built-in benchmark subcommand. Option C is wrong because `kube-bench scan` is not a valid subcommand; kube-bench uses `run` to execute the benchmark, not `scan`. Option D is wrong because `kubectl run kube-bench` would attempt to run a pod named 'kube-bench' using a container image, not execute the kube-bench binary directly against the host's configuration files.

Full explanation →

58

Multi-Selectmedium

Which TWO are best practices for Dockerfile security? (Select 2)

Select 2 answers

A.Use a non-root user

B.Use a minimal base image (distroless)

C.Store secrets in environment variables

D.Install SSH server for debugging

E.Run the container as root

AnswersA, B

Running as non-root limits the impact of a breach.

Why this answer

Using a non-root user reduces the attack surface if the container is compromised. Using a minimal base image like distroless reduces the number of packages and potential vulnerabilities.

Full explanation →

59

Multi-Selectmedium

Which TWO of the following are correct about container sandboxing technologies? (Select TWO)

Select 2 answers

A.Kata Containers run containers in lightweight VMs, providing hardware-level isolation.

B.gVisor provides a kernel-level sandbox by implementing a user-space kernel.

C.Kata Containers use the host kernel for system calls.

D.gVisor runs containers in separate VMs for each pod.

E.Both gVisor and Kata Containers require RuntimeClass to be used in Kubernetes.

AnswersA, B

Kata Containers use VMs for stronger isolation.

Full explanation →

60

MCQmedium

Which of the following OPA Gatekeeper Rego policies would deny a pod that sets `securityContext.runAsUser: 0`?

A.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.capabilities.drop == "ALL" }

B.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.securityContext.runAsUser == 0 }

C.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsUser == 0 }

D.violation[{"msg": "Running as root is not allowed"}] { input.review.object.spec.containers[_].securityContext.runAsNonRoot == true }

AnswerC

This correctly denies pods with runAsUser=0.

Why this answer

The correct Rego policy denies pods with `runAsUser: 0` because that runs as root. Option A correctly checks for the field and denies if it is 0.

Full explanation →

61

MCQeasy

A developer wants to run a container that needs to modify kernel parameters. What is the secure way to achieve this?

A.Run the container with privileged: true

B.Add SYS_ADMIN capability to the container

C.Use allowedUnsafeSysctls in pod securityContext for safe sysctls like net.ipv4.tcp_syncookies

D.Modify kubelet's --sysctl-whitelist to include the needed sysctl

AnswerC

Namespaced sysctls can be set without full privileges if allowed by the cluster.

Why this answer

Option C is correct because Kubernetes provides a secure mechanism to modify kernel parameters via `allowedUnsafeSysctls` in the Pod's `securityContext`. This approach allows specific sysctls (e.g., `net.ipv4.tcp_syncookies`) to be set without granting full privileged access or dangerous capabilities. It ensures that only explicitly whitelisted sysctls are permitted, reducing the attack surface while meeting the developer's requirement.

Exam trap

CNCF often tests the misconception that `SYS_ADMIN` capability is the minimal privilege needed for sysctl modifications, but in reality, it grants far more power than necessary, and the correct secure approach is to use `allowedUnsafeSysctls` in the Pod's security context.

How to eliminate wrong answers

Option A is wrong because running a container with `privileged: true` grants all capabilities and disables all security restrictions, which is excessive and insecure for modifying only kernel parameters. Option B is wrong because adding `SYS_ADMIN` capability grants broad administrative privileges (e.g., namespace manipulation, filesystem operations) beyond just modifying sysctls, violating the principle of least privilege. Option D is wrong because modifying the kubelet's `--sysctl-whitelist` is a deprecated and insecure approach; it applies globally to all pods on the node and does not provide per-pod granular control, unlike the Pod-level `allowedUnsafeSysctls` field.

Full explanation →

62

MCQmedium

What is the purpose of the Kubernetes Dashboard?

A.To provide a command-line interface for cluster management

B.To provide a web-based user interface for deploying and managing applications

C.To monitor cluster performance metrics

D.To enforce security policies on the cluster

AnswerB

The Dashboard allows users to manage applications, view logs, and more via a GUI.

Why this answer

The Kubernetes Dashboard is a web-based user interface that allows users to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster resources. It provides a graphical alternative to the kubectl command-line tool, enabling operations such as viewing workloads, scaling deployments, and editing resources through a browser.

Exam trap

CNCF often tests the misconception that the Dashboard is a monitoring or security tool, but the CKS exam emphasizes that its role is purely a web UI for cluster management, and that security enforcement is the job of admission controllers and RBAC, not the Dashboard itself.

How to eliminate wrong answers

Option A is wrong because the command-line interface for cluster management is provided by kubectl, not the Dashboard. Option C is wrong because while the Dashboard can display some basic metrics (like CPU/memory usage) via integrations like metrics-server, its primary purpose is not performance monitoring; dedicated tools like Prometheus and Grafana are used for comprehensive cluster monitoring. Option D is wrong because security policies (e.g., Pod Security Standards, RBAC, NetworkPolicies) are enforced by the Kubernetes API server and admission controllers, not by the Dashboard; the Dashboard itself is subject to those policies.

Full explanation →

63

MCQhard

You are auditing RBAC and find a ClusterRoleBinding that grants cluster-admin to a service account. Which command should you run to list all ClusterRoleBindings in the cluster?

A.kubectl get clusterrolebinding

B.kubectl get clusterrolebindings

C.kubectl get clusterrolebindings.rbac.authorization.k8s.io

D.kubectl get clusterrolebinding --all-namespaces

AnswerB, C

This is the standard command to list ClusterRoleBindings.

Why this answer

The correct command to list all ClusterRoleBindings in the cluster is `kubectl get clusterrolebindings` (option B). This uses the standard plural form of the resource name, which is the default and recommended way to query RBAC resources. The command retrieves all ClusterRoleBindings across the cluster, as ClusterRoleBindings are non-namespaced resources.

Exam trap

The trap here is that candidates may think `--all-namespaces` is needed for cluster-scoped resources, but it is only applicable to namespaced resources, and using the singular form `clusterrolebinding` will cause an error.

How to eliminate wrong answers

Option A is wrong because `kubectl get clusterrolebinding` uses the singular form, which is not a valid kubectl resource name; kubectl requires the plural form to list resources. Option D is wrong because `--all-namespaces` is redundant for ClusterRoleBindings, as they are cluster-scoped resources and not bound to any namespace; the flag has no effect and is misleading. Option C is also marked as correct in the question, but the prompt asks for the single correct answer; however, `kubectl get clusterrolebindings.rbac.authorization.k8s.io` is technically valid as it uses the fully qualified resource name, but the simpler plural form is the standard and expected answer.

Full explanation →

64

MCQeasy

Which kubectl command will disable anonymous authentication on a kube-apiserver?

A.kubectl edit pod kube-apiserver -n kube-system and add --anonymous-auth=false

B.kubectl run --image=k8s.gcr.io/kube-apiserver --env=ANONYMOUS_AUTH=false

C.kubectl patch node <nodename> -p '{"spec":{"anonymousAuth":false}}'

D.kubectl set env deployment/kube-apiserver -n kube-system ANONYMOUS_AUTH=false

AnswerA

This command allows editing the kube-apiserver pod to set the flag.

Why this answer

Option A is correct because the kube-apiserver is a static pod managed by the kubelet, and its configuration is defined in a manifest file located in /etc/kubernetes/manifests/ on the control-plane node. Editing the pod directly with `kubectl edit pod kube-apiserver -n kube-system` allows you to add the `--anonymous-auth=false` flag to the kube-apiserver command, which disables anonymous authentication by rejecting requests from unauthenticated users. This change is automatically applied by the kubelet, which restarts the static pod with the updated configuration.

Exam trap

CNCF often tests the misconception that the kube-apiserver can be configured via environment variables or that it runs as a Deployment, when in fact it is a static pod configured solely through command-line arguments in its manifest file.

How to eliminate wrong answers

Option B is wrong because `kubectl run` creates a new pod from an image, not modify the existing kube-apiserver static pod, and environment variables like `ANONYMOUS_AUTH=false` are not recognized by the kube-apiserver binary (it uses command-line flags, not env vars). Option C is wrong because `kubectl patch node` modifies the Node object's spec, but the kube-apiserver's authentication settings are not part of the Node spec; the `anonymousAuth` field does not exist in the Node API. Option D is wrong because `kubectl set env` sets environment variables on a Deployment, but the kube-apiserver is a static pod, not a Deployment, and the kube-apiserver does not read authentication settings from environment variables.

Full explanation →

65

MCQmedium

A pod uses a Secret mounted as a volume. The Secret is updated. How can the pod consume the updated values without restarting?

A.Use a sidecar container that watches for changes and reloads the application

B.Update the pod spec to reference a new Secret version

C.The mounted volume is automatically updated over time

D.Delete and recreate the pod

AnswerC

When using subPath or projected volumes, updates may not propagate automatically. But for regular volume mounts, the contents are updated periodically.

Why this answer

Kubernetes automatically updates the mounted files when the Secret is updated, but this is not instantaneous and may take some time. However, the question asks for a way without restarting; the answer is that it is automatic, but for an alternative approach, using a sidecar that watches for changes is also valid. Option C (automatic refresh) is the simplest correct answer.

Full explanation →

66

MCQeasy

Which Kubernetes admission controller ensures that a pod only uses images from a specific registry?

A.NamespaceLifecycle

B.ImagePolicyWebhook

C.PodNodeSelector

D.AlwaysPullImages

AnswerB

ImagePolicyWebhook can enforce policies on image registry and more.

Why this answer

The ImagePolicyWebhook admission controller can be configured to allow or deny images based on registry, via an external webhook.

Full explanation →

67

MCQmedium

You have configured an audit policy with level: Request. Which request information is logged?

A.Only metadata for the request

B.Nothing is logged because Request is not a valid level

C.Request metadata and request body

D.Request metadata, request body, and response body

AnswerC

Correct. Request level includes metadata plus the request body.

Why this answer

The Request level logs request metadata and request body. This is more detailed than Metadata but less than RequestResponse.

Full explanation →

68

MCQmedium

During a security audit, it is found that containers running in a cluster have CAP_NET_RAW capability by default. The team wants to drop this capability for all containers. Which approach should be taken?

A.Use a mutating admission webhook to add a finalizer that drops capabilities

B.Create a PodSecurityPolicy with requiredDropCapabilities: [NET_RAW] and assign it to a role binding

C.Configure kubelet with --allowed-unsafe-sysctls to restrict capabilities

D.Modify each deployment to include securityContext.capabilities.drop: [NET_RAW]

AnswerB

PSP (or PSA) enforces the drop for all pods in the cluster.

Why this answer

Option B is correct because PodSecurityPolicy (PSP) is the native Kubernetes mechanism to enforce cluster-wide security constraints, including dropping specific capabilities like NET_RAW. By defining a PSP with `requiredDropCapabilities: [NET_RAW]` and binding it to a role via RoleBinding or ClusterRoleBinding, all containers in the cluster will automatically have that capability removed, ensuring consistent enforcement without modifying individual workloads.

Exam trap

The trap here is that candidates confuse PodSecurityPolicy with deprecated or alternative mechanisms (like manual deployment edits or unrelated kubelet flags), or mistakenly think a mutating webhook with a finalizer can alter security contexts, when in fact finalizers serve a completely different purpose in Kubernetes lifecycle management.

How to eliminate wrong answers

Option A is wrong because a mutating admission webhook can modify pods, but adding a finalizer does not drop capabilities; finalizers are used for cleanup logic before deletion, not for security context modifications. Option C is wrong because `--allowed-unsafe-sysctls` on the kubelet controls which unsafe sysctls are permitted, not capabilities; capabilities are managed via the container runtime and security context, not sysctl settings. Option D is wrong because modifying each deployment manually is not a scalable or auditable approach for cluster-wide enforcement; it violates the principle of centralized security policy and is error-prone in large environments.

Full explanation →

69

MCQmedium

An admin has deployed a ValidatingWebhookConfiguration that denies pods with `runAsNonRoot: false`. After creating a pod that does not set `runAsNonRoot` at all, the pod is created successfully. Why did the webhook not deny it?

A.The webhook configuration's rules do not match the pod create operation

B.The webhook's failure policy is set to Ignore

C.The webhook is only applied to pods in a specific namespace

D.The webhook only applies to pods created with a specific service account

AnswerA

If the rules do not include pods or the create operation, the webhook is not invoked.

Why this answer

Option C is correct. A ValidatingWebhookConfiguration must define `rules` with `apiGroups`, `apiVersions`, `operations`, and `resources` to match requests. If the rules do not match the pod creation request, the webhook is not called.

Option A is wrong because the webhook can be cluster-scoped. Option B is wrong because admission webhooks can be used with any pod. Option D is wrong because the webhook can have any failure policy.

Full explanation →

70

MCQeasy

An administrator needs to enforce that all pods in a namespace run with read-only root filesystem. Which Pod Security Standard should be applied?

A.Use a NetworkPolicy to restrict filesystem access

B.Run the pod with securityContext.readOnlyRootFilesystem: true

C.Set securityContext.runAsNonRoot: true

D.Set securityContext.allowPrivilegeEscalation: false

AnswerB

Setting readOnlyRootFilesystem: true in the security context makes the root filesystem read-only. This is a Pod-level setting.

Full explanation →

71

MCQmedium

Which kubectl command creates a Role named 'pod-reader' that allows only 'get', 'list', and 'watch' on pods in namespace 'ns1'?

A.kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

B.kubectl create role pod-reader --verb=get,list,watch --resource=pods --namespace=ns1

C.kubectl create role pod-reader --verb=* --resource=pods --namespace=ns1

D.kubectl create rolebinding pod-reader --role=pod-reader --serviceaccount=ns1:default

AnswerB

This command creates the role with specified verbs and resource.

Why this answer

Option B is correct because the `kubectl create role` command creates a Role (namespaced resource) with the specified verbs and resources in the given namespace. The `--verb=get,list,watch` and `--resource=pods` flags define the exact permissions, and `--namespace=ns1` scopes the Role to that namespace, which matches the requirement.

Exam trap

The trap here is that candidates often confuse `kubectl create role` with `kubectl create clusterrole` (option A) or mistakenly use `--verb=*` (option C) thinking it means 'only these verbs', when in fact it grants all verbs, violating the principle of least privilege.

How to eliminate wrong answers

Option A is wrong because `kubectl create clusterrole` creates a ClusterRole, which is cluster-scoped, not namespaced; it would grant permissions across all namespaces, not just 'ns1'. Option C is wrong because `--verb=*` grants all verbs (including create, update, delete, etc.), not just 'get', 'list', and 'watch'. Option D is wrong because `kubectl create rolebinding` creates a RoleBinding (binding a role to a subject), not a Role; it also references a role named 'pod-reader' that does not exist yet, and the command does not create the Role itself.

Full explanation →

72

MCQmedium

Which tool can be used to perform static analysis of Kubernetes manifests for security issues?

A.syft

B.cosign

C.kubesec

D.trivy

AnswerC

kubesec analyzes Kubernetes manifests for security issues.

Why this answer

kubesec evaluates Kubernetes resources against security best practices.

Full explanation →

73

MCQmedium

A security scan reports that the etcd cluster does not encrypt data at rest. The cluster uses aescbc encryption. Which resource type should be created to configure encryption at rest?

A.ConfigMap

B.ClusterRole

C.EncryptionConfiguration

D.Secret

AnswerC

EncryptionConfiguration is the correct resource to define encryption providers and keys.

Why this answer

The correct resource type is an EncryptionConfiguration, which is a Kubernetes API object used to configure encryption at rest for etcd. When the aescbc provider is specified in the EncryptionConfiguration, Kubernetes encrypts secret data before writing it to etcd, ensuring data at rest is protected. This configuration is passed to the kube-apiserver via the --encryption-provider-config flag.

Exam trap

The trap here is that candidates often confuse the resource that stores sensitive data (Secret) with the resource that configures encryption at rest (EncryptionConfiguration), or they mistakenly think a ConfigMap can define encryption settings because it holds configuration data.

How to eliminate wrong answers

Option A is wrong because a ConfigMap is used to store non-confidential configuration data as key-value pairs, not to define encryption providers or settings for etcd encryption at rest. Option B is wrong because a ClusterRole defines permissions for RBAC (Role-Based Access Control) and has no relation to configuring encryption providers for etcd. Option D is wrong because a Secret is used to store sensitive data like passwords or tokens, but it is not the resource that configures how etcd data is encrypted; the EncryptionConfiguration resource defines the encryption providers and keys.

Full explanation →

74

MCQmedium

An administrator runs 'kubectl run test-pod --image=nginx:latest' and the pod fails to start. The event log shows 'ImagePullBackOff' with error 'manifest for nginx:latest not found: manifest unknown'. The image 'nginx:latest' exists in the registry. What is the most likely cause?

A.The pod is running in a different namespace

B.The registry requires authentication

C.The image tag is misspelled or points to a non-existent tag

D.The image is a multi-architecture image and the node does not support the required architecture

AnswerC

'Manifest unknown' means the specific tag is not found. The user might have made a typo or the tag doesn't exist in the registry.

Why this answer

The 'manifest unknown' error indicates that the image tag does not exist in the repository. Even though 'nginx:latest' exists on Docker Hub, the registry in use may be a different one or the tag might be misspelled. Option A is the most likely.

Full explanation →

75

MCQhard

You are the security engineer for a multi-tenant Kubernetes cluster. The cluster uses kubeadm and runs Kubernetes v1.24. Each tenant has a dedicated namespace. A new tenant, 'acme-corp', requires that all pods in their namespace run with a read-only root filesystem and must not be able to escalate privileges. They also need to run a legacy container that must listen on a port below 1024. The cluster currently uses PodSecurityPolicy (PSP) but is planning to migrate to Pod Security Admission (PSA). The legacy container needs to run as non-root with the NET_BIND_SERVICE capability to bind to port 80. You need to configure security policies for the 'acme-corp' namespace without affecting other tenants. Which approach best meets these requirements while following Kubernetes best practices?

A.Enable Pod Security Admission with the 'baseline' policy in enforce mode for acme-corp namespace, and add a mutating webhook to set readOnlyRootFilesystem

B.Use OPA/Gatekeeper to create a ConstraintTemplate that requires readOnlyRootFilesystem and allows only NET_BIND_SERVICE capability, then apply it to acme-corp namespace

C.Use Pod Security Admission with the 'privileged' policy and rely on the legacy container's securityContext

D.Create a new PSP that allows NET_BIND_SERVICE and requires readOnlyRootFilesystem, then bind it to the acme-corp namespace via RoleBinding

AnswerB

OPA can enforce both requirements flexibly.

Why this answer

Option B is correct because OPA/Gatekeeper allows fine-grained, namespace-scoped policy enforcement that can require readOnlyRootFilesystem and restrict capabilities to only NET_BIND_SERVICE, meeting all requirements without affecting other tenants. Pod Security Admission (PSA) does not support custom capability restrictions or readOnlyRootFilesystem enforcement natively, and PSP is deprecated in Kubernetes v1.24 and being removed, making it unsuitable for new configurations. Gatekeeper’s ConstraintTemplate provides the flexibility to enforce these specific security contexts while following best practices for policy-as-code.

Exam trap

The trap here is that candidates may choose Pod Security Admission (PSA) because it is the newer, recommended replacement for PSP, but PSA lacks the granularity to enforce readOnlyRootFilesystem or restrict capabilities to a single capability like NET_BIND_SERVICE, leading to an incorrect choice like Option A or C.

How to eliminate wrong answers

Option A is wrong because Pod Security Admission (PSA) with the 'baseline' policy does not enforce readOnlyRootFilesystem or allow fine-grained capability control like only NET_BIND_SERVICE; it only restricts privileged containers and host namespaces, and a mutating webhook would be an additional, non-standard workaround. Option C is wrong because the 'privileged' policy in PSA allows all capabilities and privilege escalation, directly violating the requirement to prevent privilege escalation and enforce a read-only root filesystem. Option D is wrong because PodSecurityPolicy (PSP) is deprecated in Kubernetes v1.24 and will be removed in v1.25, making it a non-compliant choice for new configurations; additionally, PSPs are cluster-scoped and binding them via RoleBinding to a namespace is not the intended mechanism (they require PSP-specific RBAC bindings).

Full explanation →

Page 1 of 14

All pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Practice CKS by domain

Target a specific domain to shore up weak areas.

Monitoring Logging and Runtime Security Cluster Setup and Hardening System Hardening Minimize Microservice Vulnerabilities Supply Chain Security Monitoring, Logging and Runtime Security Cluster Setup Cluster Hardening

See all domains with question counts →