CCNA Cks Monitoring Runtime Questions

The condition matches execve system calls where the executed process is bash and the container ID is not the host, so it fires on shells spawned inside containers. This detects interactive or scripted bash execution within containerised workloads, not host-level bash.

securityContext.readOnlyRootFilesystem is a boolean field within a container's security context. When set to true, it mounts the container's root filesystem as read-only, blocking any writes to the container layer. This forces all writable data to be stored in explicitly mounted volumes, such as emptyDir or persistent volumes, which is a key security hardening measure.

WARNING is one of the eight valid Falco priorities, sitting between NOTICE and ERROR in the severity ordering. It is intended for events that are security-relevant and should be surfaced to operators, but are not as severe as an error or critical condition. For example, spawning a new shell inside a running container without a known parent process is often assigned WARNING priority to alert on potential lateral movement without flooding the alerting pipeline. It is a suitable default for many behavioral rules that warrant attention but not immediate incident response.

The `priority` field indicates the severity level of the event that the rule generates, using Falco's enumerated values from DEBUG (lowest) to EMERGENCY (highest). It is unrelated to the condition, output, or rule name, and it allows operators and integrated systems to apply different response thresholds, such as suppressing low-severity notifications or escalating high-severity alerts to pager escalation.

Setting readOnlyRootFilesystem: true causes the container runtime to mount the container's root filesystem as read-only, so the write layer is not writable from the container's perspective; any attempt to modify an existing file or create a new file in the root directory tree will fail with EROFS. This directly prevents an attacker who compromises the container from persisting changes in the container layer, though ephemeral writes can still be accommodated by mounting volumes (e.g., emptyDir) at specific paths such as /tmp. It is the only option among those listed that enforces the filesystem-level read-only requirement.

This rule precisely targets a containerized process attempting to read /etc/shadow, the file that stores password hashes on most Linux systems. The condition container.id != host is essential because it restricts the match to events originating from containers, excluding the host itself. This combination avoids false positives from legitimate admin actions while capturing the exact behavior indicative of credential harvesting in a container.

When the audit policy level is set to Request, the Kubernetes API server logs a structured audit event containing the full request metadata and the raw request body. This level sits between Metadata, which omits the body, and RequestResponse, which additionally includes the response body. It is the correct behavior for a policy configured with the Request level, matching the official audit level specification.

`readOnlyRootFilesystem: true` is a container securityContext field that instructs the container runtime to mount the container's root filesystem as read-only (typically using a read-only overlay). Any attempt to write to the root filesystem will fail with an error unless a writable volume is mounted at a specific path, such as an `emptyDir` for temporary data. This directly satisfies the requirement to make the container's filesystem immutable, and it is the standard Kubernetes‑native way to achieve that guarantee.

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.

ResponseStarted is a valid audit stage that is recorded when the HTTP response headers are sent by the kube-apiserver to the client. This stage fires before the response body is fully transmitted, making it useful for observing when a request has begun to be served, especially for long-running or streaming requests.

Falco evaluates the condition against every execve event, and the proc.name!=bash filter excludes only processes named bash. No namespace field appears in the condition, so container and host executions alike trigger the CRITICAL alert, matching the option's scope exactly.

This is correct because a NetworkPolicy with a podSelector that matches only the compromised pod and contains no ingress or egress rules creates a default-deny policy for that pod alone. Under Kubernetes NetworkPolicy semantics, any selected pod with no matching rules is isolated: all inbound and outbound traffic is dropped, including DNS and cluster traffic. The policy does not alter the pod itself, so it preserves the running state and evidence. This is the standard, least-privilege method for isolating a single pod without disturbing the rest of the namespace.

In Falco, proc.pname contains the name of the parent process of the event's process. This field is particularly valuable for detecting suspicious subprocess spawning: a shell like 'bash' is frequently launched by an application (e.g., a web server or a Kubernetes controller) rather than directly by a user. If a rule checks proc.pname for a known parent binary (such as 'nginx' or 'java') and proc.name for 'bash', it can flag a shell being spawned by an unexpected parent. Since proc.pname gives the immediate ancestor, it is a valid Falco field for writing shell-detection rules.

