CCNA Cks Monitoring Runtime Questions

CONTAINER_RUNNING is the state crictl reports for a container whose process is active and healthy, matching the stem's observation directly. Unlike CONTAINER_EXITED or CONTAINER_CREATED, it confirms the container runtime has started the workload and it has not terminated, so the container is operating normally.

The --audit-policy-file flag tells kube-apiserver where to find the audit policy defining which events to record and at what level. Without it, the API server has no ruleset, so no audit events are generated regardless of any log destination configured.

The --previous flag instructs kubectl to fetch log output from the previously terminated container instance rather than the current one. In a CrashLoopBackOff scenario, the current container has just restarted and may only show startup messages (if any), while the actual panic or error that caused the crash lives in the previous container's stdout/stderr. This flag is the correct way to retrieve that historical crash output and diagnose the root cause.

Audit policy rules are evaluated in order, first match wins. Placing the RequestResponse rule for secrets in kube-system first captures that resource at full detail, while the trailing Metadata rule acts as the catch-all for every other request, satisfying both logging requirements in one policy.

crictl relies on a CRI runtime endpoint to communicate with the container runtime. If --runtime-endpoint is omitted, crictl uses its built-in default, which usually points to a non-existent dockershim socket on modern CRI runtimes such as containerd or CRI-O. A wrong or missing endpoint means the gRPC connection silently fails, so crictl ps returns no output even though containers are running.

crictl ps is the correct command because it queries the CRI runtime for all containers and, by default, filters to those in the running state. It displays each container's unique ID, the associated pod, name, and status, directly satisfying the question's request. This is the standard CRI-O/containerd equivalent of docker ps for inspecting active containers on a node.

The `-c` flag is the shorthand for `--container` and tells kubectl which container's logs to read from the pod. This is essential when the pod runs multiple containers, because kubectl logs by default only returns logs from the first container or fails with an ambiguity error. Both `-c` and `--container` are valid, so this command correctly targets a specific container.

Falco detects shell execution by monitoring the execve syscall, which replaces the calling process image with a new program. When a shell binary such as /bin/sh is launched inside a container, execve fires, letting the rule match the spawned process and satisfy the stem's requirement to detect shell execution.

This is the correct method: a NetworkPolicy that selects the compromised pod via its podSelector and explicitly lists policyTypes: [Ingress, Egress] with no rules. With this configuration, the pod is isolated because the policy enforces an implicit deny: any traffic that is not explicitly allowed is dropped, and since there are no allow rules, all ingress and egress traffic is blocked. This effectively quarantines the pod without affecting other pods.

The write fails because `securityContext.readOnlyRootFilesystem: true` makes the container's root filesystem read-only at the kernel level, so every path on the root filesystem—including /tmp—is immutable. The `write()` syscall returns `EROFS` (read-only file system) or `EACCES` (permission denied) unless a writable volume such as an `emptyDir` is explicitly mounted at /tmp. The error is surfaced to the application, not hidden.

crictl logs <container-id> is the correct command because it directly retrieves the container's stdout/stderr log stream from the CRI-compatible runtime (containerd, CRI-O, etc.). The runtime stores these logs separately from the container's filesystem, and crictl logs queries that store, analogous to `docker logs`. You can further tailor it with flags like `--tail` or `--timestamps`, but the base command is what fetches the log output for a given container ID.

This policy correctly isolates the compromised pod by selecting it with podSelector and defining an ingress rule that only allows traffic from pods labeled app: monitoring-pod. Because policyTypes explicitly includes both Ingress and Egress, and no egress rules are present, the pod gets a default egress deny. Thus, the pod cannot reach outbound destinations and only accepts incoming traffic from the monitoring pod, achieving effective quarantine while preserving observability.

kubectl exec -it <pod> -- /bin/sh is correct because -i keeps stdin open for the session, -t allocates a pseudo-TTY, and the -- separates the command to run inside the container. This combination starts an interactive shell as long as /bin/sh is present in the container's filesystem; if it is not, a similar command with /bin/bash or an ephemeral debug container would be needed.

Capturing the full log stream before deletion preserves volatile evidence that vanishes with the pod. The --tail=-1 flag retrieves every retained line rather than the default last ten, satisfying the requirement to secure container logs prior to removing the compromised workload.

Using stages explicitly lets you tailor logging per phase: placing level: Metadata for stages: ["RequestReceived"] captures lightweight metadata early, and level: Request for stages: ["ResponseComplete"] captures the full request body after processing. Since the first matching rule in the policy file wins, order these rules appropriately to avoid the default rule catching the RequestReceived stage. This is the correct way to achieve stage-specific audit levels.

