KCSA — Cloud Native Security Tools — Practice Questions

12 minute read

Practice Questions — Cloud Native Security Tools

These 10 multiple-choice questions cover the key concepts from the Cloud Native Security Tools chapter. Topics include Falco architecture, Trivy scanning, OPA/Kyverno policy enforcement, service mesh security, and the security observability stack.

How to use these questions:

  1. Read each question carefully — watch for negative qualifiers like “NOT”
  2. Try to answer before expanding the answer section
  3. Use the elimination technique: cross off obviously wrong options first
  4. Read the full explanation for every question — even the ones you got right
  5. Track your score at the end

Questions

Q1: Falco captures syscall events from the Linux kernel using which modern approach?

A) Kubernetes Audit Webhook
B) eBPF probe
C) Container runtime socket
D) Prometheus metrics exporter

Show Answer

Correct Answer: B) eBPF probe

Falco captures syscall events from the Linux kernel using either a kernel module or an eBPF probe. The eBPF probe is the modern, recommended approach because it does not require loading a kernel module, is safer, and is portable across kernel versions (especially the modern eBPF CO-RE variant).

  • A) Kubernetes Audit Webhook — Incorrect. Falco can consume Kubernetes audit logs via a plugin, but this is for API server events, not syscall capture. The primary data source for Falco is the kernel, not the audit webhook.
  • B) eBPF probe — Correct. eBPF (extended Berkeley Packet Filter) allows Falco to attach to kernel syscall tracepoints and capture events efficiently without a traditional kernel module.
  • C) Container runtime socket — Incorrect. Tools like crictl or container monitoring agents use the runtime socket, but Falco operates at the kernel level below the container runtime.
  • D) Prometheus metrics exporter — Incorrect. Prometheus is a metrics collection system. Falco does not use Prometheus to capture events — though Falco metrics can be exported to Prometheus for dashboarding.

Domain: Cloud Native Security Tools — Falco

Q2: What is the correct order of Falco rule priorities from MOST severe to LEAST severe?

A) CRITICAL → ALERT → EMERGENCY → ERROR → WARNING → NOTICE → INFO → DEBUG
B) EMERGENCY → ALERT → CRITICAL → ERROR → WARNING → NOTICE → INFORMATIONAL → DEBUG
C) ALERT → EMERGENCY → CRITICAL → WARNING → ERROR → NOTICE → INFO → DEBUG
D) DEBUG → INFO → NOTICE → WARNING → ERROR → CRITICAL → ALERT → EMERGENCY

Show Answer

Correct Answer: B) EMERGENCY → ALERT → CRITICAL → ERROR → WARNING → NOTICE → INFORMATIONAL → DEBUG

Falco uses eight priority levels that follow the standard syslog severity scale. EMERGENCY (level 0) is the most severe, and DEBUG (level 7) is the least severe.

  • A) CRITICAL → ALERT → EMERGENCY → ERROR → WARNING → NOTICE → INFO → DEBUG — Incorrect. This puts CRITICAL before ALERT and EMERGENCY, which reverses the top three priorities.
  • B) EMERGENCY → ALERT → CRITICAL → ERROR → WARNING → NOTICE → INFORMATIONAL → DEBUG — Correct. This follows the syslog convention: Emergency (0), Alert (1), Critical (2), Error (3), Warning (4), Notice (5), Informational (6), Debug (7).
  • C) ALERT → EMERGENCY → CRITICAL → WARNING → ERROR → NOTICE → INFO → DEBUG — Incorrect. EMERGENCY is more severe than ALERT, and ERROR is more severe than WARNING.
  • D) DEBUG → INFO → NOTICE → WARNING → ERROR → CRITICAL → ALERT → EMERGENCY — Incorrect. This is the reverse order (least to most severe).

Domain: Cloud Native Security Tools — Falco

Q3: Which of the following is NOT a valid scanning target for Trivy?

A) Container images
B) Running Kubernetes cluster resources
C) Active network connections
D) Infrastructure-as-Code files (Terraform, Dockerfile)

Show Answer

Correct Answer: C) Active network connections

