CCNA Monitoring, Logging and Runtime Security Questions

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.

Practice this question →

Multi-Selectmedium

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

Select 3 answers

A.Authentication

B.ResponseComplete

C.Authorization

D.RequestReceived

E.ResponseStarted

AnswersB, D, E

ResponseComplete is a valid audit stage, but not selected as the required two.

Why this answer

Valid Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. All three options B (ResponseComplete), D (RequestReceived), and E (ResponseStarted) are valid audit stages. The question asks for two, but there are three valid options; thus, the correct set includes B, D, and E.

Practice this question →

MCQmedium

During a runtime incident, you suspect a container has a reverse shell. Which kubectl command can you use to examine the container's running processes?

A.kubectl logs <pod-name>

B.kubectl exec <pod-name> -- ps aux

C.kubectl top pod <pod-name>

D.kubectl describe pod <pod-name>

AnswerB

Correct. `kubectl exec <pod-name> -- ps aux` executes the `ps aux` command inside the container, displaying all active processes. This is the appropriate kubectl command to check for a reverse shell without requiring node-level access.

Why this answer

`kubectl exec <pod-name> -- ps aux` runs the `ps aux` command inside the container, which lists running processes. It is the only kubectl command that allows you to inspect container processes. Options A, C, and D do not provide process listings.

Exam trap

The exam may test that `kubectl exec` is the kubectl command used to run commands inside a container, enabling process inspection.

How to eliminate wrong answers

Option A is wrong because `kubectl logs` only retrieves the container's stdout/stderr logs, not a list of running processes; it cannot reveal a reverse shell that may not produce log output. Option C is wrong because `kubectl top pod` shows CPU and memory usage metrics for the pod, not process listings; it cannot identify specific processes like a reverse shell. Option D is wrong because `kubectl describe pod` provides metadata, events, and configuration details about the pod, not the container's running processes; it cannot inspect runtime process activity.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.ResponseStarted

B.Panic

C.ResponseFinished

D.RequestProcessing

E.RequestReceived

AnswersA, E

ResponseStarted is a valid audit stage that fires after the response headers are sent but before the body.

Why this answer

Kubernetes audit logging defines four stages: RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the options, valid stages are A (ResponseStarted), B (Panic), and E (RequestReceived). Since the question asks for exactly two, the selected correct answers are A and E.

Both are valid. Option B (Panic) is also a valid stage but is not included as a correct answer for this specific question.

Exam trap

The trap is that candidates may not realize that RequestReceived is also a valid stage and might overlook it, assuming only ResponseStarted and Panic are the only two. The question selects A and E as the correct pair, but any two of the three valid stages would be technically correct.

Practice this question →

Multi-Selectmedium

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

Select 2 answers

A.ResponseStarted

B.ResponseDelay

C.ResponseComplete

D.RequestProcessing

E.RequestReceived

AnswersA, E

Correct: This is a valid stage.

Why this answer

The Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. In the given options, ResponseStarted (A) and RequestReceived (E) are valid stages and are the two correct answers according to the question. Option C (ResponseComplete) is also a valid stage, but since the question explicitly asks for two, it is not selected as a correct answer here.

Options B (ResponseDelay) and D (RequestProcessing) are not valid audit stages.

Practice this question →

MCQmedium

You are using `crictl` to debug a container that is not responding. Which command should you use to get the list of running containers?

A.crictl pods

B.crictl ps

C.crictl images

D.crictl stats

AnswerB

crictl ps lists containers (including running, paused, exited).

Why this answer

`crictl ps` is the correct command because it lists running containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O). This is analogous to `docker ps` but for the Kubernetes container runtime interface, allowing you to see container IDs, names, and statuses for debugging.

Exam trap

The trap here is that candidates familiar with Docker may confuse `crictl ps` with `docker ps` but forget that `crictl pods` exists for pod-level operations, leading them to incorrectly choose `crictl pods` when the question asks for running containers.

How to eliminate wrong answers

Option A is wrong because `crictl pods` lists pods (groups of containers), not individual containers, and is used for pod-level debugging. Option C is wrong because `crictl images` lists container images stored locally, not running containers. Option D is wrong because `crictl stats` shows resource usage statistics (CPU, memory) for running containers, not a list of them.

