Courseiva

CCNA Monitoring Logging and Runtime Security Questions

18 questions · Monitoring Logging and Runtime Security · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

A security team wants to detect anomalous process executions in containers without modifying the container images or requiring agents inside containers. Which approach is most suitable?

A.Configure CRI-O to log all container process starts to syslog.
B.Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.
C.Enable Kubernetes audit logging and parse the logs for process events.
D.Use OPA Gatekeeper to enforce allowed process lists in pod specs.
AnswerB

Falco on the host can detect container process anomalies without modifying images.

Why this answer

Falco, deployed as a DaemonSet with an eBPF probe, can monitor system calls at the kernel level without modifying container images or requiring agents inside containers. This allows it to detect anomalous process executions in real time by analyzing syscall events from the host, which is the most suitable approach for runtime security monitoring in Kubernetes.

Exam trap

CNCF often tests the distinction between admission control (e.g., OPA Gatekeeper) and runtime monitoring (e.g., Falco), where candidates mistakenly choose a policy enforcement tool for detection tasks.

How to eliminate wrong answers

Option A is wrong because CRI-O does not natively log all container process starts to syslog; it manages container runtime operations but lacks built-in process-level auditing. Option C is wrong because Kubernetes audit logging captures API server requests (e.g., pod creation), not process executions within containers, so it cannot detect anomalous process starts. Option D is wrong because OPA Gatekeeper enforces admission control policies on pod specs (e.g., allowed process lists) but does not monitor runtime behavior or detect anomalies after a container is running.

Practice this question →
2
Multi-Selecthard

A security engineer runs kube-hunter against a production cluster and receives the above output. The cluster uses kubeadm with default settings. Which two actions should the engineer take to remediate the vulnerabilities?

Select 2 answers
A.Upgrade the cluster to Kubernetes 1.14 or later to fix CVE-2019-11245
B.Set the kubelet flag --authentication-token-webhook=true
C.Configure the kubelet to set --anonymous-auth=false and restart the kubelet service
D.Enable the NodeRestriction admission controller
E.Modify the kube-apiserver manifest to set --anonymous-auth=false
AnswersA, C

The vulnerability is fixed in kubelet versions 1.13.9+, 1.14.5+, and 1.15.2+.

Why this answer

Option A is correct because CVE-2019-11245 affects kubelet container runtime exec probes in Kubernetes versions prior to 1.14, where containers could restart unexpectedly due to a race condition. Upgrading to 1.14 or later patches this vulnerability. Option C is correct because setting --anonymous-auth=false on the kubelet disables unauthenticated access to the kubelet API, which is a common finding from kube-hunter when default kubeadm settings leave anonymous authentication enabled.

Exam trap

The trap here is that candidates confuse the kubelet's anonymous-auth flag with the API server's anonymous-auth flag, or think that enabling webhook authentication alone (Option B) disables anonymous access, when in fact anonymous auth must be explicitly disabled on the kubelet.

Practice this question →
3
Drag & Dropmedium

Arrange the steps to configure and use kube-bench to audit a Kubernetes cluster's security.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

kube-bench audits CIS benchmarks. After installation, run it, analyze results, remediate, and re-audit.

Practice this question →
4
Drag & Dropmedium

Order the steps to recover a Kubernetes cluster after a control plane failure where the API server certificate has expired.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps
Order

Why this order

Recovery involves identifying expired certs, renewing, restarting components, verifying, and updating configs.

Practice this question →
5
Multi-Selecthard

Which THREE practices help ensure the integrity and confidentiality of container logs in a Kubernetes cluster?

Select 3 answers
A.Configure the log collector to use TLS when shipping logs to a central system.
B.Set container 'stdout' logging only, avoiding file-based logs.
C.Store logs in a backend that supports encryption at rest (e.g., S3 with SSE).
D.Run log collectors in a dedicated namespace with network policies limiting access.
E.Disable log rotation to prevent log tampering during rotation.
AnswersA, C, D

TLS encrypts logs in transit.

