How should I use these Monitoring Logging and Runtime Security practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

CKS · topic practice

Monitoring Logging and Runtime Security practice questions

Q: Can I practise just Monitoring Logging and Runtime Security questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Monitoring Logging and Runtime Security domain.

Practise Certified Kubernetes Security Specialist CKS Monitoring Logging and Runtime Security practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Reviewed byJohnson Ajibi· MSc IT Security

18 questionsDomain: Monitoring Logging and Runtime Security

Practice 10 questions Browse domain →

What the exam tests

What to know about Monitoring Logging and Runtime Security

Monitoring Logging and Runtime Security questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Monitoring Logging and Runtime Security exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Monitoring Logging and Runtime Security questions

18 questions · select your answer, then reveal the explanation

Question 1mediummultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Configure CRI-O to log all container process starts to syslog.

CRI-O does not provide process-level logging; would require runtime modification.

Trap 2: Enable Kubernetes audit logging and parse the logs for process…

Audit logs capture API requests, not container process syscalls.

Trap 3: Use OPA Gatekeeper to enforce allowed process lists in pod specs.

OPA/Gatekeeper validates admission, not runtime process execution.

Study all Monitoring Logging and Runtime Security common traps →

A
Configure CRI-O to log all container process starts to syslog.
Why wrong: CRI-O does not provide process-level logging; would require runtime modification.
B
Deploy Falco as a DaemonSet using eBPF probe to monitor system calls.
Falco on the host can detect container process anomalies without modifying images.
C
Enable Kubernetes audit logging and parse the logs for process events.
Why wrong: Audit logs capture API requests, not container process syscalls.
D
Use OPA Gatekeeper to enforce allowed process lists in pod specs.
Why wrong: OPA/Gatekeeper validates admission, not runtime process execution.

Full breakdown with real-world context →

Question 2hardmultiple choice

Read the full NAT/PAT explanation →

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?

Trap 1: Use an AppArmor profile to block setuid syscalls.

AppArmor is not a built-in Kubernetes mechanism for pod security standards.

Trap 2: Set 'securityContext.runAsUser: 1000' on each pod spec.

Setting a non-root user does not prevent setuid binaries.

Trap 3: Apply the 'baseline' Pod Security Standard with 'seccompProfile:…

Baseline does not require runAsNonRoot.

Study all Monitoring Logging and Runtime Security common traps →

A
Use an AppArmor profile to block setuid syscalls.
Why wrong: AppArmor is not a built-in Kubernetes mechanism for pod security standards.
B
Apply the 'restricted' Pod Security Standard at the namespace level.
Restricted enforces runAsNonRoot and disallows privileged escalation.
C
Set 'securityContext.runAsUser: 1000' on each pod spec.
Why wrong: Setting a non-root user does not prevent setuid binaries.
D
Apply the 'baseline' Pod Security Standard with 'seccompProfile: RuntimeDefault'.
Why wrong: Baseline does not require runAsNonRoot.

Full breakdown with real-world context →

Question 3easymultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Configure the kubelet to rotate logs from the container's…

Kubelet only captures container stdout/stderr, not file logs.

Trap 2: Use `kubectl cp` to periodically copy logs from the container.

Manual copying is not efficient or real-time.

Trap 3: Install a syslog daemon in the container to forward logs.

Modifying the image is not efficient and violates immutability.

Study all Monitoring Logging and Runtime Security common traps →

A
Configure the kubelet to rotate logs from the container's filesystem.
Why wrong: Kubelet only captures container stdout/stderr, not file logs.
B
Add a sidecar container that reads the log file and outputs to stdout.
The sidecar pattern streams file logs to stdout for kubectl logs.
C
Use `kubectl cp` to periodically copy logs from the container.
Why wrong: Manual copying is not efficient or real-time.
D
Install a syslog daemon in the container to forward logs.
Why wrong: Modifying the image is not efficient and violates immutability.

Full breakdown with real-world context →

Question 4hardmultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Run Trivy in a CronJob to scan images and update a ConfigMap with…

ConfigMap approach is not real-time and can be bypassed.

Trap 2: Use OPA Gatekeeper to verify that the image comes from the private…

Registry source does not guarantee scanning or signing.

Trap 3: Enable Binary Authorization on the cluster to enforce image…

Binary Authorization is a GCP-specific feature, not general Kubernetes.

Study all Monitoring Logging and Runtime Security common traps →

A
Use Cosign to sign images and deploy a webhook that verifies signatures.
Cosign admission controller can enforce signature verification at pod creation.
B
Run Trivy in a CronJob to scan images and update a ConfigMap with allowed images.
Why wrong: ConfigMap approach is not real-time and can be bypassed.
C
Use OPA Gatekeeper to verify that the image comes from the private registry.
Why wrong: Registry source does not guarantee scanning or signing.
D
Enable Binary Authorization on the cluster to enforce image attestation.
Why wrong: Binary Authorization is a GCP-specific feature, not general Kubernetes.