Practice this question →

MCQmedium

You need to configure Kubernetes audit logging to log all requests to the 'secrets' API. Which audit policy level captures the body of the request?

A.Request

B.None

C.RequestResponse

D.Metadata

AnswerA

The Request audit level instructs the kube-apiserver to log the event's metadata and the raw request body, including any submitted objects, parameters, and headers. Because the requirement is only to capture request payloads, Request satisfies the condition without also recording the response. This level is ideal when you need to know exactly what the client sent, but you don't care about the server's reply.

Why this answer

The 'Request' audit level logs the request metadata and the request body, which includes the body of the request. This is exactly what the question asks for. 'RequestResponse' adds the response body, which is not required per the question. Therefore, the correct answer is A.

Exam trap

The trap is that candidates may overthink and choose RequestResponse because it captures more, but the question precisely asks for 'the body of the request', which is captured by the Request level.

How to eliminate wrong answers

Option A is wrong because the 'Request' level logs only the request metadata and the request body, but not the response body; however, the question asks for the level that captures the body of the request, and 'Request' does capture the request body, but the correct answer is 'RequestResponse' because it captures both request and response bodies, and the question's phrasing implies the need for full body capture including response. Option B is wrong because 'None' logs no events at all, so it cannot capture any request body. Option D is wrong because 'Metadata' logs only the request metadata (e.g., user, timestamp, resource) and does not include the request or response body, so it cannot capture the body of the request.

Practice this question →

MCQeasy

What is the purpose of setting a container's filesystem to read-only in a Pod spec?

A.To prevent an attacker from modifying the container's filesystem after compromise

B.To allow multiple pods to share the same filesystem

C.To prevent the container from being deleted

D.To improve disk I/O performance

AnswerA

Setting a container's filesystem to read-only enforces a runtime security boundary: even if an attacker gains code execution inside the container, they cannot write to the root filesystem, modify existing binaries, or plant persistent payloads. This aligns with immutable infrastructure principles and limits the blast radius of a compromise, though ephemeral writable locations like tmpfs volumes can still be used if needed.

Why this answer

Setting a container's filesystem to read-only in a Pod spec (via `securityContext.readOnlyRootFilesystem: true`) ensures that the container's root filesystem cannot be written to at runtime. This is a critical runtime security hardening measure because even if an attacker gains code execution inside the container (e.g., through a web application vulnerability), they cannot modify binaries, configuration files, or scripts on the filesystem, severely limiting their ability to persist, escalate privileges, or tamper with the application. This aligns with the principle of immutable infrastructure and is a key control in the CKS domain of Runtime Security.

Exam trap

Candidates often mistake the read-only filesystem as a performance or sharing feature, but it is strictly a security control to prevent post-compromise tampering. This is a key concept in the CKS domain of Runtime Security.

How to eliminate wrong answers

Option B is wrong because sharing a filesystem between multiple pods is achieved through PersistentVolumeClaims with `ReadWriteMany` access modes or hostPath volumes, not by setting the container's filesystem to read-only. Option C is wrong because preventing a container from being deleted is a matter of Pod lifecycle management (e.g., using `terminationGracePeriodSeconds` or PodDisruptionBudgets), not filesystem permissions. Option D is wrong because setting a filesystem to read-only does not improve disk I/O performance; in fact, it may have a negligible effect or even slightly degrade performance if the container attempts writes that are silently dropped or cause errors.

Practice this question →

MCQhard

A Falco rule is written to detect when a shell is spawned inside a container. The rule condition is: `spawned_process and container and proc.name = bash`. The rule is not triggering. Which of the following is the most likely reason?

A.The rule is missing `proc.name in (bash, sh, zsh)` because only bash is checked

B.Falco is not running with the required syscall capabilities

C.The `spawned_process` macro may not match because the process was inherited (not spawned), e.g., from an entrypoint

D.The priority is set to `ERROR` but the output is being filtered

AnswerC

