Courseiva

Certified Kubernetes Security Specialist CKS (CKS) — Questions 976–997

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

Take a mock examExam hub
Page 13

Page 14 of 14

976
MCQhard

You are securing etcd. Which of the following is required to enable TLS client authentication for etcd?

A.Set --auto-tls to true
B.Set --peer-client-cert-auth to true
C.Use --cert-file and --key-file only
D.Set --client-cert-auth to true and provide --trusted-ca-file
AnswerD

These flags enable and configure client certificate authentication.

Why this answer

Option D is correct because etcd requires `--client-cert-auth=true` to enforce TLS client certificate authentication for incoming client requests, and `--trusted-ca-file` must be provided to specify the CA certificate used to validate client certificates. Without both, client certificate authentication is not enabled.

Exam trap

The trap here is that candidates confuse `--peer-client-cert-auth` (for inter-node communication) with `--client-cert-auth` (for client-to-server communication), leading them to select option B instead of D.

How to eliminate wrong answers

Option A is wrong because `--auto-tls` enables self-signed TLS for peer and client connections but does not enforce client certificate authentication; it is intended for development or testing, not secure production use. Option B is wrong because `--peer-client-cert-auth` enables client certificate authentication for peer-to-peer communication between etcd members, not for client connections to the etcd API. Option C is wrong because `--cert-file` and `--key-file` only configure the server certificate for TLS, but without `--client-cert-auth=true` and `--trusted-ca-file`, the server will not request or validate client certificates.

Full explanation →
977
Multi-Selecthard

Which THREE of the following are valid flags for enabling admission plugins on the API server?

Select 3 answers
A.--enable-admission-plugins=AlwaysPullImages
B.--enable-admission-plugins=PodSecurity,NodeRestriction
C.--plugin-dir=/admission
D.--enable-admission-plugins=NodeRestriction
E.--admission-control=NodeRestriction
AnswersA, B, D

AlwaysPullImages is a valid admission plugin.

Why this answer

Option A is correct because `--enable-admission-plugins=AlwaysPullImages` is the valid flag to enable the AlwaysPullImages admission plugin on the kube-apiserver. This flag accepts a comma-separated list of plugin names, and AlwaysPullImages is a built-in admission controller that forces every new Pod to pull images again, even if they already exist on the node, enhancing security by ensuring only authorized images are used.

Exam trap

CNCF often tests the distinction between the deprecated `--admission-control` flag and the current `--enable-admission-plugins` flag, as well as the difference between built-in plugin flags and plugin directory flags, to catch candidates who rely on outdated knowledge or confuse configuration parameters.

Full explanation →
978
MCQmedium

An administrator runs `kubectl exec -it nginx-pod -- sh` and inside the container runs `curl http://example.com`. This succeeds. However, the administrator wants to detect such outbound connections using Falco. Which syscall should Falco monitor to detect this network connection?

A.open
B.connect
C.execve
D.bind
AnswerB

The connect syscall is used to initiate a connection to a remote socket, making it appropriate for detecting outbound connections.

Why this answer

Falco monitors system calls. Establishing an outbound TCP connection involves the `connect` syscall. Other syscalls like `open`, `execve`, `bind` are not directly related to initiating outbound connections.

Full explanation →
979
MCQhard

An etcd cluster is configured with TLS. You need to enforce that only the API server can read and write to etcd. Which method should you use?

A.Configure etcd RBAC with a role that grants readwrite access only to the API server's client certificate CN
B.Set etcd's --peer-client-cert-auth flag to true
C.Set etcd's --client-cert-auth flag to false
D.Use a NetworkPolicy to restrict access to etcd port 2379
AnswerA

Correct. etcd RBAC can restrict access based on client certificate CN.

Why this answer

Option A is correct because etcd supports Role-Based Access Control (RBAC) that can restrict access based on the Common Name (CN) in the client certificate. By creating a role with readwrite access and binding it only to the API server's client certificate CN, you ensure that only the API server can read and write to etcd, while other clients are denied.

Exam trap

CNCF often tests the distinction between client-to-etcd authentication (--client-cert-auth) and peer-to-peer authentication (--peer-client-cert-auth), and candidates may confuse the two or think disabling client-cert-auth improves security, when it actually opens access.

How to eliminate wrong answers