Full breakdown with real-world context →

Question 5easymultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Configure Fluentd to collect network logs from each node.

Fluentd is a log collector, not a network monitor.

Trap 2: Use Prometheus to scrape network metrics from kube-proxy.

Prometheus collects metrics, not network flows.

Trap 3: Run kube-bench to audit network policies.

Kube-bench checks CIS benchmarks, not live traffic.

Study all Monitoring Logging and Runtime Security common traps →

A
Configure Fluentd to collect network logs from each node.
Why wrong: Fluentd is a log collector, not a network monitor.
B
Use Prometheus to scrape network metrics from kube-proxy.
Why wrong: Prometheus collects metrics, not network flows.
C
Run kube-bench to audit network policies.
Why wrong: Kube-bench checks CIS benchmarks, not live traffic.
D
Deploy Cilium with Hubble for network flow visibility.
Cilium/Hubble provides pod-level network monitoring.

Full breakdown with real-world context →

Question 6mediummulti select

Read the full Monitoring Logging and Runtime Security explanation →

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

Trap 1: Set 'securityContext.seccompProfile.type: Unconfined' to allow all…

Unconfined disables seccomp, increasing risk.

Trap 2: Enable Kubernetes audit logging to capture exec commands.

Audit logs record events, not prevent breakouts.

Trap 3: Use PodSecurityPolicy to deny privileged containers.

PSP is deprecated and does not detect breakouts.

Study all Monitoring Logging and Runtime Security common traps →

A
Set 'securityContext.seccompProfile.type: Unconfined' to allow all syscalls.
Why wrong: Unconfined disables seccomp, increasing risk.
B
Enable Kubernetes audit logging to capture exec commands.
Why wrong: Audit logs record events, not prevent breakouts.
C
Use PodSecurityPolicy to deny privileged containers.
Why wrong: PSP is deprecated and does not detect breakouts.
D
Deploy Falco with rules that alert on 'syscall' events like 'clone' or 'unshare'.
Falco can detect breakout attempts via syscall monitoring.
E
Apply a seccomp profile that blocks unneeded syscalls for each container.
Seccomp restricts syscalls, making breakout harder.

Full breakdown with real-world context →

Question 7hardmulti select

Read the full Monitoring Logging and Runtime Security explanation →

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

Trap 1: Set container 'stdout' logging only, avoiding file-based logs.

Stdout logs are not encrypted unless the container output is encrypted.

Trap 2: Disable log rotation to prevent log tampering during rotation.

Disabling rotation causes disk full and data loss.

Study all Monitoring Logging and Runtime Security common traps →

A
Configure the log collector to use TLS when shipping logs to a central system.
TLS encrypts logs in transit.
B
Set container 'stdout' logging only, avoiding file-based logs.
Why wrong: Stdout logs are not encrypted unless the container output is encrypted.
C
Store logs in a backend that supports encryption at rest (e.g., S3 with SSE).
Encryption at rest protects stored logs.
D
Run log collectors in a dedicated namespace with network policies limiting access.
Isolation and network policies restrict unauthorized access.
E
Disable log rotation to prevent log tampering during rotation.
Why wrong: Disabling rotation causes disk full and data loss.

Full breakdown with real-world context →

Question 8mediummultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Use Seccomp profiles to block write syscalls outside /tmp

Seccomp filters syscalls at the kernel level and cannot selectively block writes based on file path.

Trap 2: Implement an OPA Gatekeeper constraint to reject pods that write…

OPA Gatekeeper validates pod specs at admission time, not runtime behavior.

Trap 3: Configure AppArmor to deny writes outside /tmp

AppArmor enforces policy but does not log violations by default without explicit audit rules.

Study all Monitoring Logging and Runtime Security common traps →

A
Use Seccomp profiles to block write syscalls outside /tmp
Why wrong: Seccomp filters syscalls at the kernel level and cannot selectively block writes based on file path.
B
Implement an OPA Gatekeeper constraint to reject pods that write outside /tmp
Why wrong: OPA Gatekeeper validates pod specs at admission time, not runtime behavior.
C
Deploy Falco with a rule: 'evt.type=open and evt.dir=< and fd.name startswith / and not fd.name startswith /tmp'
Falco monitors system calls and can generate alerts for file writes outside /tmp with minimal overhead.
D
Configure AppArmor to deny writes outside /tmp
Why wrong: AppArmor enforces policy but does not log violations by default without explicit audit rules.

Full breakdown with real-world context →

Question 9hardmulti select

Read the full Monitoring Logging and Runtime Security explanation →

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?