The `spawned_process` macro is defined to match processes whose parent is a shell, i.e., processes created via `fork` and `exec` from an interactive or scripted shell. When a container runs an entrypoint that directly exec's a shell as PID 1, the parent of that shell is the container runtime or init process, not another shell. As a result, the `proc.pname` check inside the macro fails, and the rule never matches even though the shell is present. In such cases, the shell is inherited rather than spawned, so a rule relying on `spawned_process` will not fire.

Why this answer

The `spawned_process` macro in Falco specifically matches processes that are created via `execve` or `fork` system calls. If a shell is inherited from the container's entrypoint (e.g., the container runs `bash` as PID 1 directly), it is not considered a spawned process but rather the initial process of the container. Falco's default `spawned_process` macro filters out such inherited processes, so the rule condition fails to match even though `proc.name = bash` is true.

Exam trap

The trap here is that candidates often focus on the `proc.name` condition and assume the rule is incomplete (option A), but the real issue is the `spawned_process` macro's definition, which excludes the initial container process, a nuance The CKS exam frequently tests in runtime security scenarios.

How to eliminate wrong answers

Option A is wrong because the rule condition `proc.name = bash` is syntactically correct and would match a process named exactly 'bash'; the issue is not about missing shell names but about the process not being detected as spawned. Option B is wrong because Falco requires specific syscall capabilities (e.g., `SYS_EXECVE`, `SYS_FORK`) to detect spawned processes, and if those capabilities were missing, Falco would not detect any spawned processes at all, not just this rule; the question states the rule is not triggering, implying other rules might work, so this is not the most likely reason. Option D is wrong because priority filtering (e.g., `ERROR` vs `WARNING`) affects whether an alert is output or logged, but does not prevent the rule from triggering; the rule condition itself must be satisfied first, and priority is irrelevant to the matching logic.

Practice this question →

MCQmedium

You are responding to a security incident where a pod named `compromised-pod` in namespace `default` is suspected of being used for cryptocurrency mining. You need to immediately isolate the pod from the network while preserving evidence. Which command sequence should you use?

A.kubectl cordon <node-of-compromised-pod>

B.kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml

C.kubectl delete pod compromised-pod && kubectl describe pod compromised-pod

D.kubectl exec compromised-pod -- killall miner-process

AnswerB

Ly identifies the need to label the pod and apply a deny-all NetworkPolicy. The command sequence is impractical (busybox lacks kubectl), but the concept is what the exam tests. In a real scenario, you would label the pod directly and then apply the policy.

Why this answer

The correct approach is to label the pod and apply a deny-all NetworkPolicy that selects pods with that label. This immediately isolates the pod from all network traffic while preserving the pod for forensic analysis. The command sequence is: kubectl label pod compromised-pod isolated=true && kubectl apply -f networkpolicy.yaml where the networkpolicy.yaml defines an ingress/egress deny-all policy for pods with label isolated=true.

Exam trap

In the CKS exam, a common trap is confusing node-level controls (cordon, drain) with pod-level network isolation (NetworkPolicy). Candidates may think cordoning a node isolates the pod, or that deleting the pod is sufficient containment, but deleting destroys forensic evidence.

How to eliminate wrong answers

Option A is wrong because `kubectl cordon` marks a node as unschedulable, preventing new pods from being scheduled on it, but it does not affect network traffic to or from existing pods on that node; the compromised pod remains fully connected. Option C is wrong because deleting the pod destroys the running container and its ephemeral storage, losing volatile evidence (e.g., running processes, open file handles, memory dumps) that is critical for incident response. Option D is wrong because `kubectl exec` to kill a specific process assumes you know the exact process name and does not guarantee the mining process is stopped (it may respawn), and it does not isolate the pod from network egress, allowing continued communication with external mining infrastructure.

Practice this question →

Multi-Selectmedium

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

Select 3 answers

A.ResponseReceived

B.Panic

C.ResponseStarted

D.RequestReceived

E.RequestSent

AnswersB, C, D

Panic is a valid audit stage that captures events that cause a panic in the API server.

Why this answer

Kubernetes audit stages include RequestReceived, ResponseStarted, ResponseComplete, and Panic. Among the given options, RequestReceived (D), ResponseStarted (C), and Panic (B) are all valid stages. Options A (ResponseReceived) and E (RequestSent) are not standard stages.

Practice this question →

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.

Practice this question →