Trivy scans container images, filesystems, Git repositories, Kubernetes resources, IaC files, and SBOMs. It does not scan active network connections — that is the domain of network observability tools like Cilium Hubble or service mesh telemetry.

  • A) Container images — Incorrect. Container image scanning is Trivy’s most common use case — it checks OS packages and language dependencies for known CVEs.
  • B) Running Kubernetes cluster resources — Incorrect. Trivy can scan a running Kubernetes cluster (trivy k8s) to detect misconfigurations and vulnerabilities in deployed workloads.
  • C) Active network connections — Correct. Trivy is a vulnerability and misconfiguration scanner. It analyzes static artifacts and configurations, not live network traffic.
  • D) Infrastructure-as-Code files (Terraform, Dockerfile) — Incorrect. Trivy scans IaC files (trivy config) to detect misconfigurations before infrastructure is provisioned.

Domain: Cloud Native Security Tools — Trivy

Q4: A security engineer wants to compare Trivy with Grype. Which statement is accurate?

A) Grype supports IaC scanning and SBOM generation natively, while Trivy does not
B) Both are open-source vulnerability scanners, but Trivy additionally scans IaC, Kubernetes clusters, and generates SBOMs
C) Grype is a commercial product from Snyk, while Trivy is open-source from Aqua Security
D) Trivy and Grype are identical in functionality and are maintained by the same organization

Show Answer

Correct Answer: B) Both are open-source vulnerability scanners, but Trivy additionally scans IaC, Kubernetes clusters, and generates SBOMs

Both Trivy and Grype are open-source vulnerability scanners. However, Trivy is an all-in-one tool that also scans IaC files, Kubernetes clusters, and generates SBOMs. Grype is focused on vulnerability scanning of container images and filesystems using SBOMs.

  • A) Grype supports IaC scanning and SBOM generation natively, while Trivy does not — Incorrect. This is reversed. Trivy supports IaC scanning and SBOM generation. Grype does not scan IaC and does not generate SBOMs (it consumes SBOMs generated by Syft).
  • B) Both are open-source vulnerability scanners, but Trivy additionally scans IaC, Kubernetes clusters, and generates SBOMs — Correct. This accurately describes the scope difference between the two tools.
  • C) Grype is a commercial product from Snyk, while Trivy is open-source from Aqua Security — Incorrect. Grype is open-source from Anchore, not a commercial product from Snyk. Snyk is a separate commercial tool.
  • D) Trivy and Grype are identical in functionality and are maintained by the same organization — Incorrect. They are different tools by different organizations (Aqua Security vs Anchore) with different scope.

Domain: Cloud Native Security Tools — Trivy

Q5: What is the key difference between OPA/Gatekeeper policy language and Kyverno policy language?

A) OPA uses YAML policies, Kyverno uses a custom language called Rego
B) OPA uses Rego (a custom declarative language), Kyverno uses standard Kubernetes YAML
C) Both use CEL (Common Expression Language) as their policy language
D) OPA uses JSON policies, Kyverno uses Go templates

Show Answer

Correct Answer: B) OPA uses Rego (a custom declarative language), Kyverno uses standard Kubernetes YAML

This is one of the most important distinctions for the KCSA exam. OPA policies are written in Rego, a purpose-built declarative query language with a steep learning curve. Kyverno policies are written in standard Kubernetes YAML, making them immediately familiar to anyone who works with Kubernetes manifests.

  • A) OPA uses YAML policies, Kyverno uses a custom language called Rego — Incorrect. This is completely reversed. OPA uses Rego, Kyverno uses YAML.
  • B) OPA uses Rego (a custom declarative language), Kyverno uses standard Kubernetes YAML — Correct. Rego is OPA’s custom language. Kyverno’s YAML-native approach is its primary selling point — no new language to learn.
  • C) Both use CEL (Common Expression Language) as their policy language — Incorrect. CEL is used by Kubernetes’ built-in ValidatingAdmissionPolicy, not by OPA or Kyverno.
  • D) OPA uses JSON policies, Kyverno uses Go templates — Incorrect. Neither tool uses JSON policies or Go templates for policy definition.

Domain: Cloud Native Security Tools — OPA & Kyverno

Q6: In OPA Gatekeeper, what is the relationship between a ConstraintTemplate and a Constraint?

A) A Constraint defines the Rego logic, and a ConstraintTemplate applies parameters to it
B) A ConstraintTemplate defines the reusable Rego policy logic, and a Constraint applies it with specific parameters and scope
C) ConstraintTemplate and Constraint are two names for the same resource
D) A ConstraintTemplate is used only in audit mode, while a Constraint is used in enforcement mode