Network Topology

Trap 1: Set the kubelet flag --authentication-token-webhook=true

This enables token review but does not disable anonymous access.

Trap 2: Enable the NodeRestriction admission controller

NodeRestriction limits node self-updates to the API server, but does not secure the kubelet API.

Trap 3: Modify the kube-apiserver manifest to set --anonymous-auth=false

This affects the API server, not the kubelet's anonymous access.

Study all Monitoring Logging and Runtime Security common traps →

A
Upgrade the cluster to Kubernetes 1.14 or later to fix CVE-2019-11245
The vulnerability is fixed in kubelet versions 1.13.9+, 1.14.5+, and 1.15.2+.
B
Set the kubelet flag --authentication-token-webhook=true
Why wrong: This enables token review but does not disable anonymous access.
C
Configure the kubelet to set --anonymous-auth=false and restart the kubelet service
This stops the kubelet from allowing unauthenticated requests.
D
Enable the NodeRestriction admission controller
Why wrong: NodeRestriction limits node self-updates to the API server, but does not secure the kubelet API.
E
Modify the kube-apiserver manifest to set --anonymous-auth=false
Why wrong: This affects the API server, not the kubelet's anonymous access.

Full breakdown with real-world context →

Question 10easymulti select

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Enable the AuditDynamicConfiguration feature gate

This allows dynamic reconfiguration but does not address retention or tamper-proofing.

Trap 2: Deploy Fluentd to forward logs to a central Elasticsearch cluster

Forwarding does not guarantee immutability.

Trap 3: Set --audit-log-maxbackup=10 and --audit-log-maxsize=100

These flags control rotation, not retention duration or tamper-proofing.

Study all Monitoring Logging and Runtime Security common traps →

A
Configure the audit log backend to write to an immutable object store like S3 with Object Lock
Immutable storage prevents log modification or deletion.
B
Enable the AuditDynamicConfiguration feature gate
Why wrong: This allows dynamic reconfiguration but does not address retention or tamper-proofing.
C
Deploy Fluentd to forward logs to a central Elasticsearch cluster
Why wrong: Forwarding does not guarantee immutability.
D
Set the API server flag --audit-log-maxage=90
This sets the retention period for audit log files.
E
Set --audit-log-maxbackup=10 and --audit-log-maxsize=100
Why wrong: These flags control rotation, not retention duration or tamper-proofing.

Full breakdown with real-world context →

Question 11hardmultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Trap 1: Use 'kubectl exec -it <pod> -- bash' to inspect the container, then…

The container may not have a shell, or the process may be immune to SIGTERM; this also does not prevent the pod from restarting.

Trap 2: Scale the 'payment-processor' Deployment to 0 replicas to…

This stops all replicas, potentially destroying evidence and affecting other legitimate processes.

Trap 3: Check the Falco logs for an alert containing the pod name, then use…

Falco may not have detected the C2 traffic due to default rules, and deleting the pod will cause the ReplicaSet to recreate it.

Study all Monitoring Logging and Runtime Security common traps →

A
Use 'kubectl exec -it <pod> -- bash' to inspect the container, then kill the malicious process from within
Why wrong: The container may not have a shell, or the process may be immune to SIGTERM; this also does not prevent the pod from restarting.
B
Scale the 'payment-processor' Deployment to 0 replicas to immediately stop all pods
Why wrong: This stops all replicas, potentially destroying evidence and affecting other legitimate processes.
C
Check the Falco logs for an alert containing the pod name, then use 'kubectl delete pod' to remove the compromised pod
Why wrong: Falco may not have detected the C2 traffic due to default rules, and deleting the pod will cause the ReplicaSet to recreate it.
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
This directly stops the specific container without affecting other replicas and preserves the ability to investigate.

Full breakdown with real-world context →

Question 12easymulti select

Read the full Monitoring Logging and Runtime Security explanation →

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

Trap 1: Disable the container runtime's security engine to reduce overhead.

Disabling security reduces protection.

Trap 2: Run containers in privileged mode for better performance.

Privileged containers weaken security.

Trap 3: Set AppArmor to unconfined for all pods to avoid profile conflicts.

Unconfined disables AppArmor protection.

Study all Monitoring Logging and Runtime Security common traps →

A
Deploy Falco to monitor system calls and detect anomalous behavior.
Falco is a standard runtime security tool.
B
Disable the container runtime's security engine to reduce overhead.
Why wrong: Disabling security reduces protection.
C
Run containers in privileged mode for better performance.
Why wrong: Privileged containers weaken security.
D
Enable seccomp profiles to restrict available system calls.
Seccomp reduces kernel attack surface.
E
Set AppArmor to unconfined for all pods to avoid profile conflicts.
Why wrong: Unconfined disables AppArmor protection.