Why this answer

Option A is correct because configuring the log collector to use TLS (e.g., Fluentd with TLS output plugin or Filebeat with SSL/TLS) encrypts log data in transit, preventing eavesdropping or tampering during shipping to a central system like Elasticsearch or Splunk. This directly protects confidentiality and integrity against man-in-the-middle attacks on the network path.

Exam trap

CNCF often tests the misconception that disabling log rotation improves security, but in reality, rotation is a standard operational practice that does not inherently compromise integrity; the trap is confusing operational controls with security controls.

Practice this question →
6
MCQeasy

A DevOps engineer notices that a container's stdout logs are not appearing in the `kubectl logs` output. The container runs a legacy application that writes logs to a file inside the container. What is the most efficient way to capture these logs without modifying the application?

A.Configure the kubelet to rotate logs from the container's filesystem.
B.Add a sidecar container that reads the log file and outputs to stdout.
C.Use `kubectl cp` to periodically copy logs from the container.
D.Install a syslog daemon in the container to forward logs.
AnswerB

The sidecar pattern streams file logs to stdout for kubectl logs.

Why this answer

Option B is correct because deploying a sidecar container that tails the log file and writes to its own stdout is the most efficient, Kubernetes-native pattern for capturing logs from applications that write to files. The sidecar container shares the same Pod and volume, reads the log file (e.g., using `tail -F`), and outputs to stdout, which is then collected by `kubectl logs` and the cluster-level logging pipeline. This approach requires no modification to the legacy application and leverages the existing container runtime and kubelet log collection.

Exam trap

CNCF often tests the sidecar logging pattern as the standard Kubernetes solution for capturing file-based logs, and the trap here is that candidates may incorrectly choose kubelet log rotation (Option A) thinking it applies to all container logs, when in fact it only applies to the container runtime's own stdout/stderr streams.

How to eliminate wrong answers

Option A is wrong because the kubelet handles log rotation only for container stdout/stderr streams, not for files written inside the container's filesystem; it cannot rotate arbitrary application log files. Option C is wrong because `kubectl cp` is a manual, non-scalable operation that requires external orchestration and does not provide real-time log streaming to `kubectl logs`. Option D is wrong because installing a syslog daemon inside the container would require modifying the container image or running additional processes, which contradicts the requirement of not modifying the application and adds unnecessary complexity.

Practice this question →
7
Multi-Selecteasy

An auditor requires that all audit logs from the Kubernetes API server be stored for 90 days and be tamper-proof. Which TWO measures should be implemented?

Select 2 answers
A.Configure the audit log backend to write to an immutable object store like S3 with Object Lock
B.Enable the AuditDynamicConfiguration feature gate
C.Deploy Fluentd to forward logs to a central Elasticsearch cluster
D.Set the API server flag --audit-log-maxage=90
E.Set --audit-log-maxbackup=10 and --audit-log-maxsize=100
AnswersA, D

Immutable storage prevents log modification or deletion.

Why this answer

Option A is correct because storing audit logs in an immutable object store like S3 with Object Lock ensures tamper-proof retention by preventing any object from being overwritten or deleted for a specified retention period. This directly satisfies the auditor's requirement for logs that cannot be altered or destroyed, regardless of the Kubernetes cluster state.

Exam trap

CNCF often tests the distinction between log rotation/retention settings (like --audit-log-maxage) and true immutability features, leading candidates to incorrectly select options that only manage log file age without preventing tampering.

Practice this question →
8
MCQeasy

A cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?

A.Configure Fluentd to collect network logs from each node.
B.Use Prometheus to scrape network metrics from kube-proxy.
C.Run kube-bench to audit network policies.
D.Deploy Cilium with Hubble for network flow visibility.
AnswerD

Cilium/Hubble provides pod-level network monitoring.

Why this answer

D is correct because Cilium, combined with Hubble, is specifically designed to provide deep network flow visibility and monitoring for Kubernetes pods. Hubble leverages eBPF to capture and report network traffic at the kernel level, offering granular observability into pod-to-pod communications, which directly meets the requirement for security analysis of network traffic between pods.