This NetworkPolicy correctly restricts inbound traffic: the `policyTypes` list explicitly includes `Ingress`, and the `ingress` rule uses a `podSelector` with `matchLabels: app: frontend`. This `podSelector` in the `from` field matches only source pods that carry the label `app=frontend` within the same namespace. Because a NetworkPolicy that selects a pod enforces default-deny for the specified policy types, this rule whitelists exactly the intended frontend pods while blocking all other ingress sources.

RequestResponse is the most verbose audit level. For any rule matched at this level, the audit event includes the complete request object and the complete response object, each with both metadata and body payloads. This includes the full submitted resource state and the returned status/object, so all request and response information is logged as the option correctly states.

A NetworkPolicy that selects the compromised pod and specifies an empty egress rule list (e.g., `egress: []`) enforces a default-deny model for all outbound traffic. Because NetworkPolicy rules are additive—only traffic explicitly allowed by a matching rule passes—an empty list allows nothing, effectively containing the pod while preserving its state for forensics. For this to work, the cluster must run a CNI that implements NetworkPolicy, such as Calico, Cilium, or Weave Net. Alternatively, setting `policyTypes: [Egress]` with no egress rules achieves the same isolation.

The ipBlock with CIDR 10.0.0.5/32 precisely identifies the database's IP address, and the port 5432 restricts traffic to the database listener, thereby permitting only the intended communication. Because policyTypes includes Egress and this is the sole egress rule, it also establishes an implicit default-deny for any other outbound traffic, aligning with least-privilege security. This is the correct configuration for allowing egress to a specific external IP and port.

The Localhost AppArmor type requires the named profile to already be loaded into the kernel on the node where the pod runs. The kubelet does not load profiles from the manifest; it only references them. Running apparmor_parser to load k8s-nginx on each eligible node makes the profile available so the runtime can apply it and the container can start.

Taking a memory dump preserves volatile artifacts—such as running processes, network socket states, environment variables, and injected attack code—that disappear permanently when the container stops. Capturing this snapshot before any other forensic or remediation action allows investigators to run offline analysis against the exact memory image, potentially revealing the initial exploit and any in-memory resident payloads. Using tooling like `docker exec` with `/proc` access or dedicated memory capture utilities ensures the live state is frozen without altering the container.

This is the correct Falco rule: it captures the open syscall specifically on /etc/shadow, uses the exact file path to avoid false positives from /etc subdirectories, and filters on the O_RDONLY flag to select only read-only opens. Attackers almost always open the shadow file with O_RDONLY to dump its contents, so this rule reliably surfaces those attempts while ignoring legitimate administrative writes that use O_WRONLY or O_RDWR. The result is a focused, high-signal detection rule.

The open syscall is the actual attempt to access a file; checking evt.type=open with an exact fd.name=/etc/shadow ensures the rule fires when any process tries to open the shadow password file, whether or not the subsequent read occurs. This catches both successful reads and denied attempts, making it the precise detection predicate.

A NetworkPolicy that selects the compromised pod and has no ingress or egress rules enforces a default-deny policy for that pod, immediately cutting off command-and-control and lateral movement. This is a nondestructive containment action that preserves the pod's filesystem and live state for subsequent forensic collection. Ensure your CNI plugin (e.g., Calico, Cilium) actually enforces the policy—otherwise the rule will be silently ignored.

A successful kubectl exec starts a shell only if the container image contains that shell binary; the readOnlyRootFilesystem flag does not block process creation. Once the shell is running, it inherits the container's read-only root mount, meaning operations like touch /file or redirecting output to /root/out.txt will fail with a read-only file system error. Only paths backed by writable volumes defined in the pod spec, such as emptyDir or a mounted persistent volume, will accept writes.

None is a valid and correct Kubernetes audit level. When set in an audit policy rule, None means that no audit event is logged for requests that match that rule. It is commonly used to exclude high-noise, low-risk endpoints such as health checks, static assets, or service account token requests. Using None for specific rules helps reduce storage and performance overhead while still logging important actions at other levels.

Loading a kernel module involves the init_module or finit_module system calls. Falco can detect these by matching evt.type against those syscall names. This condition directly targets the kernel module loading activity, making it the correct choice for detecting when a container attempts to load a kernel module into the host kernel.

ctr is containerd's native CLI that connects directly to the containerd daemon through its gRPC socket, typically /run/containerd/containerd.sock. It operates below the CRI layer and can access containerd's low-level primitives such as images, snapshots, tasks, and namespaces, providing direct and unabstracted interaction with the container runtime on the host. On many Kubernetes nodes, containerd is the underlying runtime, so ctr is a legitimate direct tool, though it requires explicit namespace knowledge when inspecting pod containers.