Option B is wrong because --peer-client-cert-auth enables client certificate authentication for peer-to-peer communication between etcd members, not for client-to-etcd access, so it does not restrict API server access. Option C is wrong because setting --client-cert-auth to false disables client certificate authentication entirely, allowing any client to connect, which is the opposite of enforcing access control. Option D is wrong because a NetworkPolicy can restrict network-level access to port 2379, but it cannot enforce certificate-based identity; it would block all traffic including legitimate API server traffic if misconfigured, and does not provide the granularity of CN-based authorization.

Full explanation →
980
MCQmedium

A security team wants to ensure that only container images from a trusted registry (mytrustedregistry.io) are deployed in the cluster. They plan to use OPA/Gatekeeper. Which kind of Gatekeeper constraint template and constraint should they create?

A.A constraint that uses a pattern to match the image field against allowed registries
B.A constraint that validates the cluster's registry mirror configuration
C.A constraint that inspects the image field in the Pod's metadata annotations
D.A constraint that checks the imagePullSecrets field in the Pod spec
AnswerA

By matching the 'image' field in containers, you can ensure only images from trusted registries are used.

Why this answer

Option B is correct. A K8sAllowedRegions constraint template on the spec.containers[*].image field can enforce that image names match a specific registry. Option A is too broad.

Option C uses an incorrect field. Option D targets an irrelevant field.

Full explanation →
981
MCQhard

A pod is scheduled on a node that has the AppArmor profile 'my-profile' loaded in complain mode. The pod annotation specifies 'localhost/my-profile' but the container is running without the profile being enforced. What is the most likely cause?

A.The pod must run as privileged to use AppArmor
B.The annotation is missing the 'localhost/' prefix
C.The profile is in complain mode, not enforce mode
D.The profile is not loaded on the node
AnswerC

In complain mode, AppArmor allows all actions and only logs violations; it does not enforce restrictions.

Why this answer

Option C is correct because AppArmor profiles can operate in either 'enforce' or 'complain' mode. When a profile is loaded in complain mode, violations are logged but not blocked, so the container runs without enforcement. The pod annotation 'localhost/my-profile' correctly references the profile, but the profile itself is not set to enforce mode, which is why the container is running without the profile being enforced.

Exam trap

CNCF often tests the distinction between 'complain' and 'enforce' modes, where candidates mistakenly assume that a loaded profile always enforces restrictions, ignoring that complain mode only logs violations without blocking them.

How to eliminate wrong answers

Option A is wrong because AppArmor does not require the pod to run as privileged; it works with standard containers and enforces profiles at the kernel level via LSM hooks. Option B is wrong because the annotation 'localhost/my-profile' already includes the 'localhost/' prefix, which is the correct format for referencing a locally loaded profile. Option D is wrong because the question explicitly states the profile 'my-profile' is loaded on the node in complain mode, so it is present and not missing.

Full explanation →
982
MCQhard

A developer asks you to run a container with gVisor runtime. The cluster has a RuntimeClass named 'gvisor' defined. Which field must be added to the Pod spec to use gVisor?

A.spec.containers[0].runtimeClassName: gvisor
B.metadata.runtimeClassName: gvisor
C.spec.runtimeClass: gvisor
D.spec.runtimeClassName: gvisor
AnswerD

Correct.

Why this answer

The 'runtimeClassName' field in the Pod spec selects the RuntimeClass.

Full explanation →
983
MCQhard

Which Istio resource is used to enforce mutual TLS (mTLS) for all services in a namespace, ensuring that traffic between services is encrypted?

A.DestinationRule
B.PeerAuthentication
C.ServiceEntry
D.VirtualService
AnswerB

PeerAuthentication defines mTLS settings for workloads in a namespace. Setting mode: STRICT enforces mTLS.

Why this answer

PeerAuthentication defines the traffic policy for mTLS within a namespace. Setting `mode: STRICT` enforces mTLS for all services in the namespace.

Full explanation →
984
Matchingmedium

Match each Kubernetes object or feature to its primary security purpose.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Provides an identity for processes running in a pod

Stores sensitive data such as passwords, OAuth tokens, and ssh keys

Stores non-sensitive configuration data in key-value pairs

Specifies security settings for a pod or container

Limits resource consumption per namespace to prevent resource exhaustion

Why these pairings

These objects are essential for managing security and resource constraints.

Full explanation →
985
Multi-Selecthard

Which THREE of the following are recommended steps when responding to a compromised pod?

Select 3 answers
A.Immediately delete the pod to stop the attack
B.Scale the deployment replicas to zero to stop the pod
C.Run kubectl exec to investigate the container's state
D.Isolate the pod using a NetworkPolicy that denies all egress
E.Capture a snapshot of the container's filesystem using kubectl cp
AnswersB, D, E