Exam trap

The trap here is that candidates may confuse general monitoring tools (Fluentd, Prometheus) or security auditing tools (kube-bench) with a purpose-built network flow visibility solution like Cilium/Hubble, which is the only option that directly addresses pod-to-pod traffic monitoring for security analysis.

How to eliminate wrong answers

Option A is wrong because Fluentd is a log collector and aggregator, not a network traffic monitoring tool; it collects log files (e.g., from containers or applications) but does not capture or analyze network flows between pods. Option B is wrong because Prometheus scrapes metrics (e.g., from kube-proxy for iptables rules or service endpoints) but does not provide real-time network flow visibility or capture individual packet-level communications between pods. Option C is wrong because kube-bench is a compliance auditor that checks Kubernetes clusters against CIS benchmarks, focusing on configuration security, not on monitoring live network traffic between pods.

Practice this question →
9
MCQhard

An organization uses Kubernetes with multiple namespaces and wants to ensure that containers running as non-root cannot escalate to root via setuid binaries. Which combination of security contexts and Pod Security Standards achieves this?

A.Use an AppArmor profile to block setuid syscalls.
B.Apply the 'restricted' Pod Security Standard at the namespace level.
C.Set 'securityContext.runAsUser: 1000' on each pod spec.
D.Apply the 'baseline' Pod Security Standard with 'seccompProfile: RuntimeDefault'.
AnswerB

Restricted enforces runAsNonRoot and disallows privileged escalation.

Why this answer

The 'restricted' Pod Security Standard (PSS) enforces the strongest set of security constraints, including preventing containers from running as root and disallowing privilege escalation. Specifically, it requires `securityContext.allowPrivilegeEscalation: false` and prohibits running as root, which directly blocks escalation via setuid binaries. Applying this standard at the namespace level ensures all pods in that namespace inherit these controls, meeting the requirement.

Exam trap

CNCF often tests the misconception that simply running as a non-root user (e.g., `runAsUser: 1000`) is sufficient to prevent privilege escalation, but without `allowPrivilegeEscalation: false`, setuid binaries can still be exploited to gain root.

How to eliminate wrong answers

Option A is wrong because AppArmor profiles can block specific syscalls, but they are not the standard Kubernetes-native mechanism for preventing privilege escalation via setuid binaries; the question specifically asks for a combination of security contexts and Pod Security Standards, not a third-party tool. Option C is wrong because setting `runAsUser: 1000` only changes the user ID but does not prevent the container from using setuid binaries to escalate to root; it still allows privilege escalation unless `allowPrivilegeEscalation: false` is also set. Option D is wrong because the 'baseline' PSS does not enforce `allowPrivilegeEscalation: false`; it only prevents known privilege escalation paths like host namespaces but allows setuid binaries, and `seccompProfile: RuntimeDefault` alone does not block setuid escalation.

Practice this question →
10
MCQhard

You are a security engineer for a financial services company running a Kubernetes cluster with 50 nodes. The cluster uses containerd as the container runtime and Calico for networking. The security team has detected unusual outbound network connections from a pod running in the 'payments' namespace to an external IP address known to be a command-and-control server. The pod is part of a Deployment named 'payment-processor' with 3 replicas. The cluster has a Falco daemonset deployed with default rules, and audit logging is enabled for the API server. You need to quickly identify the compromised container and contain the threat. Which action should you take FIRST?

A.Use 'kubectl exec -it <pod> -- bash' to inspect the container, then kill the malicious process from within
B.Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods
C.Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod
D.Identify the node hosting the suspicious pod using 'kubectl get pod -o wide', then SSH to that node and use 'crictl ps' to list containers, then 'crictl stop' the container
AnswerD

This directly stops the specific container without affecting other replicas and preserves the ability to investigate.

Why this answer

