CKS Monitoring, Logging and Runtime Security Practice Test 12 — 15 Questions

Question 1

Which THREE of the following are valid audit stages in Kubernetes audit logging? (Select THREE.)

Accepted Answer

ResponseStarted. In Kubernetes audit logging, the audit policy's `stage` field accepts exactly four values: RequestReceived, ResponseStarted, ResponseComplete, and Panic. Option B (RequestReceived) is correct because it is the stage generated as soon as the API server receives the request, before the response is sent. Option A (ResponseStarted) is correct because it is emitted once the response headers have been sent but before the response body is fully transmitted, which applies to long-running requests like watch operations. Option E (ResponseComplete) is correct because it is generated after the response body has been fully sent and the request lifecycle is finished. Option C (ResponseBuffered) is not a valid stage — no such value exists in the audit.k8s.io API. Option D (RequestProcessing) is also invalid; the API server does not expose a stage by that name, so it cannot be configured in an audit policy.

Answer

ResponseBuffered

Answer

RequestProcessing

Question 2

Which kubectl command can be used to view the live logs of a container in a pod named 'my-pod'?

Accepted Answer

kubectl logs -f my-pod. The command 'kubectl logs -f my-pod' streams the logs in real-time (follow mode), which is equivalent to viewing live logs. The -f flag stands for 'follow' and continuously outputs new log entries as they are generated.

Answer

kubectl attach my-pod

Answer

kubectl logs my-pod --tail 10

Answer

kubectl exec my-pod -- journalctl

Question 3

A security team wants to detect any attempt to read the /etc/shadow file inside a container. Which Falco rule condition would detect this syscall?

Accepted Answer

evt.type in (open, openat) and fd.name=/etc/shadow. The correct condition is 'evt.type in (open, openat) and fd.name=/etc/shadow' because reading a file in Linux involves the open or openat syscall to obtain a file descriptor. Falco's fd.name field captures the file path, and using 'in (open, openat)' covers both variants. This directly detects access to /etc/shadow.

Answer

evt.type=read and fd.name=/etc/shadow

Answer

evt.type=open and fd.name contains /etc/shadow

Answer

proc.name=cat and fd.name=/etc/shadow

Question 4

An administrator wants to enable Kubernetes audit logging with the following requirements: log all requests at the Metadata level, but log all responses at the Request level. Which audit policy configuration achieves this?

Accepted Answer

Use separate rules with 'stages: ["RequestReceived"]' level Metadata, and 'stages: ["ResponseComplete"]' level Request. Audit policies allow setting different levels for different stages. To meet the requirement of logging requests at Metadata level and responses at Request level, you need separate rules for each stage. Option D does this by using two rules: one with stages: ['RequestReceived'] and level: Metadata, and another with stages: ['ResponseComplete'] and level: Request. This ensures that request events are logged at Metadata level and response events at Request level.

Answer

Set default level to Metadata and use a dynamic level based on request size

Answer

Use the --audit-log-maxbackup flag to adjust levels

Answer

Set default level to Metadata and use a rule with level: Request for specific resources

Question 5

A pod named 'compromised-pod' is suspected of making unauthorized outbound connections. You want to isolate the pod using a NetworkPolicy. Which policy correctly denies all egress traffic from the pod?

Accepted Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and egress: []. A NetworkPolicy with podSelector matching 'compromised-pod' (via label app=compromised) and an empty egress list (egress: []) explicitly denies all egress traffic from the pod. This is the standard Kubernetes pattern to isolate a pod by default-deny egress. Option A allows egress to 0.0.0.0/0, which permits all outbound traffic. Option B only restricts ingress, not egress. Option D allows egress to pods matching an empty podSelector (all pods), thus permitting traffic to other pods in the namespace. Therefore, only option C achieves complete egress isolation.

Answer

NetworkPolicy with podSelector: {} and egress: [{to: [{ipBlock: {cidr: 0.0.0.0/0}}]}]

Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and policyTypes: ["Ingress"]

Answer

NetworkPolicy with podSelector: matchLabels: app: compromised and egress: [{to: [{podSelector: {}}]}]

Question 6

