KCSA Practice Test 14 — 15 Questions

Question 1

Which TWO layers complete the remaining set of the 4Cs of Cloud Native Security model alongside Code and Container? (Choose TWO)

Accepted Answer

Cloud. The 4Cs of Cloud Native Security model are Code, Container, Cluster, and Cloud, so the two missing layers are Cloud (B) and Cluster (D). Cloud (B) is correct because it represents the underlying infrastructure layer — the cloud provider, its network, compute, storage, and IAM boundaries — which underpins and isolates everything above it. Cluster (D) is correct because it covers the orchestration layer (e.g., Kubernetes control plane, nodes, RBAC, network policies, and admission control) that secures how containers are scheduled and run. The remaining options do not belong: Cache (A) is a performance/data-storage concept, not a security layer; Compiler (C) is a build toolchain component, not part of the 4Cs; and Containerd (E) is a specific container runtime that falls within the Container layer rather than being a separate layer itself.

Answer

Cache

Answer

Compiler

Answer

Containerd

Question 2

You are auditing a multi-tenant Kubernetes cluster and notice that users can read ServiceAccount tokens belonging to other namespaces through improper RBAC configuration. Which ClusterRole permission should be strictly avoided or audited to prevent token theft via secret inspection?

Accepted Answer

Verbs like 'get', 'list', or 'watch' on resource 'secrets' across all namespaces.. To prevent token theft via secret inspection, you must avoid or audit ClusterRole permissions that allow 'get', 'list', or 'watch' on 'secrets' across all namespaces. ServiceAccount tokens are stored as Secrets, so broad read access to secrets enables attackers to steal tokens and escalate privileges. Option D correctly identifies this critical permission set.

Answer

Verbs like 'get' on resource 'pods/status'.

Answer

Verbs like 'list' on resource 'namespaces'.

Answer

Verbs like 'create' on resource 'deployments'.

Question 3

According to the CIS Kubernetes Benchmark, anonymous requests to the Kubernetes API server should be disabled. Which kube-apiserver flag enforces this setting?

Accepted Answer

--anonymous-auth=false. The --anonymous-auth=false flag on the kube-apiserver disables anonymous requests, as recommended by the CIS Kubernetes Benchmark. This forces all requests to be authenticated.

Answer

--authorization-mode=Node,RBAC

Answer

--enable-admission-plugins

Answer

--insecure-port=0

Question 4

An attacker gains execution inside a container that has the `CAP_SYS_ADMIN` capability enabled and shares the host's IPC namespace. How does `CAP_SYS_ADMIN` facilitate container escape?

Accepted Answer

By permitting system administration operations like mounting host filesystems and manipulating cgroups. CAP_SYS_ADMIN is a powerful Linux capability that grants a broad range of system administration operations, including mounting filesystems, manipulating cgroups, and performing namespace operations. In a container, if this capability is enabled and the container shares the host's IPC namespace, an attacker can mount the host's filesystem (e.g., /dev/sda1) or use cgroup release_agent to execute commands on the host, achieving container escape.

Answer

By encrypting all network traffic traversing the CNI plugin bridge

Answer

By enabling automated horizontal scaling of replica sets

Answer

By automatically granting cluster-admin Kubernetes RBAC permissions

Question 5

You need to restrict network traffic so that only pods with the label 'tier=frontend' can communicate with pods labeled 'tier=backend' in the same namespace. Which Kubernetes resource should you create?

Accepted Answer

NetworkPolicy. NetworkPolicy is the native Kubernetes resource designed to control pod-to-pod traffic at L3/L4 by selecting pods via label selectors. A NetworkPolicy with a podSelector matching 'tier=backend' and an ingress rule with a podSelector matching 'tier=frontend' restricts ingress to only those pods. This is enforced by the CNI plugin (e.g., Calico, Cilium) on each node.

Answer

Ingress

Answer

FirewallRule

Answer

Service

Question 6

Which THREE components are involved when an external client authenticates to the Kubernetes API server using OpenID Connect (OIDC)? (Choose THREE)

Accepted Answer