Option D is correct because it follows the proper incident response workflow for a compromised container: first identify the node hosting the suspicious pod using `kubectl get pod -o wide`, then SSH to that node and use `crictl ps` (the containerd CLI) to list running containers and their IDs, then use `crictl stop` to immediately halt the compromised container. This approach directly isolates the threat at the container runtime level without relying on potentially compromised in-pod tools or deleting the pod (which could be recreated by the Deployment controller).

Exam trap

CNCF often tests the misconception that `kubectl delete pod` is sufficient for containment, but the trap here is that a Deployment controller will immediately recreate the pod, so you must either scale the Deployment to 0 (which destroys evidence) or directly stop the container at the runtime level using `crictl stop`.

How to eliminate wrong answers

Option A is wrong because using `kubectl exec -it <pod> -- bash` to inspect the container assumes the container has a shell and that the shell is not compromised; the attacker may have disabled or replaced `bash`, and any commands run inside could be tampered with or alert the attacker. Option B is wrong because scaling the Deployment to 0 replicas deletes all pods, destroying forensic evidence and potentially triggering the Deployment's restart policy or a ReplicaSet recreation, and it does not isolate the specific compromised container for investigation. Option C is wrong because Falco logs may not contain the exact pod name if the default rules do not capture outbound C2 traffic or if the alert is not triggered; additionally, `kubectl delete pod` will cause the Deployment controller to immediately recreate the pod, failing to contain the threat.

Practice this question →
11
Multi-Selectmedium

Which TWO actions are effective for detecting and preventing container breakout attempts using runtime security tools?

Select 2 answers
A.Set 'securityContext.seccompProfile.type: Unconfined' to allow all syscalls.
B.Enable Kubernetes audit logging to capture exec commands.
C.Use PodSecurityPolicy to deny privileged containers.
D.Deploy Falco with rules that alert on 'syscall' events like 'clone' or 'unshare'.
E.Apply a seccomp profile that blocks unneeded syscalls for each container.
AnswersD, E

Falco can detect breakout attempts via syscall monitoring.

Why this answer

Option D is correct because Falco is a CNCF runtime security tool that uses eBPF or kernel modules to intercept system calls. By alerting on sensitive syscalls like 'clone' (used to spawn new processes) or 'unshare' (used to create new namespaces), Falco can detect container breakout attempts where an attacker tries to escape the container's isolation. This provides real-time detection of anomalous behavior indicative of a breakout.

Exam trap

CNCF often tests the distinction between admission control (e.g., PodSecurityPolicy, OPA/Gatekeeper) and runtime security (e.g., Falco, seccomp, AppArmor), leading candidates to select admission-based options like PodSecurityPolicy when the question explicitly asks for runtime security tools.

Practice this question →
12
MCQhard

You are responsible for a production Kubernetes cluster running critical workloads. The cluster uses containerd as the container runtime. The security team has deployed Falco with default rules and it is running as a DaemonSet. Recently, the team noticed that several pods have been unexpectedly terminated by the OOMKiller. You suspect a container is performing a fork bomb attack, exhausting memory. You need to detect and prevent such attacks in real-time. Falco is already installed. Which single action should you take to best address this threat?

A.Enable the Falco rule that detects rapid process creation (fork bomb) and configure an alert.
B.Adjust the OOM score of critical pods to prevent them from being killed.
C.Apply a seccomp profile that blocks the fork and clone syscalls.
D.Set resource quotas on all namespaces to limit memory usage.
AnswerA

Falco has a built-in rule for fork bombs.

Why this answer

Falco's default rules include a rule for 'Fork Bomb' that detects rapid process creation by monitoring the `clone` and `fork` syscalls. Enabling this rule and configuring an alert allows real-time detection of fork bomb attacks, which is the most direct and effective action to address the threat. This leverages Falco's existing capability to identify anomalous syscall patterns without requiring additional tooling or configuration changes.

Exam trap

The trap here is that candidates may choose option C (blocking fork/clone syscalls) thinking it prevents the attack, but they overlook that this would break essential container functionality, whereas Falco's existing rule provides detection without breaking applications.