Which crictl command lists all running containers on a node?

Accepted Answer

crictl ps. The crictl ps command lists running containers on a node by querying the CRI runtime, similar to docker ps. It shows container ID, image, state, and other details for containers currently running, and with the -a flag it also shows stopped containers.

Answer

crictl pods

Answer

crictl images

Answer

crictl stats

Question 7

Which TWO of the following are valid audit policy levels in Kubernetes? (Choose two.)

Accepted Answer

RequestResponse. In Kubernetes audit policy, the valid audit levels are None, Metadata, Request, and RequestResponse, so option A (RequestResponse) is correct because it logs the request metadata and body plus the response metadata and body, providing the most complete audit record. Option E (Metadata) is also correct because it logs only the request metadata (such as the user, timestamp, resource, and verb) without request or response bodies, which is one of the officially supported audit levels. The unmarked options do not belong: Verbose is not a Kubernetes audit level, Response is not a standalone audit level (response logging is part of RequestResponse), and All is not a valid audit policy level in Kubernetes.

Answer

Verbose

Answer

Response

Answer

All

Question 8

Which THREE of the following are recommended steps during incident response for a compromised pod? (Choose three.)

Accepted Answer

Take a memory dump of the container for analysis. Option A is correct because capturing a memory dump of the container preserves volatile evidence such as running processes, injected code, and in-memory credentials before the pod is terminated or restarted. Option C is correct because kubectl logs retrieves container stdout/stderr history and kubectl exec allows live inspection of the filesystem, processes, and network state for forensic collection. Option D is correct because applying a NetworkPolicy that denies egress traffic contains the compromised pod, preventing data exfiltration or command-and-control communication while investigation continues. Option B is not recommended because deleting the entire namespace destroys evidence and may disrupt unrelated workloads. Option E is not recommended because restarting the pod immediately destroys volatile memory and runtime artifacts needed for root-cause analysis.

Answer

Delete the entire namespace containing the pod

Answer

Immediately restart the pod to stop the attack

Question 9

Which TWO of the following Falco fields can be used in a rule condition to detect a shell spawned inside a container? (Choose two.)

Accepted Answer

proc.pname. Option C (proc.pname) is correct because it identifies the parent process name, so a rule can match when the parent is a shell or entrypoint such as bash, sh, or a container runtime, indicating a shell was spawned by another process. Option E (proc.name) is correct because it identifies the name of the process that was executed, allowing detection of the spawned shell itself, e.g., proc.name=bash or proc.name=sh. Together, proc.pname and proc.name let Falco express conditions like proc.name in (bash, sh) and proc.pname in (bash, sh, docker, containerd) to catch shells spawned inside containers. Option A (evt.type) only describes the syscall event type (e.g., execve, clone) and does not by itself identify a shell process. Option B (k8s.ns.name) only scopes the event to a Kubernetes namespace and provides no process-level information. Option D (container.id) merely identifies the container in which the event occurred, not that a shell was spawned.

Answer

evt.type

Answer

k8s.ns.name

Answer

container.id

Question 10

Which TWO of the following are valid audit stages in Kubernetes? (Choose two.)

Accepted Answer

ResponseComplete. In Kubernetes auditing, the audit policy defines stages that determine at which points in the request lifecycle an audit event is recorded. Option B, ResponseComplete, is a valid stage that logs an event after the API server has finished sending the response to the client, capturing the final outcome. Option C, RequestReceived, is a valid stage that logs an event as soon as the API server receives the request, before any processing occurs. The other options are not valid Kubernetes audit stages: ResponseFull, RequestProcessing, and RequestComplete do not exist in the audit.k8s.io API; the actual stages are RequestReceived, ResponseStarted, ResponseComplete, and Panic.

Answer

ResponseFull

Answer

RequestProcessing

Answer

RequestComplete

Question 11

A CKS candidate is investigating a pod that appears to have been compromised. The incident response team wants to capture the exact system calls made by processes inside the container to understand the attacker's actions. Which Kubernetes-native feature or tool should be used to collect this syscall-level telemetry?

Accepted Answer