Show Answer

Correct Answer: B) A ConstraintTemplate defines the reusable Rego policy logic, and a Constraint applies it with specific parameters and scope

Gatekeeper uses a two-step model. The ConstraintTemplate contains the Rego policy logic (the “how to check”) and defines the CRD schema. The Constraint is an instance of that template that specifies parameters (the “what to check for”) and the matching scope (which resources to apply it to).

  • A) A Constraint defines the Rego logic, and a ConstraintTemplate applies parameters to it — Incorrect. This is reversed. The ConstraintTemplate holds the Rego logic, the Constraint provides parameters.
  • B) A ConstraintTemplate defines the reusable Rego policy logic, and a Constraint applies it with specific parameters and scope — Correct. For example, a ConstraintTemplate for “required labels” contains the Rego logic to check labels. A Constraint instantiates it with parameters like labels: ["team", "environment"] and applies it to specific resource kinds.
  • C) ConstraintTemplate and Constraint are two names for the same resource — Incorrect. They are distinct resources with different purposes in the Gatekeeper architecture.
  • D) A ConstraintTemplate is used only in audit mode, while a Constraint is used in enforcement mode — Incorrect. Both are used together in all modes. The enforcement action (enforce, dryrun) is set on the Constraint, not determined by resource type.

Domain: Cloud Native Security Tools — OPA & Kyverno

Q7: In Istio, what is the difference between STRICT and PERMISSIVE mTLS modes?

A) STRICT encrypts only ingress traffic, PERMISSIVE encrypts only egress traffic
B) STRICT rejects plaintext connections (only mTLS allowed), PERMISSIVE accepts both mTLS and plaintext
C) STRICT uses self-signed certificates, PERMISSIVE uses CA-signed certificates
D) STRICT mode is for development environments, PERMISSIVE is for production

Show Answer

Correct Answer: B) STRICT rejects plaintext connections (only mTLS allowed), PERMISSIVE accepts both mTLS and plaintext

Istio’s PeerAuthentication resource controls mTLS behavior. In STRICT mode, the sidecar proxy only accepts mTLS connections — any plaintext request is rejected. In PERMISSIVE mode, both mTLS and plaintext connections are accepted, which is useful during migration when not all services are in the mesh yet.

  • A) STRICT encrypts only ingress traffic, PERMISSIVE encrypts only egress traffic — Incorrect. Both modes apply to all traffic (ingress and egress). The difference is whether plaintext is accepted, not which direction is encrypted.
  • B) STRICT rejects plaintext connections (only mTLS allowed), PERMISSIVE accepts both mTLS and plaintext — Correct. STRICT enforces full mTLS. PERMISSIVE is the transitional mode for gradual mesh adoption.
  • C) STRICT uses self-signed certificates, PERMISSIVE uses CA-signed certificates — Incorrect. The certificate type is determined by the mesh CA configuration, not the mTLS mode.
  • D) STRICT mode is for development environments, PERMISSIVE is for production — Incorrect. It is the opposite — STRICT should be the production target for full encryption enforcement. PERMISSIVE is the transitional mode.

Domain: Cloud Native Security Tools — Service Mesh Security

Q8: Which Istio resource would you use to allow only the frontend service to call the backend service on specific HTTP paths?

A) PeerAuthentication
B) DestinationRule
C) AuthorizationPolicy
D) VirtualService

Show Answer

Correct Answer: C) AuthorizationPolicy

Istio’s AuthorizationPolicy provides L7 access control — it allows or denies traffic based on source identity, destination, HTTP methods, and paths. This is the correct resource for controlling which service can access which endpoints.

  • A) PeerAuthentication — Incorrect. PeerAuthentication controls mTLS mode (STRICT/PERMISSIVE), not access control rules. It determines whether plaintext is accepted, not who can talk to whom.
  • B) DestinationRule — Incorrect. DestinationRule configures traffic policies like load balancing, connection pool settings, and TLS settings for outbound traffic to a destination. It does not define access control.
  • C) AuthorizationPolicy — Correct. AuthorizationPolicy defines ALLOW/DENY rules based on source (principal, namespace), destination (HTTP method, path), and conditions. It is Istio’s L7 access control mechanism.
  • D) VirtualService — Incorrect. VirtualService configures traffic routing (path-based routing, header manipulation, traffic splitting). It does not enforce access control.