How to eliminate wrong answers

Option B is wrong because adjusting the OOM score of critical pods only influences which pod gets killed first when memory pressure occurs, but it does not detect or prevent the fork bomb attack itself; the attack would still exhaust memory and potentially kill other pods. Option C is wrong because applying a seccomp profile that blocks `fork` and `clone` syscalls would break legitimate container operations that rely on process creation (e.g., starting new processes, running scripts), making it an impractical and overly restrictive solution. Option D is wrong because setting resource quotas on namespaces limits total memory usage but does not detect or prevent a fork bomb in real-time; the attack could still cause OOM kills within the quota or affect other pods in the same namespace before the quota is enforced.

Practice this question →
13
MCQmedium

A DevOps team is deploying a new microservice that processes sensitive payment data. The security policy requires that all file system writes outside the /tmp directory be logged and alerted. Which runtime security tool and configuration best achieves this requirement with minimal performance impact?

A.Use Seccomp profiles to block write syscalls outside /tmp
B.Implement an OPA Gatekeeper constraint to reject pods that write outside /tmp
C.Deploy Falco with a rule: 'evt.type=open and evt.dir=< and fd.name startswith / and not fd.name startswith /tmp'
D.Configure AppArmor to deny writes outside /tmp
AnswerC

Falco monitors system calls and can generate alerts for file writes outside /tmp with minimal overhead.

Why this answer

Option C is correct because Falco is a runtime security tool that monitors system calls in real time. The provided rule specifically triggers an alert when a file is opened for writing (evt.dir=<) outside of /tmp, meeting the logging and alerting requirement with minimal performance impact since it only inspects syscalls without blocking them.

Exam trap

CNCF often tests the distinction between runtime monitoring (Falco) and enforcement tools (Seccomp, AppArmor, OPA Gatekeeper), and the trap here is that candidates choose blocking tools (A or D) or admission control (B) instead of the tool that specifically logs and alerts at runtime with minimal performance impact.

How to eliminate wrong answers

Option A is wrong because Seccomp profiles block syscalls at the kernel level, which would prevent the microservice from writing anywhere (including legitimate writes), and blocking syscalls has higher performance overhead than monitoring; also, Seccomp cannot selectively allow writes only to /tmp based on file path. Option B is wrong because OPA Gatekeeper is an admission controller that rejects pods at deployment time, but it cannot monitor or alert on runtime file system writes after the pod is running. Option D is wrong because AppArmor denies writes at the kernel level, which would block the writes entirely rather than logging and alerting, and it imposes a performance penalty on every write attempt.

Practice this question →
14
Multi-Selecteasy

You are auditing a cluster for runtime security best practices. Which TWO of the following actions are recommended to improve container runtime security?

Select 2 answers
A.Deploy Falco to monitor system calls and detect anomalous behavior.
B.Disable the container runtime's security engine to reduce overhead.
C.Run containers in privileged mode for better performance.
D.Enable seccomp profiles to restrict available system calls.
E.Set AppArmor to unconfined for all pods to avoid profile conflicts.
AnswersA, D

Falco is a standard runtime security tool.

Why this answer

Falco is a CNCF-graduated runtime security tool that uses eBPF or kernel modules to monitor system calls in real time, detecting anomalous behavior such as unexpected process execution or file writes. Deploying Falco is a recommended best practice for runtime security because it provides deep visibility into container activity without requiring application changes, and it can trigger alerts or actions based on customizable rules.

Exam trap

CNCF often tests the misconception that disabling security features (like seccomp or AppArmor) improves performance without understanding the severe security trade-offs, or that privileged mode is an acceptable performance tuning technique.

Practice this question →
15
MCQhard

A security auditor requires that all container images used in the cluster are scanned for vulnerabilities before deployment. The team uses a private registry with image signing. Which solution enforces that only signed and scanned images are deployed?