ResponseStarted is a valid audit stage that fires when the kube-apiserver begins sending response headers to the client. It occurs after the response status code and headers have been written, allowing audit tooling to capture the HTTP status and header metadata before the body streams. This stage is crucial for detecting errors or slow responses where the connection may be interrupted before the body completes.

RequestResponse for secrets is the correct choice because it logs the complete API exchange: metadata, the request body (e.g., a Secret create or update payload), and the response body (e.g., the decoded secret data returned by a GET). For core secrets (group ""), this rule ensures that every operation—from read to write—is fully captured, enabling auditors to see exactly what secret material was accessed or modified. This is the only level that provides full visibility into the sensitive payload itself.

crictl ps queries the container runtime for containers in the running state, listing their IDs, images and status. It is the direct equivalent of docker ps, satisfying the need to enumerate active containers before inspecting or debugging the unresponsive one.

The correct approach is to monitor open and openat syscalls because these are the system calls that actually request access to a file by pathname; the fd.name field is populated from the path argument at this point. Using the 'in' operator with both syscall variants covers modern and legacy call patterns, while the exact match '=' on fd.name ensures we detect /etc/shadow specifically and not similar paths. This rule catches any process, regardless of the tool used, and is the standard Falco pattern for file-access detection.

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.

The 'sensitive_file_names' macro is a standard Falco macro that defines a list of file names and paths considered sensitive, including /etc/passwd, /etc/shadow, /etc/sudoers, and various credential files. This macro is designed to be used in conditions for file-open rules, matching when the opened file's path is in that list. For a rule that outputs 'sensitive file opened', using this macro directly and correctly identifies the event type by filtering on the specific file path. It is the only option among the four that aligns with the rule's intent and is the correct choice.

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.

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.

Adding a toleration to the pod spec that matches the taint 'node-role.kubernetes.io/master' with effect 'NoSchedule' tells the scheduler that this pod is willing to be placed on that tainted node. This is the correct, targeted fix because tolerations are the built-in mechanism to relax taint constraints for a specific workload. The toleration should include the exact key, operator (usually 'Exists' or 'Equal'), and effect to match the taint present on the node.

Setting spec.containers[].securityContext.readOnlyRootFilesystem to true instructs the container runtime to mount the container's root filesystem as read-only, meaning the image's root filesystem and any upper writable layer become immutable at the mount level. When this is set, any attempt to write to directories other than explicitly mounted volumes (such as emptyDir or persistent volumes) fails with an error, preventing tampering with binaries, libraries, or configuration files. This is the direct and intended securityContext field to enforce root filesystem immutability for a container, though you may need to mount writable volumes for runtime data like /tmp.

Falco is a runtime security tool that instruments the Linux kernel through a kernel module or eBPF probe to observe system calls made by containers. When configured with rules that capture syscall activity, it can generate alerts or events containing the exact syscalls executed, which is precisely the telemetry required to reconstruct an attacker's actions inside the compromised pod.

This is the correct command; it lists containers managed by the CRI-compatible runtime (e.g., containerd, CRI-O), showing container ID, name, image, and status. By default it shows running containers, and you can use -a to include stopped ones. This maps directly to the concept of 'listing all running containers' in a CRI environment.

This rule is accurate because Falco's open event exposes the target path in the fd.name field, so the condition matches only when a process attempts to open the /etc/shadow file, regardless of how it eventually reads it. The open() syscall is the necessary first step for reading a file's contents, making this a reliable, low-noise detector for attempts to access sensitive files like the shadow password database.

crictl logs is the correct command because it directly fetches and prints the stdout/stderr output of a specified container, identified by its container ID or name. This command is the CRI equivalent of `docker logs` and is what you would use to inspect application or runtime output for debugging. It supports additional flags such as `-f` to follow logs in real time and `--previous` to view logs from a terminated container, making it the definitive tool for accessing container logs with crictl.

The Docker CLI and daemon communicate through a Unix socket bound at the host path /var/run/docker.sock. If a container mounts this socket, any process inside the container can issue Docker API calls to create privileged containers or mount the host filesystem, effectively escaping the container. Falco detects this by checking the fd.name field on connect/open operations, and this exact absolute path is the canonical socket location Docker uses by default, so it is the correct rule condition.