The OIDC Identity Provider (IdP) issuing ID tokens.. Option A is correct because the OIDC Identity Provider (IdP) is the external authority that authenticates the user and issues the signed ID token (JWT) that the Kubernetes API server will later validate. Option C is correct because the client, such as kubectl, must obtain that ID token and present it to the API server in the HTTP Authorization header as a Bearer token, which is how the credentials reach the API server. Option E is correct because the kube-apiserver must be started with OIDC flags such as --oidc-issuer-url, --oidc-client-id, and --oidc-username-claim so it knows which issuer to trust and how to validate and map the token claims to a Kubernetes user. Option B is not required for OIDC authentication itself; CoreDNS resolves cluster service names, and while DNS may be needed for general connectivity, it is not a component of the OIDC authentication flow. Option D is also not involved, since the kubelet runs on worker nodes to manage pods and does not participate in authenticating an external client to the API server.

Answer

The CoreDNS server resolving the OIDC provider domain.

Answer

The Kubelet running on worker nodes.

Question 7

When configuring the Kubernetes API server authorization modes, which mode evaluates requests against Kubernetes RBAC policies?

Accepted Answer

RBAC. The RBAC authorization mode in the Kubernetes API server evaluates requests against Role-Based Access Control policies defined via Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. When enabled, the API server checks whether the requesting user or service account has a binding that grants the required verb on the target resource. RBAC is the standard, fine-grained authorization mechanism in modern Kubernetes clusters.

Answer

Webhook

Answer

Node

Answer

AlwaysAllow

Question 8

Which THREE of the following statements regarding cloud native security principles are correct? (Choose THREE)

Accepted Answer

Security policies should be codified, automated, and enforced throughout the software lifecycle. Option A is correct because cloud native security relies on shifting policy enforcement left and expressing controls as code (e.g., OPA/Gatekeeper, Kyverno, or admission controllers) so that security is automated and consistently applied across build, deploy, and runtime stages of the software lifecycle. Option B is correct because scanning IaC templates (Terraform, CloudFormation, Kubernetes manifests) with tools like Checkov, tfsec, or kube-score before deployment catches misconfigurations such as open security groups or privileged containers while they are still cheap to fix. Option D is correct because cloud native workloads are designed as immutable, ephemeral containers; rather than patching running instances in place, you rebuild the image and redeploy, which eliminates configuration drift and reduces the attack window. Option C is not correct because granting developers unrestricted admin access to production clusters violates least privilege and blast-radius containment; debugging should use scoped RBAC roles, just-in-time access, and audit logging. Option E is not correct because perimeter firewalls cannot secure east-west traffic, service-to-service communication, or multi-tenant isolation in cloud native clusters; zero-trust controls such as mTLS, network policies, and workload identity are required.

Answer

Developers should have unrestricted administrative access to production clusters for debugging

Answer

Traditional perimeter firewalls are sufficient to secure modern multi-tenant cloud-native clusters

Question 9

Which THREE of the following practices should be followed when configuring Kubernetes audit logging? (Choose THREE)

Accepted Answer

Monitor audit logs regularly for suspicious authentication failures or privilege escalations.. Option C is correct because Kubernetes audit logs record authentication attempts, RBAC authorization decisions, and privileged operations, so regularly monitoring them is essential to detect brute-force authentication failures, unauthorized privilege escalations, and anomalous API activity. Option D is correct because audit logs can contain sensitive data such as request bodies, tokens, and Secret contents, so they must be written to a protected location with restricted file permissions (for example, a log file readable only by root) or forwarded to a centralized SIEM with appropriate access controls and retention. Option E is correct because audit logging is driven by an audit policy file passed to the kube-apiserver via --audit-policy-file, which explicitly defines rules with levels such as None, Metadata, Request, and RequestResponse and specifies which resources, verbs, and namespaces are captured. Option A is not appropriate because ConfigMaps are not a secure or intended storage mechanism for audit logs and exposing them unencrypted publicly would leak sensitive cluster data. Option B is not appropriate because disabling audit logging removes the accountability and forensic trail needed for security monitoring and compliance, and audit logging can be tuned via policy levels rather than turned off entirely.

Answer

Store audit logs in unencrypted public ConfigMaps.

Answer

Disable audit logging entirely to maximize API server performance.

Question 10

Why is running containers as the root user discouraged in Kubernetes platform security best practices?

Accepted Answer

It increases the impact of potential container breakout or compromise by granting root privileges inside the container. Running containers as root is discouraged because if an attacker compromises the container, they gain root privileges inside it. This significantly increases the impact of a container breakout or lateral movement, as root can modify files, install tools, and potentially exploit kernel vulnerabilities to escape to the host. Kubernetes security best practices, such as those in the CIS Benchmarks and Pod Security Standards, therefore recommend running containers as non-root users to enforce least privilege.