WARNING is a valid Falco priority and represents a mid-to-high severity condition that should be investigated but does not necessarily require immediate emergency response. It sits between NOTICE and ERROR in Falco's syslog-compatible priority ladder. For example, detecting a shell inside a container often uses WARNING or NOTICE depending on policy.

Running `kubectl logs <pod>` and `kubectl describe pod <pod>` only retrieves the current container's stdout/stderr logs and pod metadata from the API server. These commands do not access the container's filesystem, process state, or previous terminated container instances, so critical forensic artifacts like binary payloads, configuration changes, or crash evidence remain hidden. Furthermore, they capture live data that can change during investigation, making them unsuitable for preserving a reliable evidentiary snapshot.

Seccomp evaluates rules in order and applies the first matching rule, so an early broad allow for the syscall group can shadow the later errno rule. Combined with CAP_SYS_MODULE, which grants the capability needed to load modules, the container bypasses the intended block. Reordering the deny rule above the allow and dropping the capability closes the gap.

Applying a NetworkPolicy isolates the compromised pod by restricting ingress and egress traffic, satisfying the containment requirement during incident response. This prevents lateral movement to other workloads while preserving the pod for forensic analysis, rather than deleting it immediately. NetworkPolicy enforcement depends on a CNI plugin that supports it, such as Calico or Cilium.

Audit rules are evaluated in order and the first matching rule wins, so a specific rule for secrets at RequestResponse captures both request and response bodies for Secret changes. The later catch-all at Metadata keeps the rest of the traffic lightweight. This ordering and level pairing is exactly what the requirement describes.

This is correct because `connect` is the syscall invoked whenever a process initiates an outbound TCP connection (and can also set a default peer for UDP), making it the ideal hook for detecting unexpected egress. The `container.id != host` condition ensures only events from containers are evaluated, excluding host-level connections. The `not fd.snet in (...)` clause excludes RFC1918 private ranges and loopback, so the rule only fires when a container connects to a public IP, i.e., an actual outbound internet connection.

crictl logs retrieves stdout/stderr output for a given container ID from the runtime, optionally with --tail or --follow. It satisfies the requirement to inspect a specific container's logs when debugging via the CRI rather than the kubelet.

Falco's rule condition language supports boolean operators like 'and not' to exclude specific events. Adding 'and not fd.name = /etc/app/config' will prevent alerts when the file descriptor name exactly matches that path, while still triggering for other writes under /etc. This is the precise way to create an exception for a known legitimate file.

The Request audit level provides all the metadata fields from the Metadata level and also includes the request body, enabling an administrator to see the exact payload the client submitted. It deliberately omits the response body, so the audit log does not capture what data the apiserver returned. This makes Request the precise answer for the question, which asks for request metadata plus the request body.

The Metadata audit level logs request metadata such as the user, groups, verb, resource, source IP, and response status, but it deliberately omits both request and response bodies. This is the correct choice for logging all requests because it provides a complete record of who did what and when for security review, without capturing the sensitive contents that would be written to disk. It is the recommended level in the Kubernetes audit policy as the default catch-all, balancing security, compliance, and data minimization.

The kube-apiserver's audit logging behavior is governed by a YAML policy file located on the apiserver's host filesystem, whose path is passed via the `--audit-policy-file` startup flag. This file is not a Kubernetes API resource; it is a plain configuration file containing a set of rules that map requested attributes (verbs, resources, namespaces, users) to audit levels: None, Metadata, Request, or RequestResponse. The apiserver reads this file at initialization and applies it to all incoming API requests, so changing the policy requires editing the file and restarting the apiserver.

Applying a NetworkPolicy that selects the compromised pod's labels and declares policyTypes: [Ingress, Egress] with no ingress or egress rules establishes an immediate default-deny boundary. The CNI enforces this at the data path, blocking all existing and new connections while leaving the pod and its logs, memory, and filesystem untouched for forensic analysis. This is the correct incident response because it contains the blast radius without destroying evidence.

This sequence starts at WARNING and moves through ERROR, CRITICAL, ALERT, and EMERGENCY, which exactly matches Falco's ascending severity ranking for those levels. Each step denotes a progressively more serious security event, from a notable anomaly to a system-wide emergency requiring immediate response.