This is correct: DaemonSet pods, like all pods, are subject to taints and tolerations. If a node has a taint, the DaemonSet pod template must include the matching toleration; otherwise, the scheduler will leave the pod Pending with an event like '0/N nodes are available: N node(s) had taint {key=value:NoSchedule}, that the pod didn't tolerate.' The DaemonSet controller can only create pods; it cannot bypass the scheduler's taint rules.

This is the correct isolation policy because it selects only the compromised pod using its `app: busybox` label and declares both `Ingress` and `Egress` in `policyTypes` while omitting any allow rules. According to NetworkPolicy semantics, when a policy isolates a traffic direction and contains no rules for that direction, all traffic of that type is denied. Therefore this policy enforces a complete default-deny on both inbound and outbound traffic for the busybox pod, cutting off all network communication with it.

ResponseComplete is one of the four valid Kubernetes audit stages. It fires after the HTTP response has been fully transmitted to the client, meaning the audit event can include the complete response body, status code, and headers. This stage is essential for capturing full-response data for forensic analysis, though it may produce larger audit logs than earlier stages.

Unexpected mount or umount2 activity attributed to a runtime helper or a container process often accompanies container escape techniques that remount host paths or pivot into the host filesystem. Alerting on these syscalls with a source or process constraint highlights tampering that is rare in normal tenant workload operation.

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.

This is the correct flag that actually enables audit logging. It specifies the path to a YAML file containing a list of rules that define, in order, which requests (based on user, verb, resource, and phase) should be logged and at which level (None, Metadata, Request, RequestResponse). Only when this flag is present does the kube-apiserver generate audit events; simultaneously configured backends like --audit-log-path or --audit-webhook-config-file become active and receive those events.

Falco is the CNCF-graduated runtime security tool that runs as a DaemonSet on every node, with each replica using a kernel driver (eBPF or kernel module) to capture syscalls. It continuously evaluates those syscalls against a comprehensive ruleset—detecting behaviors like shell access, privilege escalation, or suspicious file reads—and produces real-time security alerts. This combination of kernel instrumentation and rule evaluation is exactly what is required to monitor runtime security events in a Kubernetes cluster.

Falco rules match process attributes from the kernel; checking proc.name equals bash while container is true detects an interactive shell spawned inside a container. This distinguishes container shell execution from host-level bash processes, which is the behaviour being hunted.

crictl logs <container-id> correctly invokes the CRI's ContainerLogs method, which fetches the log stream generated by the container's primary process. It supports common flags like --follow, --tail, and --timestamps, making it the direct equivalent to 'docker logs' for node-level troubleshooting when you have a container ID rather than a pod.

HIGH is not a valid priority level in this context. Falco's predefined priority levels are EMERGENCY, ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFO, and DEBUG; there is no HIGH level. A rule that needs to indicate a serious threat above WARNING must use CRITICAL (or ALERT/EMERGENCY), not HIGH.

The open syscall is the correct hook because it is the first syscall where the target path is supplied by the caller and resolved by the kernel, making it ideal for path-based detection. With evt.type=open, fd.name matches the path exactly as passed, and the event is emitted on both successful opens and failed attempts like EACCES, so even permission-denied probing is captured. This rule does not depend on the process name, meaning it works for any utility or binary, and it also covers openat variants when Falco normalizes them appropriately. It is the most reliable and complete condition for detecting access to /etc/shadow among the given options.

Applying a NetworkPolicy that denies all ingress and egress to the pod is a correct first step because it achieves network-level containment without destroying the running container or its filesystem. This isolation prevents the attacker from communicating with the pod or using it as a pivot, while preserving the pod's memory, disk, and process state for forensic analysis. Unlike deletion or eviction, this action is reversible and does not trigger rescheduling, keeping the compromised pod in a known, quarantined state for further investigation.

The `connect` syscall is the kernel entry point for a client initiating an outbound TCP connection, setting the remote endpoint from the local socket. Filtering on `evt.type=connect` with `fd.ip not in (allowed_ips)` directly matches egress attempts to any destination IP that is not on the allowlist, making this the correct event type for detecting unexpected outbound connections. This rule captures the moment a process tries to reach an external IP, regardless of whether the connection ultimately succeeds or fails.

Taking a snapshot of the container's filesystem captures the exact writable layer and all runtime changes, including planted malware, persistence mechanisms, and attacker-modified system files. Use `docker commit` or `crictl` to export the live container state into an immutable image that can be analyzed offline without altering the original evidence. This is forensically sound and should be the first priority before any containment or cleanup action.