Domain: Cloud Native Security Tools — Service Mesh Security

Q9: Which of the following represents the three pillars of observability?

A) Encryption, Authentication, Authorization
B) Scanning, Detection, Prevention
C) Metrics, Logs, Traces
D) CPU, Memory, Network

Show Answer

Correct Answer: C) Metrics, Logs, Traces

The three pillars of observability are Metrics (numerical measurements over time), Logs (discrete event records), and Traces (request flow across services). Together, they provide complete visibility into system behavior for both operations and security.

  • A) Encryption, Authentication, Authorization — Incorrect. These are security controls (the “AAA” model includes Authentication, Authorization, and Accounting), not observability pillars.
  • B) Scanning, Detection, Prevention — Incorrect. These describe security activity categories (e.g., Trivy scans, Falco detects, OPA prevents), not observability pillars.
  • C) Metrics, Logs, Traces — Correct. Metrics come from Prometheus, logs from EFK/ELK stacks, and traces from Jaeger/Zipkin/OpenTelemetry. Each answers a different question about system behavior.
  • D) CPU, Memory, Network — Incorrect. These are infrastructure resource types, not observability pillars. They may be things you observe using metrics, but they are not the pillars themselves.

Domain: Cloud Native Security Tools — Security Observability Stack

Q10: A security team wants to correlate Kubernetes audit logs, Falco runtime alerts, and network flow data into a single platform for investigation and incident response. Which type of system should they use?

A) Prometheus with Grafana dashboards
B) SIEM (Security Information and Event Management)
C) Trivy Operator
D) OPA Gatekeeper audit mode

Show Answer

Correct Answer: B) SIEM (Security Information and Event Management)

A SIEM platform (such as Splunk, Microsoft Sentinel, or Elastic Security) aggregates, correlates, and analyzes security events from multiple sources. It is specifically designed to bring together diverse data sources — audit logs, runtime alerts, network flows — into a unified investigation and response platform.

  • A) Prometheus with Grafana dashboards — Incorrect. Prometheus collects metrics and Grafana visualizes them. They are excellent for alerting on anomalies but are not designed for cross-source event correlation, incident management, or log aggregation.
  • B) SIEM (Security Information and Event Management) — Correct. A SIEM correlates events across multiple sources (audit logs + Falco + network flows), provides investigation workflows, enables detection rules, and supports incident response — exactly what this scenario requires.
  • C) Trivy Operator — Incorrect. Trivy Operator scans workloads for vulnerabilities and misconfigurations. It does not aggregate or correlate security events from multiple sources.
  • D) OPA Gatekeeper audit mode — Incorrect. Gatekeeper audit mode checks existing resources against admission policies. It does not aggregate runtime alerts or network flow data.

Domain: Cloud Native Security Tools — Security Observability Stack

Self-Assessment Scoring Guide

Count your correct answers and use the guide below to assess your readiness:

Score Rating Recommendation
9–10 Excellent You have a strong grasp of cloud native security tools. Review any missed questions and move on.
7–8 Good Solid understanding. Re-read the sections for questions you missed.
5–6 Fair Review the Falco, Trivy, and policy enforcement chapters — focus on tool comparisons and architectural details.
3–4 Needs Work Re-read the entire chapter. Pay special attention to tables comparing tools and their capabilities.
0–2 Start Over Go back to the beginning of Chapter 9 and work through each sub-topic carefully before retaking this quiz.

Key Concepts to Review If You Scored Below 7

  • Falco architecture — eBPF probe → rules engine → alerting (Falco chapter)
  • Trivy scanning targets — images, filesystem, IaC, Kubernetes, SBOM (Trivy chapter)
  • OPA Rego vs Kyverno YAML — the language difference is the #1 tested distinction (OPA & Kyverno chapter)
  • mTLS modes — STRICT vs PERMISSIVE and when to use each (Service Mesh chapter)
  • Three pillars of observability — metrics, logs, traces (Observability chapter)
  • SIEM vs other tools — know what SIEM uniquely provides (correlation, incident management)

Back to: Cloud Native Security Tools — Hub

Updated:

You may also enjoy