Full breakdown with real-world context →

Question 13mediummultiple choice

Read the full Monitoring Logging and Runtime Security explanation →

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?

Exhibit

Refer to the exhibit.
```
apiVersion: v1
kind: Pod
metadata:
  name: security-pod
spec:
  containers:
  - name: test
    image: alpine
    command: ["sleep", "3600"]
    securityContext:
      seccompProfile:
        type: Localhost
        localhostProfile: "profiles/audit.json"
      capabilities:
        add: ["SYS_ADMIN"]
```
The seccomp profile at /var/lib/kubelet/seccomp/profiles/audit.json contains:
```
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["mount", "umount2"],
      "action": "SCMP_ACT_LOG"
    }
  ]
}
```

Trap 1: The SYS_ADMIN capability overrides the seccomp policy.

Capabilities and seccomp are independent.

Trap 2: The defaultAction SCMP_ACT_ALLOW overrides the specific syscalls.

Specific syscalls take precedence; default is fallback.

Trap 3: The profile uses SCMP_ACT_LOG which does not block syscalls; it…

SCMP_ACT_LOG logs but does not allow; the scan says allowed.

Study all Monitoring Logging and Runtime Security common traps →

A
The SYS_ADMIN capability overrides the seccomp policy.
Why wrong: Capabilities and seccomp are independent.
B
The seccomp profile is not stored in the correct location, so the container runs without seccomp.
The path is relative; profile must be in /var/lib/kubelet/seccomp/.
C
The defaultAction SCMP_ACT_ALLOW overrides the specific syscalls.
Why wrong: Specific syscalls take precedence; default is fallback.
D
The profile uses SCMP_ACT_LOG which does not block syscalls; it only logs them.
Why wrong: SCMP_ACT_LOG logs but does not allow; the scan says allowed.

Full breakdown with real-world context →

Question 14hardmultiple choice

Read the full NAT/PAT explanation →

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?

Trap 1: Adjust the OOM score of critical pods to prevent them from being…

OOM scores control which pod is killed, not detect fork bombs.

Trap 2: Apply a seccomp profile that blocks the fork and clone syscalls.

Blocking fork/clone may break many applications.

Trap 3: Set resource quotas on all namespaces to limit memory usage.

Quotas limit total usage but do not detect fork bombs.

Study all Monitoring Logging and Runtime Security common traps →

A
Enable the Falco rule that detects rapid process creation (fork bomb) and configure an alert.
Falco has a built-in rule for fork bombs.
B
Adjust the OOM score of critical pods to prevent them from being killed.
Why wrong: OOM scores control which pod is killed, not detect fork bombs.
C
Apply a seccomp profile that blocks the fork and clone syscalls.
Why wrong: Blocking fork/clone may break many applications.
D
Set resource quotas on all namespaces to limit memory usage.
Why wrong: Quotas limit total usage but do not detect fork bombs.

Full breakdown with real-world context →

Question 15mediumdrag order

Read the full Monitoring Logging and Runtime Security explanation →

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

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 16mediumdrag order

Read the full Monitoring Logging and Runtime Security explanation →

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

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Question 17mediummatching

Read the full Monitoring Logging and Runtime Security explanation →

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)

Question 18mediummatching

Read the full Monitoring Logging and Runtime Security explanation →

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

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Monitoring Logging and Runtime Security sessions

Start a Monitoring Logging and Runtime Security only practice session

Every question in these sessions is drawn from the Monitoring Logging and Runtime Security domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Monitoring Logging and Runtime Security questions →Mixed CKS session

Frequently asked questions

What does the CKS exam test about Monitoring Logging and Runtime Security?: Monitoring Logging and Runtime Security questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Monitoring Logging and Runtime Security questions in a focused session?: Yes — the session launcher on this page draws every question from the Monitoring Logging and Runtime Security domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other CKS topics?: Use the topic links above to move to related areas, or go back to the CKS question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the CKS exam covers. They are not copied from any real exam or dump site.

Monitoring Logging and Runtime Security only

10 questions 20 questions 30 questions 50 questions

Mixed CKS session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All CKS questions Monitoring Logging and Runtime Security domain overview CKS exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Monitoring Logging and Runtime Security practice questions

What to know about Monitoring Logging and Runtime Security

Common Monitoring Logging and Runtime Security exam traps

Monitoring Logging and Runtime Security questions

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?

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 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 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 cluster administrator wants to monitor network traffic between pods for security analysis. Which tool is designed specifically for this purpose and integrates with Kubernetes?

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

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

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?

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?

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

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?

Exhibit

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

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

Match each Kubernetes command to its function related to security.

Match each Kubernetes certificate type to its usage.

Track your progress over time

Start a Monitoring Logging and Runtime Security only practice session

Related CKS topic practice pages