Answer

It prevents the kubelet from starting the pod

Answer

It disables network policy enforcement

Answer

It stops container image vulnerability scanning

Question 11

You are reviewing security logs on a control plane node and discover that an unauthenticated user accessed the kubelet's HTTPS port (10250) to execute commands inside containers. How should you restrict kubelet authentication and authorization to prevent this?

Accepted Answer

Set authentication.anonymous.enabled: false and authorization.mode: Webhook in the kubelet configuration file.. Setting authentication.anonymous.enabled to false disables unauthenticated access to the kubelet, and setting authorization.mode to Webhook delegates authorization decisions to the API server, which enforces RBAC. This combination ensures that only authenticated and authorized requests can execute commands via the kubelet, preventing the observed unauthenticated access.

Answer

Enable the kubelet insecure-port flag.

Answer

Set authorization.mode: AlwaysAllow in the kubelet configuration file.

Answer

Disable the API server proxy subresource.

Question 12

You need to audit the cryptographic algorithms and TLS versions permitted by the Kubernetes API server for incoming client connections. Which API server flag enforces a minimum TLS version of 1.3?

Accepted Answer

--tls-min-version=VersionTLS13. The kube-apiserver flag `--tls-min-version` sets the minimum TLS version accepted for incoming client connections. To enforce TLS 1.3, the value must be `VersionTLS13` (the Go constant used by the API server). This flag is part of the secure serving options and is critical for compliance with modern cryptographic standards.

Answer

--min-tls=1.3

Answer

--cipher-suites=TLS_AES_256_GCM_SHA384

Answer

--ssl-version=TLSv3

Question 13

Which TWO of the following metrics or health endpoints should be protected against unauthenticated access on control plane nodes? (Choose TWO)

Accepted Answer

Etcd metrics and health endpoints (typically port 2379/2380).. Option B is correct because etcd exposes sensitive metrics and health endpoints on ports 2379 (client) and 2380 (peer), and unauthenticated access to these can leak cluster state, keys, and allow disruptive operations, so they must be protected on control plane nodes. Option E is correct because the kubelet serves metrics and operational endpoints on port 10250, and unauthenticated access there can expose pod specs, logs, and even permit command execution via the kubelet API, making authentication and authorization essential. Option A is not a control plane health or metrics endpoint; container image caches are local storage artifacts, not network services requiring this protection. Option C refers to external load balancer probe targets, which are typically intentionally reachable and are not control plane node metrics/health endpoints. Option D concerns CoreDNS internal DNS forwarding ports, which are part of cluster DNS service traffic rather than control plane node metrics or health endpoints.

Answer

Container runtime image download caches.

Answer

Public load balancer health check probe targets configured for external routing.

Answer

CoreDNS internal DNS query forwarding ports.

Question 14

What is the primary purpose of vulnerability scanning databases (such as Trivy, Grype, or Clair) when integrated into a container platform?

Accepted Answer

To match package versions inside container images against known CVE databases and report vulnerabilities. Vulnerability scanning databases like Trivy, Grype, and Clair work by extracting the installed package inventory (OS packages, language libraries) from a container image and matching those versions against known CVE feeds such as NVD, GHSA, and vendor advisories. They report CVEs with severity, fixed versions, and package paths so teams can remediate before deployment. This is the core function of an image scanner — it is not a runtime enforcement or networking tool.

Answer

To enforce network microsegmentation rules

Answer

To balance incoming web traffic across backend replicas

Answer

To automatically rotate cluster TLS certificates

Question 15

Which TWO of the following are primary components of the 4Cs of Cloud Native Security model? (Choose TWO)

Accepted Answer

Container. The 4Cs of Cloud Native Security model defines four layers of defense: Cloud, Cluster, Container, and Code, so option A (Container) is correct because the container layer covers securing the container image, its runtime, and its contents. Option D (Code) is also correct because the code layer is the innermost layer, focusing on securing application source code, dependencies, and CI/CD pipelines. The remaining options do not belong: Client (B) is not one of the 4Cs, Crypto (C) is a security mechanism rather than a layer in this model, and Compliance (E) is a governance concern, not a named component of the 4Cs.

Answer

Client

Answer

Crypto

Answer

Compliance