The `condition` field in a Falco rule is the mandatory boolean filter expression that actually defines which events trigger the rule. For shell detection, it combines syscalls such as `evt.type=execve` with process and container fields (e.g., `proc.name in (bash, sh)` and `container.id != host`) to match a shell being opened inside a container. No other rule field performs event matching, so this is the correct place to encode the detection logic.

Setting readOnlyRootFilesystem to true mounts the container's root filesystem as read-only, so any attempt by the container process to write, create, or delete files in / fails. This makes the root filesystem effectively immutable from the container's perspective because all write operations are blocked at the mount layer. Note that volumes can still be mounted writable, so immutability applies only to the root filesystem itself, not to data volumes.

securityContext.readOnlyRootFilesystem: true mounts the container's root filesystem with read-only permissions, so any process inside the container cannot write to the root filesystem at all. This directly enforces immutability of the core container filesystem, which is exactly what this question requires. Note that ephemeral volumes like emptyDir can still be mounted to provide writable directories, so the setting is compatible with workloads that need temporary storage.

This policy selects all pods in the namespace via podSelector: {} and permits egress traffic specifically to the database IP on TCP port 3306, which is the MySQL port mentioned in the scenario. By including both the destination IP and the exact port, it follows least privilege and directly restores the pod's ability to reach the external data source while blocking other outbound traffic.

This is the correct flag because it supplies the audit policy YAML that filters and selects which user requests, stages, and response levels are logged by the kube-apiserver. The policy file contains rules with verbs, resources, and audit levels, and it is the mandatory component to enable any audit logging. All other flags, such as log or webhook backends, are secondary and depend on this policy being present.

crictl ps is the correct CRI-compatible command to list running containers on a node. By default it shows only currently running containers, mirroring docker ps, and with -a it includes exited ones. It retrieves the container list from the CRI runtime socket (e.g., containerd, CRI-O) and displays fields such as container ID, image, created time, and status.

Incorrect: kubectl get events shows Kubernetes Event objects, not API server audit logs, and does not display exec audit entries.

ResponseComplete is emitted only after the entire HTTP response has been sent to the client, meaning the audit event now carries the final status code, response size, and all processing results. This is the stage at which every phase of request handling—authentication, authorization, admission, and execution—has finished, making it the correct stage for auditing the complete outcome of a request. Without waiting for this stage, an audit log could miss failures or side effects that occur after the initial response begins.

Running 'kubectl exec <pod> -- tcpdump -i eth0' is the correct immediate investigation step because it captures raw network packets directly from the pod's network interface, revealing destination IPs, ports, protocols, and payloads of ongoing communication. This live capture provides the forensic evidence needed to understand the attacker's command-and-control traffic or data exfiltration in real time. However, tcpdump must be installed in the container image and the container must have the necessary privileges, such as CAP_NET_RAW or root access, which may require using an ephemeral container if the tools are missing.

The `open` syscall is the initial operation that must occur before any file content can be read or modified; when a process calls `open` on `/etc/shadow`, Falco's `fd.name` is populated directly from the path argument, making this condition both reliable and comprehensive. This rule detects any attempt to open the shadow file, regardless of the intended operation (read, write, or execute) and regardless of the process name or container name. It is the precise, minimal condition that catches unauthorized access to sensitive credential files, and it is the standard cornerstone for such Falco rules.

This is the correct and dedicated Falco CLI flag for specifying one or more rules files (`-r /path/to/rules.yaml`). It tells Falco to load the provided YAML rule file in addition to or instead of the default rules, depending on how it is used. Running the command with `-r` will make Falco read the custom rules and apply them to the event stream.

kubectl exec -it pod-name -- /bin/bash starts a new process inside the already-running container, sharing its mount namespace, PID namespace, and network stack. This gives you direct access to the live filesystem, running processes, and environment variables exactly as they exist in the compromised pod, enabling immediate forensic evidence collection. This is the standard method for interactive shell access to an existing container and is the correct approach for investigating a compromise.

kubectl exec -it <pod> -- /bin/sh launches a new /bin/sh process inside the container's namespaces via the kubelet and container runtime. The -i flag keeps STDIN open, -t allocates a pseudo-TTY, and the command after -- is executed directly as a new process in the container. This is the canonical way to get an interactive shell in a running pod's primary container for debugging.