RequestReceived is the first stage of a Kubernetes audit event, emitted as soon as the kube-apiserver receives the request and before any admission or processing occurs. It captures the raw request metadata, making it useful for observing requests that may later be rejected or mutated by admission controllers. This stage is one of the four valid audit stages defined in the AuditConfiguration, along with ResponseStarted, ResponseComplete, and Panic.

`crictl ps` is the correct command because it directly queries the Container Runtime Interface (CRI) to list containers on the node. It is analogous to `docker ps` and, with the `-a` flag, shows both running and exited containers, enabling debugging of container states, IDs, images, and resource usage.

Setting readOnlyRootFilesystem: true mounts the container's root filesystem as read-only, blocking all writes to the overlay paths such as /, /etc, and /bin. The emptyDir volume mounted at /tmp is a tmpfs-based ephemeral storage that lives only as long as the pod, offering a writable scratch area without violating immutability. This configuration correctly achieves an immutable container filesystem while allowing the application to write temporary files.

ResponseStarted is a defined Kubernetes audit stage, triggered after the response headers are written but before the response body is sent. It is primarily relevant for long-running requests such as watches, enabling auditing of the initial response metadata without waiting for the entire stream to conclude.

The Metadata audit level captures the request's metadata, such as the user, timestamp, resource, and verb, while explicitly excluding the request and response body. This gives a high-level audit trail without exposing sensitive payload data. In the rule, the level field set to Metadata makes this the exact outcome.

Audit logging levels are defined inside an audit policy YAML, and the kube-apiserver only emits audit events when started with --audit-policy-file pointing at that file. The policy's rules set the Metadata level for the relevant request stages, so this flag is the mechanism that enables the required logging.

readOnlyRootFilesystem mounts the container's root filesystem read-only at the kernel level, so any write syscall to a path on it returns EROFS. The process receives an error rather than the write silently succeeding or the pod restarting.

ctr is the native CLI for containerd, speaking directly to containerd's gRPC API over its Unix socket (e.g., /run/containerd/containerd.sock). It can list, create, and exec into containers, manage images, snapshots, and tasks without going through Kubernetes or the kubelet. Because it bypasses the CRI layer, it is an invaluable debugging and forensics tool for containerd-based nodes, though it only works when the runtime is containerd and is not suitable for managing CRI-only abstractions like pods.

This audit stage fires when the HTTP server begins writing the response headers to the client, making it the earliest point at which the response's status code and headers are available. For a question asking which stage captures the beginning of the response, this is the correct choice because it records the event before the body is fully streamed. It is particularly useful for tracking latency and status decisions without waiting for the entire payload.

kubectl logs -f my-pod is the correct way to view live logs because the -f (or --follow) flag keeps the connection open and streams new log lines as they arrive, similar to tail -f. It first outputs the most recent logs (unless --tail is explicitly set) and then continues printing any subsequent output from the container's stdout/stderr until you interrupt it. This is the canonical command for real-time log monitoring in Kubernetes.

This policy selects the compromised pod and specifies egress: [] as an empty list. An empty egress rule list is a deny-all: since no destinations are allowed, all outbound traffic from that pod is blocked. With an egress list present, policyTypes defaults to Egress, so this rule is enforced; any additional egress allowances must be added in separate policies, which are ORed. This provides immediate containment of the suspicious outbound activity.

The open (or openat) syscall is the first system call issued when a process requests access to a file; Falco's evt.type=open matches both. fd.name=/etc/shadow filters for the exact pathname, so this condition triggers as soon as the file is opened, regardless of whether any read operation actually follows. This is the canonical Falco pattern (e.g., the 'Read sensitive file' rule) because it captures the clear intent to access the file at the syscall boundary.

The connect syscall establishes a connection between a socket and a remote address; for curl, this is the exact moment the TCP handshake begins with the destination web server. When tracing system calls, connect is the first syscall that carries the remote IP and port, so it directly identifies the outbound HTTP request. Thus, of the listed options, connect is the correct syscall to monitor for this network activity.

The Kubernetes audit system defines exactly four stages at which an event can be recorded: RequestReceived, ResponseStarted, ResponseComplete, and Panic. RequestReceived occurs immediately when the API server receives a request, ResponseStarted happens after response headers are sent but before the response body, ResponseComplete after the full response is sent, and Panic if a panic occurs while handling the request. Because these stages are captured in the audit policy rules, operators can choose to log only certain stages, such as logging RequestReceived for all requests and ResponseComplete for mutating requests.