Falco with the appropriate kernel module or eBPF probe loaded on the node. Collecting syscall-level telemetry requires a runtime security tool that hooks into the kernel. Falco, using either its kernel module or eBPF probe, observes system calls across all processes on the node, including those inside containers. This allows incident responders to see exactly which syscalls a compromised process invoked, providing the granular data needed for forensic analysis of the attack.

Answer

kubectl debug with a privileged profile attached to the pod

Answer

Container runtime logs collected by the kubelet and exposed via kubectl logs

Answer

Kubernetes audit logging configured with the RequestResponse level

Question 12

A security engineer is hardening a Kubernetes cluster and wants to ensure that any container attempting to load a kernel module is immediately detected and logged. They have deployed Falco on all nodes. Which Falco rule condition should they use to detect this activity?

Accepted Answer

evt.type=init_module or evt.type=finit_module. To detect kernel module loading, Falco must monitor the init_module and finit_module system calls, which are the actual kernel interfaces for loading modules. Matching evt.type against these syscall names provides direct, reliable detection regardless of which user-space tool or method is used to initiate the load. This condition is precise and minimizes false positives.

Answer

evt.type=mmap and fd.type=module

Answer

evt.type=execve and proc.name contains modprobe

Answer

evt.type=open and fd.name contains /lib/modules

Question 13

A security analyst notices that a Falco rule intended to detect writes to /etc inside containers is generating alerts for a legitimate application that writes to /etc/app/config. The analyst wants to refine the rule to exclude this specific path while still detecting other writes to /etc. Which Falco rule condition modification should be applied?

Accepted Answer

Add 'and not fd.name = /etc/app/config' to the condition. Falco rules can be tuned with boolean conditions to exclude known legitimate activity. To suppress alerts for a specific file path, the condition should include a check that the file descriptor name does not equal that path. This maintains detection for all other writes to /etc while eliminating the false positive from the legitimate application's configuration file.

Answer

Add 'and not fd.directory = /etc/app' to the condition

Answer

Add 'and not proc.name = app' to the condition

Answer

Change the rule's priority from WARNING to NOTICE

Question 14

A cluster runs Kubernetes 1.29 with the AppArmor support enabled. A pod manifest sets securityContext.appArmorProfile.type to Localhost with localhostProfile: k8s-nginx. The pod stays in ContainerCreating and the kubelet logs show a failed to apply AppArmor profile error. Which action most directly resolves the failure?

Accepted Answer

Load the k8s-nginx profile into the kernel on every node in the cluster with apparmor_parser -r before the pod is scheduled.. Localhost AppArmor profiles must exist in the node kernel before a pod referencing them can start. The kubelet and container runtime only look up the named profile; they do not load it. Loading k8s-nginx with apparmor_parser on each node that may run the pod makes the profile resolvable, allowing the container to be created under the intended policy.

Answer

Install the AppArmor profile into the container image at /etc/apparmor.d/k8s-nginx and restart the pod.

Answer

Add the k8s-nginx profile to the kube-apiserver's --apparmor-profile flag.

Answer

Change the profile type to RuntimeDefault so the container inherits the runtime's default AppArmor profile.

Question 15

A security analyst needs to detect and record attempts to modify Kubernetes audit-relevant resources. The cluster already forwards audit logs to a SIEM. Which configuration ensures the API server records both the request and the response for changes to Secrets, while keeping other requests at a lighter level?

Accepted Answer

Set --audit-policy-file to a policy that places a rule with level: RequestResponse and resources: [{group: "", resources: ["secrets"]}] above a catch-all rule with level: Metadata.. Audit policy rules are matched in order, and the first match determines the level. A resource-specific rule at RequestResponse placed above a broad Metadata rule records full request and response bodies for Secret changes while keeping other traffic light. Reversing the order or using a broad RequestResponse rule would either miss the bodies or flood the audit backend.

Answer

Set --audit-policy-file to a policy with a rule at level: Request for secrets and a catch-all at level: RequestResponse.

Answer

Set --audit-policy-file to a policy with a single rule at level: RequestResponse and no resource restriction.

Answer

Set --audit-policy-file to a policy with a rule at level: Metadata for secrets and a catch-all at level: None.