Using kubectl cp is correct because it reads the container's filesystem through the container runtime and produces a tar archive in a safe location without modifying the source files; the command uses tar and writes to stdout, so the container's storage layer is left untouched for subsequent analysis. This preserves evidence such as dropped payloads, shell history, modified binaries, and configuration files, and it can be performed quickly even while the container remains running. Be aware that kubectl cp does not capture memory or /proc, but for filesystem artifacts it is the advisable first step before any destructive containment.

crictl logs <container-id> is the correct command because it directly retrieves the container's stdout/stderr streams through the CRI (Container Runtime Interface). It functions analogously to 'docker logs', letting you inspect application output for debugging or monitoring, and it reads from the runtime's buffer for the specified container.

Request level is the correct configuration: it captures audit event metadata (e.g., user, source IP, verb, resource) and the complete request body. This gives deep visibility into exactly what the client sent, while intentionally omitting the response data to reduce storage and sensitive-data exposure. Because the question explicitly specifies level 'Request', this is precisely what gets logged.

This is the correct command. It fetches the log output of the specified container, capturing what the container wrote to stdout/stderr as captured by the container runtime (e.g., containerd). It works similarly to `docker logs` and is the standard way to view container logs in a CRI-compatible environment. The container ID can be obtained from `crictl ps`, and the command shows both historical and, with `-f`, live logs.

Using `kubectl cp` to copy the container’s filesystem is a forensically sound step because it preserves the writable layer, arbitrary files, and binaries without altering the running state. This offline copy lets you analyze the image, look for persistence mechanisms (e.g., cron jobs, backdoors), and inspect configuration files while the container remains responsive. Because `kubectl cp` reads the live filesystem, it is non-destructive and is a best practice before any termination decision. It also gives you a baseline for detecting changes if you later compare with the original image.

Applying a NetworkPolicy YAML is the correct method because this API resource is designed to select pods by label and restrict their ingress and egress traffic. A properly written manifest with a podSelector matching 'app=malicious' and policyTypes: [Ingress, Egress] but no ingress/egress rules creates a default-deny rule for that pod, blocking all inbound and outbound connections non-destructively. kubectl apply is also idempotent and the only reliable way to declare such a policy, since kubectl does not offer a native 'create networkpolicy' command.

RequestResponse records the full request and response bodies alongside metadata, satisfying the requirement to audit complete API request content. Lower levels such as Metadata or Request omit response bodies entirely, so they cannot capture the payloads the admin needs. This level therefore provides the body-level detail the stem explicitly demands.

The setuid syscall is the kernel API that changes the process's effective (and optionally real) user ID, and it is the direct primitive used in a privilege-escalation attack when a process transitions from an unprivileged UID to a privileged one such as root. Because an exploit often invokes setuid (or one of its variants like seteuid) to permanently or temporarily raise privileges, Falco can catch credential-state changes by filtering on this syscall. In a Falco rule for privilege escalation, setuid is the semantically correct event to monitor, since it represents the moment of privilege elevation, not just a side effect.

crictl exec is the correct choice because it lets you run a command inside the container via the container runtime (containerd/CRI-O), such as `crictl exec -it <container-id> ss -tpn` or `netstat -an`, to inspect active TCP/UDP connections initiated by the container. Unlike `kubectl exec`, it works directly against the runtime, even if the Kubernetes API server is unreachable. This allows you to see the exact source, destination, and process for each outbound connection.

If the container's main command exits with a non-zero code immediately after startup, the kubelet sees a stopped container and, with the default restartPolicy of Always, schedules another attempt. Each restart fails again, and the kubelet applies exponential backoff, eventually reporting CrashLoopBackOff. This is the exact scenario the exam question refers to: a successfully launched container that fails at runtime, not a scheduling or image-pull problem.

crictl ps is correct because, like `docker ps`, it lists the currently running containers managed by the container runtime, showing the container ID, image, state, and name. Once you have the container ID from `crictl ps`, you can use `crictl inspect` or `crictl exec` to enumerate actual processes, making it the essential starting point for investigating a suspected unexpected process in a Kubernetes node's container.

The rule fires on process-spawn events inside containers where the executable is bash and the parent process name is not sshd. This matches interactive shells launched by kubectl exec, docker exec, or exploited entrypoints, satisfying the stem's condition that the parent process is anything other than sshd.