Scaling to zero stops the pod without deleting it, preserving evidence.

Why this answer

Isolating the pod via NetworkPolicy, capturing a forensic snapshot (e.g., using kubectl cp), and scaling replicas to zero are all valid steps. Deleting the pod immediately may destroy evidence. Running commands inside the pod could alter state.

Full explanation →
986
MCQmedium

You are investigating a compromised pod. You need to capture the contents of a file in the container without modifying the container. Which kubectl command should you use?

A.kubectl logs <pod>
B.kubectl cp <pod>:/etc/passwd ./passwd
C.kubectl exec <pod> -- cat /etc/passwd
D.kubectl describe pod <pod>
AnswerB

kubectl cp copies the file from the container to the local machine without executing anything inside the container.

Why this answer

kubectl cp copies files/folders between a container and the local filesystem, allowing you to extract evidence without running commands inside the container.

Full explanation →
987
MCQhard

You have configured Kyverno to enforce that all Pods must have an image from a trusted registry. However, a newly created Pod is not being rejected even though it uses an untrusted image. What is the most likely reason?

A.Kyverno is not an admission controller; it only mutates resources
B.The Kyverno policy requires an external registry to compare images, which is unavailable
C.The Kyverno webhook is not invoked because the failure policy is set to Ignore or the resource is not matched by the policy's rules
D.The Pod was created by a Deployment controller, which bypasses admission control
AnswerC

If the webhook's failure policy is 'Ignore', a failing webhook will not block the request. Also, the policy may not match the namespace or other criteria.

Why this answer

Option D is correct. Kyverno policies are implemented as a MutatingAdmissionWebhook or ValidatingAdmissionWebhook, and they must be properly configured with the correct failurePolicy and match conditions. If the webhook is not properly configured, the request may bypass the policy.

Option A is wrong because Kyverno uses webhooks, not the ImagePolicyWebhook. Option B is not specific to this issue. Option C is wrong because Kyverno can validate resources without an external registry.

Full explanation →
988
Matchingmedium

Match each container security context setting to its effect.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts
Matches

Prevents processes from gaining more privileges than their parent

Ensures the container runs with a user ID that is not 0 (root)

Mounts the container's root filesystem as read-only

Drops all Linux capabilities, minimizing kernel privileges

Disables privileged mode, preventing access to host devices

Why these pairings

These settings are used to enforce least privilege for containers.

Full explanation →
989
MCQhard

A pod running in the cluster is in a CrashLoopBackOff state. You run 'kubectl describe pod <pod>' and see the following event: 'Warning BackOff Back-off restarting failed container'. Which command would you run to see the standard error output of the container?

A.kubectl logs <pod> --previous
B.kubectl exec <pod> -- cat /var/log/syslog
C.kubectl describe pod <pod>
D.kubectl logs <pod>
AnswerA

Using --previous retrieves logs from the previous instance of the container, which is essential when the container is restarting due to a crash.

Why this answer

Option A is correct because `kubectl logs <pod> --previous` retrieves the logs from the previous instance of a crashed or restarting container. When a pod is in CrashLoopBackOff, the current container may have already restarted, so the standard error output from the failed run is only available in the previous container's logs. This command specifically fetches those logs, which typically contain the stderr output that caused the crash.

Exam trap

CNCF often tests the distinction between `kubectl logs <pod>` and `kubectl logs <pod> --previous`; the trap here is that candidates assume the current container's logs contain the crash information, but in a CrashLoopBackOff, the current container may have already restarted and its logs are empty or show only the restart loop, so the `--previous` flag is required to see the actual error output from the failed run.

How to eliminate wrong answers

Option B is wrong because `kubectl exec <pod> -- cat /var/log/syslog` attempts to run a command inside the currently running container, but in a CrashLoopBackOff state the container may not be running or may restart immediately, making exec unreliable; also, containerized applications often do not log to /var/log/syslog. Option C is wrong because `kubectl describe pod <pod>` shows events and metadata but does not display the container's standard error output; it only shows the back-off event already seen. Option D is wrong because `kubectl logs <pod>` fetches logs from the current (possibly restarted) container, which may be empty or show only the restart loop, not the stderr from the failed previous instance.

Full explanation →
990
Multi-Selecthard

Which THREE of the following are true about Kubernetes audit logging?