A.Use Cosign to sign images and deploy a webhook that verifies signatures.
B.Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.
C.Use OPA Gatekeeper to verify that the image comes from the private registry.
D.Enable Binary Authorization on the cluster to enforce image attestation.
AnswerA

Cosign admission controller can enforce signature verification at pod creation.

Why this answer

Cosign is a tool for signing container images, and deploying a validating webhook (e.g., the cosigned admission controller) enforces that only images with valid signatures are admitted. This directly meets the requirement to deploy only signed and scanned images, as the webhook verifies the signature before the pod is created.

Exam trap

CNCF often tests the distinction between admission-time enforcement (webhooks) and post-deployment scanning (CronJobs), and the trap here is that candidates confuse scanning with enforcement, or assume Binary Authorization is a generic Kubernetes feature when it is actually GKE-specific.

How to eliminate wrong answers

Option B is wrong because a CronJob scanning images and updating a ConfigMap does not enforce admission-time control; it only provides a reactive list of allowed images, which can be bypassed or become stale. Option C is wrong because OPA Gatekeeper verifying the registry origin (e.g., checking the image path) does not verify image signatures or scan results; it only ensures the image comes from the private registry, not that it is signed or scanned. Option D is wrong because Binary Authorization is a Google Cloud-specific service (GKE) and is not a generic Kubernetes-native solution; it is not available in a standard CKS cluster environment.

Practice this question →
16
Matchingmedium

Match each Kubernetes command to its function related to security.

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

Concepts
Matches

Check whether an action is allowed for a user or service account

Approve a certificate signing request (CSR)

Run a temporary interactive pod for troubleshooting

Create a secret from literals, files, or directories

Apply a PodSecurityPolicy configuration (deprecated)

Why these pairings

These commands are commonly used for security operations and auditing.

Practice this question →
17
MCQmedium

A security team deploys the above pod and profile. The pod runs but a security scan reports that mount-related syscalls are being allowed instead of logged. What is the most likely reason?

A.The SYS_ADMIN capability overrides the seccomp policy.
B.The seccomp profile is not stored in the correct location, so the container runs without seccomp.
C.The defaultAction SCMP_ACT_ALLOW overrides the specific syscalls.
D.The profile uses SCMP_ACT_LOG which does not block syscalls; it only logs them.
AnswerB

The path is relative; profile must be in /var/lib/kubelet/seccomp/.

Why this answer

Option B is correct because the seccomp profile must be stored in `/var/lib/kubelet/seccomp/` for the `localhost` source to work. If the profile is placed elsewhere, the kubelet cannot read it, and the container runs without any seccomp restriction, allowing mount-related syscalls to proceed instead of being logged or blocked.

Exam trap

CNCF often tests the requirement that seccomp profiles must reside in `/var/lib/kubelet/seccomp/` for `localhost` profiles to be applied, and candidates mistakenly assume any valid path works or that the profile is silently ignored rather than causing a runtime failure.

How to eliminate wrong answers

Option A is wrong because SYS_ADMIN capability does not override seccomp; seccomp filters are enforced independently of capabilities, and capabilities cannot disable a seccomp profile. Option C is wrong because `defaultAction: SCMP_ACT_ALLOW` only sets the default action for syscalls not explicitly listed; it does not override the specific syscalls listed in the profile — those specific syscalls would still be handled by their own actions. Option D is wrong because `SCMP_ACT_LOG` does log syscalls without blocking them, but the question states syscalls are being allowed instead of logged, meaning the profile is not applied at all, not that it is applied with LOG action.

Practice this question →
18
Matchingmedium

Match each Kubernetes certificate type to its usage.

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

Concepts
Matches

Used by kubelet to serve the kubelet API (e.g., exec, logs)

Used by kubelet to authenticate to the API server

Used by the API server to serve HTTPS endpoints

Used to sign service account tokens so they can be verified

Used by an administrator to authenticate to the cluster with full privileges

Why these pairings

Certificate management is essential for securing communication in Kubernetes.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Monitoring Logging and Runtime Security questions.

Start 20-question session