Falco monitors the connect() syscall as applications initiate TCP or UDP outbound traffic, so an unexpected destination IP, port, or domain pattern for a given container image can signal data exfiltration or command-and-control activity. Unlike high-level metrics, this is a definitive, event-level behavioral indicator because it captures the exact moment a new network connection is established, and allows correlation with process context.

The scheduler computes the sum of CPU requests for existing pods and compares it against each node's allocatable CPU capacity. If the requested CPU for this pod is greater than any node's available (allocatable minus already requested) CPU, the scheduler emits a FailedScheduling event with 'Insufficient cpu' and lists the nodes that could not fit. As a result, the pod remains Pending until a node's resources change or the request is reduced. This is exactly the situation indicated by an Insufficient cpu event.

The correct fix is to create a dedicated emptyDir volume and mount it at /tmp. When readOnlyRootFilesystem is true, the container's root filesystem is mounted with the MS_RDONLY flag, so every write attempt to any path on that filesystem returns EROFS — regardless of permissions. An emptyDir volume provides a separate, writable filesystem (initially empty, typically backed by the node's disk or tmpfs) that can be mounted exactly where the application expects to write temporary data, allowing the container to work while preserving the immutability of the root filesystem.

This is the exact Falco rule needed: it combines the execve syscall (new process execution), proc.name = bash (the shell binary), and container.id != host (restricting to container events). The combination logically isolates the moment a bash shell is spawned from inside a container while excluding host-level bash runs, giving a high-fidelity signal for interactive shell activity. Because it checks the syscall that actually creates the process, it correctly captures shell starts rather than related but distinct activities like file reads or network connections.

Taking a memory dump preserves the ephemeral volatile data that exists only inside the running container's user-space processes and its shared host kernel view. Tools like `gcore` on the container PID, or CRIU-based dump, capture open file descriptors, decrypted secrets, injected shellcode, and active network socket states that vanish when the container stops. This is critical for detecting in-memory-only attacks (e.g., process hollowing) that leave no disk footprint, and it should be performed before the container is terminated or filesystem is altered.

crictl is a CLI that communicates with a CRI-compliant runtime via a gRPC endpoint, and it must be told where that runtime's socket lives via the --runtime-endpoint flag or a configuration file such as /etc/crictl.yaml. If it points to a default or stale socket (for example /var/run/dockershim.sock instead of /run/containerd/containerd.sock), it will not see the containers managed by the actual containerd or CRI-O runtime. Even though pods are running, a misconfigured runtime endpoint commonly produces a misleading empty list or a connection error, so this is the correct explanation.

ResponseComplete is emitted after the API server has sent the entire HTTP response, including the body, to the client. This stage means all processing phases — authentication, authorization, admission, and any mutation or storage operations — have finished and the complete response payload has been transmitted. It is the definitive final audit stage for a fully processed request, making it the correct answer.

This rule is correct because 'execve' is the fundamental Linux syscall that executes a new program by replacing the caller's memory image. In Falco, for an 'execve' event, 'proc.name' is the basename of the new executable, so filtering for 'bash' or 'sh' directly matches the execution of those shell binaries. This aligns exactly with the intended goal of detecting an attempt to run a shell, and it intentionally ignores file access and process creation events that do not themselves indicate shell execution.

With readOnlyRootFilesystem: true, any write to a path outside a mounted writable volume returns EROFS (read-only file system). Since /var/log/app.log is inside the container's root filesystem and no volume is mounted at /var/log, the application cannot create or append to that file. The application may catch the error and continue, log to stderr, or exit if log failure is fatal, which would cause the container to crash or be marked as failed.

The `RequestResponse` audit level logs the request metadata, the request body, and the response body for matching requests, providing a complete record of the API interaction. This is the only level that enables full reconstruction of what was sent and what the API server returned, including the exact object created, updated, or returned in error. Because it includes potentially sensitive data from both sides, it should be applied selectively (e.g., to Secrets or `exec` endpoints) and is the most resource-intensive level in terms of storage and performance.

RequestResponse is a valid audit level that captures the full request and response objects, including the body content, in addition to all metadata. It is one of the four levels defined by Kubernetes (None, Metadata, Request, RequestResponse) and is the most verbose level available. This level is useful for deep debugging but can produce a large volume of logs, so it should be used selectively.