Select 2 answers
A.Audit logging can be enabled without restarting the API server
B.Audit stages include 'RequestReceived', 'ResponseStarted', 'ResponseComplete', and 'Panic'
C.The audit policy file is passed to the API server via the --audit-policy-file flag
D.The 'Request' level logs both request and response bodies
E.The 'Metadata' level logs the request body
AnswersB, C

Correct.

Why this answer

Audit policy levels are None, Metadata, Request, RequestResponse. Stages include RequestReceived, ResponseStarted, ResponseComplete, Panic. The audit policy file is specified via --audit-policy-file flag.

Full explanation →
991
MCQhard

A cluster administrator has applied a PodSecurityPolicy (PSP) to restrict privileged containers. After upgrading to Kubernetes 1.25, they notice that PSPs are no longer working. What is the MOST likely reason?

A.The PSP API version needs to be updated to v1
B.PSPs were replaced by NetworkPolicies in 1.25
C.PSP support was removed from Kubernetes in 1.25
D.The PSP was not applied to the correct namespace
AnswerC

Correct. PodSecurityPolicy was removed in Kubernetes 1.25.

Why this answer

PodSecurityPolicy (PSP) was deprecated in Kubernetes 1.21 and completely removed in Kubernetes 1.25, meaning the PSP admission controller and API resource no longer exist in that version. The cluster administrator's PSPs stopped working because the feature was removed entirely, not due to a configuration or versioning issue. The replacement is Pod Security Admission (PSA), which uses built-in admission controllers and Pod Security Standards.

Exam trap

The trap here is that candidates may think PSPs are merely deprecated or need a version update, but the CKS exam tests the specific knowledge that PSP was removed entirely in 1.25, and that NetworkPolicies serve a completely different purpose.

How to eliminate wrong answers

Option A is wrong because PSP API version updates are irrelevant; the entire PSP API was removed in 1.25, not just deprecated or requiring a version bump. Option B is wrong because NetworkPolicies control network traffic between pods, not pod security constraints like privileged containers; they are not a replacement for PSPs. Option D is wrong because namespace scoping is not the issue; PSPs were cluster-level resources that applied globally via admission controllers, and their removal affects all namespaces equally.

Full explanation →
992
MCQmedium

You are auditing RBAC and find a ClusterRoleBinding named 'admin-binding' that binds the 'cluster-admin' ClusterRole to the service account 'default' in namespace 'kube-system'. What is the risk?

A.The risk is only if the service account is used by external users
B.The ClusterRoleBinding is invalid because it uses a namespace-scoped service account
C.Any pod using the default service account in kube-system has cluster-admin privileges
D.No risk, as it is limited to kube-system namespace
AnswerC

The service account inherits the cluster-admin role.

Why this answer

Option C is correct because the ClusterRoleBinding 'admin-binding' binds the 'cluster-admin' ClusterRole to the 'default' service account in the 'kube-system' namespace. Since ClusterRoleBindings are cluster-scoped, they grant permissions across all namespaces. Any pod in the 'kube-system' namespace that uses the 'default' service account (which is the default if no other service account is specified) will inherit cluster-admin privileges, allowing full control over the entire cluster.

Exam trap

CNCF often tests the distinction between RoleBindings (namespace-scoped) and ClusterRoleBindings (cluster-scoped), and the trap here is that candidates mistakenly think a ClusterRoleBinding to a namespace-scoped service account is invalid or limited to that namespace.

How to eliminate wrong answers

Option A is wrong because the risk is not limited to external users; any pod (including internal workloads) using the default service account in kube-system gains cluster-admin privileges, regardless of user identity. Option B is wrong because ClusterRoleBindings can bind to namespace-scoped subjects (like service accounts) — the binding is valid and does not require the subject to be cluster-scoped. Option D is wrong because ClusterRoleBindings grant permissions cluster-wide, not limited to the kube-system namespace; the binding gives admin access to all namespaces.

Full explanation →
993
MCQmedium

A pod fails to start with 'CrashLoopBackOff'. The pod's YAML includes securityContext: { allowPrivilegeEscalation: false, capabilities: { drop: ['ALL'] } }. What is the likely cause?

A.The container image requires privilege escalation to run
B.The pod is missing a required environment variable
C.The node does not support seccomp profiles
D.The pod's service account lacks permissions to create pods
AnswerA

If the application needs to perform privileged operations (e.g., setuid binaries, syscalls), dropping all capabilities and disabling privilege escalation will cause it to fail.

Why this answer

Setting allowPrivilegeEscalation: false and dropping all capabilities restricts the container from gaining additional privileges. If the container image relies on any privileged operations (e.g., using ping or other setcap binaries), it will fail.

