CKS Monitoring, Logging and Runtime Security Practice Question
You suspect a pod is making unexpected outbound connections. Which tool can you use to inspect network connections from within the container?
⚠ Common exam trap
Many exam-takers choose `kubectl logs` thinking it shows network activity, but logs only capture application output, not kernel-level connection states, while `crictl exec` provides direct access to the container's network namespace.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
crictl exec
`crictl exec` allows you to run commands inside a container managed by CRI-compatible runtimes (like containerd), enabling you to inspect network connections from within the container using tools like `ss`, `netstat`, or `ip`. This is the direct method to check outbound connections from the container's network namespace, which is isolated from the host.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
kubectl port-forward
Why it's wrong here
kubectl port-forward creates a local tunnel to a pod's exposed port for debugging or accessing a service; it does not inspect or list the pod's active outbound connections. It also requires the pod to have a listening port and targets traffic from your local machine, not traffic initiated from inside the container. Therefore, it gives no visibility into unexpected outbound connections.
- ✓
crictl exec
Why this is correct
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.
- ✗
falco
Why it's wrong here
Falco is a runtime security monitoring tool that uses kernel eBPF or kprobes to detect syscall-level events, such as `connect()`, and can trigger alerts on unexpected outbound connections, but it is not a command for interactively inspecting a container's network state. It runs as a daemon outside the container, and while it can log alert activity, it does not provide a shell or a live netstat inside the container being investigated. Hence, it cannot be used to directly run `ss` or `netstat` inside the container, making it incorrect for this immediate diagnostic task.
- ✗
kubectl logs
Why it's wrong here
`kubectl logs` only retrieves the stdout/stderr output of the container's main process, which may or may not contain network-related log lines, but it never displays the kernel's connection table or the container's active sockets. Unless the application was explicitly coded to log each outbound connection, logs will be silent about network activity, and even then the logs do not provide a real-time snapshot of all connections like `ss` does. Thus, it is not a tool for inspecting live outbound connections.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKS question from scratch — 845 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKS practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKS exam.