Full explanation →
994
MCQeasy

Which kubectl command can be used to determine if anonymous authentication is enabled on the API server?

A.kubectl get --raw /api/v1
B.kubectl describe node | grep anonymous
C.kubectl cluster-info dump | grep -i anonymous
D.kubectl get pods -n kube-system kube-apiserver-<node> -o yaml | grep anonymous-auth
AnswerD

This shows the API server flags, including --anonymous-auth.

Why this answer

Option D is correct because the kube-apiserver manifest file (typically located in /etc/kubernetes/manifests/kube-apiserver.yaml) contains the `--anonymous-auth` flag. By inspecting the pod definition via `kubectl get pods -n kube-system kube-apiserver-<node> -o yaml`, you can see the exact command-line arguments passed to the API server, including whether `--anonymous-auth=false` is set (disabled) or absent (enabled by default). This is the most direct and reliable method to check anonymous authentication status.

Exam trap

The trap here is that candidates might think `kubectl cluster-info dump` or `kubectl get --raw` can reveal server flags, but these commands do not expose the API server's startup arguments; only inspecting the pod manifest or directly reading the static pod YAML file shows the actual `--anonymous-auth` setting.

How to eliminate wrong answers

Option A is wrong because `kubectl get --raw /api/v1` returns API resource listing and does not expose server configuration flags like anonymous authentication. Option B is wrong because `kubectl describe node` shows node metadata and conditions, not API server flags; the grep for 'anonymous' would not match anything relevant. Option C is wrong because `kubectl cluster-info dump` outputs cluster-wide logs and resource dumps, but it does not parse the API server's command-line arguments; grepping for 'anonymous' might yield false positives from logs or other components, not a definitive check of the `--anonymous-auth` flag.

Full explanation →
995
MCQhard

A Gatekeeper Constraint is not blocking pods that violate the policy. The constraint references a ConstraintTemplate that has been successfully created. What is the most likely cause?

A.The Constraint is missing the 'match' field
B.The Constraint has 'enforcementAction: dryrun'
C.The Constraint is in a different namespace than the pods
D.The ConstraintTemplate is missing the 'violation' rule
AnswerB

Dryrun mode logs violations but does not deny admission.

Why this answer

Option C is correct. In Gatekeeper, the enforcementAction defaults to 'deny', but if it is set to 'dryrun', violations are logged but not denied. Option A would cause the template to not be created; B would cause errors; D is not relevant.

Full explanation →
996
MCQmedium

An admin runs 'kubectl run nginx --image=nginx' and the pod fails with 'ImagePullBackOff'. The cluster has an OPA/Gatekeeper constraint that only allows images from 'myregistry.io'. How can the admin quickly test the restriction?

A.Delete the OPA constraint
B.Add a label 'allowlist=true' to the pod
C.Use an image from 'myregistry.io/nginx:latest'
D.Use 'kubectl run nginx --image=nginx --validate=false'
AnswerC

If the constraint allowlists 'myregistry.io', then using an image from that registry should pass the admission check.

Why this answer

The constraint restricts images to a specific registry. The admin should use an image from that registry to succeed. Option A is correct.

Full explanation →
997
MCQeasy

Which command loads an AppArmor profile into the kernel?

A.apparmor_load /path/to/profile
B.aa-load /path/to/profile
C.aa-status /path/to/profile
D.apparmor_parser -r /path/to/profile
AnswerD

apparmor_parser loads the profile into the kernel.

Why this answer

The `apparmor_parser` command is the standard tool for loading AppArmor profiles into the Linux kernel. The `-r` flag (replace) loads or reloads the specified profile file, merging it into the kernel's security policy. This is the correct method because AppArmor profiles are text files that must be parsed and loaded by the kernel's LSM (Linux Security Module) subsystem via this utility.

Exam trap

The trap here is that candidates may confuse the command with similar-sounding names like `aa-load` or `apparmor_load`, or mistake `aa-status` (a status-checking tool) for a loading command, because the CKS exam often tests precise command names and their specific functions.

How to eliminate wrong answers

Option A is wrong because `apparmor_load` is not a valid command; AppArmor does not provide a command with that name. Option B is wrong because `aa-load` is not a standard AppArmor command; the correct command is `apparmor_parser`. Option C is wrong because `aa-status` is used to check the status of loaded AppArmor profiles (e.g., which profiles are enforced or complain mode), not to load a profile into the kernel.

Full explanation →
Page 13

Page 14 of 14

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 →