Courseiva

CCNA Compliance And Security Frameworks Questions

27 questions · Compliance And Security Frameworks · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

A compliance officer wants to continuously audit Kubernetes resource manifests for misconfigurations against security best practices before they are applied. Which tool type is best suited for this shift-left compliance approach?

A.Log shippers
B.Packet analyzers
C.Static code analysis and admission controllers
D.Kernel debuggers
AnswerC

Static analysis scans manifests in CI before they reach the cluster, catching misconfigurations at build time, while admission controllers enforce policy at apply time. Together they satisfy the stem's shift-left requirement to audit continuously before resources are applied.

Why this answer

Static code analysis tools (e.g., kube-score, Checkov, kube-linter) scan YAML manifests in CI/CD pipelines to catch misconfigurations like missing resource limits or privileged containers before deployment. Admission controllers (e.g., OPA Gatekeeper, Kyverno) enforce policies at the API server level, rejecting non-compliant resources at admission time. Together, they provide continuous, shift-left auditing that prevents misconfigured workloads from ever reaching the cluster.

Exam trap

KCSA often tests the misconception that runtime monitoring tools (log shippers, packet analyzers) provide compliance auditing, but shift-left specifically requires pre-deployment static analysis and admission control.

How to eliminate wrong answers

Option A is wrong because log shippers (e.g., Fluentd, Filebeat) collect and forward runtime logs; they do not analyze manifest content or enforce policies. Option B is wrong because packet analyzers (e.g., tcpdump, Wireshark) inspect network traffic at the packet level, not Kubernetes resource definitions. Option D is wrong because kernel debuggers (e.g., gdb, bpftrace) diagnose low-level kernel or process issues, not manifest compliance.

Practice this question →
2
MCQhard

An auditor is assessing compliance with NIST SP 800-53 controls for access control (AC) within a managed Kubernetes cluster. Which API object enforces fine-grained authorization decisions directly at the Kubernetes API server?

A.ValidatingWebhookConfiguration
B.NetworkPolicy
C.ClusterRoleBinding
D.ResourceQuota
AnswerC

ClusterRoleBinding grants a subject (user, group, or service account) the permissions defined in a ClusterRole across the entire cluster, and the API server's authorisation chain evaluates it for every request, satisfying NIST SP 800-53 AC controls.

Why this answer

ClusterRoleBinding is the Kubernetes RBAC API object that binds a ClusterRole (or Role) to subjects (users, groups, service accounts) cluster-wide, and the API server evaluates these bindings during authorization. It directly enforces fine-grained authorization decisions at the API server, satisfying NIST SP 800-53 AC controls for least privilege and role-based access. Without a binding, a role grants nothing — the binding is what activates the permissions.

Exam trap

KCSA often tests the confusion between admission control (ValidatingWebhookConfiguration), network policy, resource quotas, and RBAC — candidates must recognize that only RoleBinding/ClusterRoleBinding objects drive API server authorization decisions.

How to eliminate wrong answers

Option A is wrong because ValidatingWebhookConfiguration registers an admission webhook that validates API requests against custom logic, but it is not the native RBAC authorization mechanism — it is admission control, a different stage. Option B is wrong because NetworkPolicy controls pod-to-pod network traffic (L3/L4), not API server authorization decisions. Option D is wrong because ResourceQuota limits aggregate resource consumption (CPU, memory, object counts) per namespace, not who can perform which API actions.

Practice this question →
3
MCQhard

An enterprise undergoes an ISO/IEC 27001 audit for their Kubernetes environment. The auditor requests evidence that secrets at rest are encrypted. Which configuration component enables encryption of Secret resources in etcd?

A.EncryptionConfiguration API
B.Kubelet TLS bootstrapping
C.SecretProviderClass CRD
D.ServiceAccount token volume projection
AnswerA

The EncryptionConfiguration API defines which resources are encrypted in etcd and which provider handles the encryption, such as AES-CBC or KMS v2. Supplying this file to the kube-apiserver via the --encryption-provider-config flag satisfies the auditor's requirement for evidence that Secret resources are encrypted at rest.

Why this answer

The EncryptionConfiguration API in Kubernetes defines how etcd encrypts Secret and other resources at rest, specifying providers (e.g., aesgcm, aescbc, kms) and key material. Auditors verifying ISO/IEC 27001 encryption-at-rest controls for Kubernetes look for this configuration as evidence. It is the authoritative component for encrypting Secret resources in etcd.

Exam trap

The trap is confusing in-transit controls (kubelet TLS, token projection) or external secret stores (SecretProviderClass) with etcd encryption at rest — only EncryptionConfiguration governs Secret encryption in etcd.

How to eliminate wrong answers

Option B is wrong because Kubelet TLS bootstrapping secures node-to-API-server communication in transit, not data at rest in etcd. Option C is wrong because SecretProviderClass is a Secrets Store CSI Driver CRD for mounting external secrets (e.g., from Vault) into pods, not for encrypting etcd data. Option D is wrong because ServiceAccount token volume projection manages token issuance and rotation for pods, unrelated to etcd encryption at rest.

Practice this question →
4
MCQmedium

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

A.--authorization-mode=Node,RBAC
B.--anonymous-auth=false
C.--enable-admission-plugins
D.--insecure-port=0
AnswerB

Setting `--anonymous-auth=false` on the kube-apiserver rejects unauthenticated requests to the API server, satisfying the CIS Kubernetes Benchmark control that requires anonymous access to be disabled. Requests without valid credentials then receive a 401 Unauthorised response rather than being mapped to the `system:anonymous` user and `system:unauthenticated` group.

Why this answer

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.

Exam trap

KCSA often tests the difference between authentication and authorization flags; candidates may confuse --authorization-mode with --anonymous-auth, leading to wrong answers.

How to eliminate wrong answers

Option A is wrong because --authorization-mode=Node,RBAC controls authorization, not authentication; it does not disable anonymous access. Option C is wrong because --enable-admission-plugins enables admission controllers, which are unrelated to anonymous authentication. Option D is wrong because --insecure-port=0 disables the insecure HTTP port, but anonymous requests can still be made over HTTPS if --anonymous-auth is not set to false.

Practice this question →
5
MCQeasy

An enterprise is adopting the Cloud Native Security Framework to map their controls. Which of the 4Cs of Cloud Native Security represents the outermost layer encompassing physical data centers and hardware?

A.Clusters
B.Cloud
C.Code
D.Containers
AnswerB

The Cloud layer is the outermost of the 4Cs, covering the physical data centres, hardware, and underlying infrastructure that hosts everything above it. Controls here address physical security and provider-level protections, forming the foundation beneath clusters, containers, and code.

Why this answer

The Cloud layer is the outermost of the 4Cs of Cloud Native Security (Cloud, Clusters, Containers, Code), representing the underlying infrastructure — physical data centers, hardware, and the cloud provider's IaaS layer. It encompasses the security of the cloud provider's environment, including physical security, hypervisor security, and network infrastructure. The 4Cs model, popularized by Kubernetes, emphasizes that security at each inner layer depends on the outer layer.

Exam trap

KCSA often tests the ordering and scope of the 4Cs, causing candidates to confuse the Cloud layer (physical infrastructure) with the Clusters layer (Kubernetes control plane) because both sound 'infrastructure-related'.

How to eliminate wrong answers

Option A is wrong because Clusters is the second layer (after Cloud) and covers the Kubernetes control plane, nodes, and cluster networking, not physical data centers. Option C is wrong because Code is the innermost layer, covering application source code, dependencies, and CI/CD pipeline security. Option D is wrong because Containers is the third layer, covering container images, runtime, and orchestration, not the physical infrastructure.

Practice this question →
6
Multi-Selecteasy

When evaluating a Kubernetes cluster against security and compliance baselines, which TWO tools are commonly used for automated auditing and benchmarking? (Choose TWO)

Select 2 answers
A.Kustomize
B.kube-bench
C.Helm
D.Kubescape
E.Kubectl
AnswersB, D

kube-bench automates the CIS Kubernetes Benchmark, checking control plane and node configuration against hardening baselines. It satisfies the auditing requirement by inspecting running components and reporting pass/fail results, making it a standard benchmarking tool for cluster compliance assessments.

Why this answer

kube-bench (B) is correct because it is an open-source tool from Aqua Security that automates the checks of the CIS Kubernetes Benchmark, inspecting the cluster's control plane components, kubelet, and configuration files to report pass/fail results against the benchmark. Kubescape (D) is correct because it is an ARMO tool that performs automated security and compliance scanning of Kubernetes clusters, mapping results to frameworks such as the NSA/CISA Kubernetes Hardening Guidance, MITRE ATT&CK, and CIS benchmarks. Kustomize (A) is a configuration management tool for customizing Kubernetes YAML manifests via overlays, not an auditing or benchmarking tool.

Helm (C) is a package manager for deploying and managing Kubernetes applications using charts, not a compliance scanner. Kubectl (E) is the Kubernetes command-line client for interacting with the API server, not an automated auditing or benchmarking tool.

Exam trap

KCSA often tests the confusion between general Kubernetes tools (Helm, Kustomize, kubectl) and specialized security auditing tools, leading candidates to select non-security tools.

Practice this question →
7
MCQeasy

A security analyst wants to scan container images for known Common Vulnerabilities and Exposures (CVEs) as part of a continuous compliance pipeline. Which tool is widely used for this purpose?

A.Envoy
B.CoreDNS
C.Trivy
D.Calico
AnswerC

Trivy scans container images for known CVEs, satisfying the continuous compliance pipeline requirement. It inspects OS packages and language dependencies, matching them against vulnerability databases. Unlike runtime tools such as Falco, which detect behavioural threats, Trivy performs static image analysis, making it suited to pre-deployment pipeline scanning.

Why this answer

Trivy is an open-source vulnerability scanner for container images, filesystems, and Git repositories. It detects known CVEs in OS packages and application dependencies, making it ideal for continuous compliance pipelines.

Exam trap

KCSA often tests the confusion between networking tools (Envoy, Calico, CoreDNS) and security scanning tools, causing candidates to pick a CNI or DNS component instead of Trivy.

How to eliminate wrong answers

Option A is wrong because Envoy is a service proxy for networking, not a vulnerability scanner. Option B is wrong because CoreDNS is a DNS server for Kubernetes service discovery. Option D is wrong because Calico is a CNI plugin for network policy and security, not an image scanner.

Practice this question →
8
MCQhard

A security engineer is configuring kube-apiserver audit logging to satisfy NIST compliance requirements. Which configuration file specifies which requests are logged and at what log level?

A.kubeadm.conf
B.Kubelet configuration file
C.Admission configuration YAML
D.Audit policy file
AnswerD

The audit policy file defines exactly which requests are recorded and at which level, using rules that match on users, verbs, resources and namespaces. Passing it to kube-apiserver via --audit-policy-file satisfies the NIST requirement to log specified request categories at defined depths.

Why this answer

The audit policy file is the Kubernetes resource that defines which requests are logged and at what level (None, Metadata, Request, RequestResponse). It is passed to the kube-apiserver via the --audit-policy-file flag, and the apiserver evaluates each request against the policy rules to determine logging behavior. Other configuration files govern different components and do not control audit logging.

Exam trap

KCSA often tests which configuration file controls which apiserver behavior — candidates confuse audit policy with admission configuration because both are YAML files passed to the apiserver, but only the audit policy defines logging levels and rules.

How to eliminate wrong answers

Option A is wrong because kubeadm.conf is a kubeadm configuration file used for cluster initialization and upgrade parameters, not for audit logging rules. Option B is wrong because the Kubelet configuration file controls the kubelet (node agent) settings such as cgroup driver and eviction thresholds, not apiserver audit behavior. Option C is wrong because the Admission configuration YAML configures admission controllers (e.g., PodSecurity, ImagePolicyWebhook), which validate or mutate requests but do not define audit logging levels or rules.

Practice this question →
9
Multi-Selecthard

An auditor is inspecting a Kubernetes cluster for compliance with the CIS Benchmark for etcd security. Which THREE configurations must be verified for the etcd cluster? (Choose THREE)

Select 3 answers
A.Peer communication is encrypted using TLS certificates
B.Client certificate authentication is enabled for etcd (--client-cert-auth=true)
C.etcd auto-compaction is permanently disabled
D.etcd is exposed directly on the public internet without authentication
E.etcd data directory permissions are restricted (e.g., 700)
AnswersA, B, E

CIS etcd controls require peer traffic between etcd members to be encrypted, preventing eavesdropping or tampering on the replication channel. Verifying TLS certificates on the peer port satisfies this transport-encryption requirement, distinct from client-facing authentication controls.

Why this answer

Option A is correct because the CIS Benchmark for etcd requires that peer (server-to-server) communication be encrypted with TLS certificates to protect cluster traffic between etcd members from eavesdropping or tampering. Option B is correct because enabling client certificate authentication via the --client-cert-auth=true flag ensures that only clients presenting a valid certificate signed by the trusted CA can connect to etcd, which is a core CIS control. Option E is correct because the etcd data directory (typically /var/lib/etcd) must have restrictive permissions such as 700 so that only the etcd process owner can read or write the sensitive key-value store and its WAL files.

Option C does not belong because auto-compaction is a maintenance feature and the benchmark does not require it to be permanently disabled. Option D is clearly wrong because exposing etcd directly to the public internet without authentication is a severe misconfiguration that the CIS Benchmark explicitly prohibits.

Exam trap

KCSA often tests whether candidates confuse operational best practices (like auto-compaction) with actual CIS security controls, so options that sound like tuning parameters are usually distractors.

Practice this question →
10
MCQeasy

Which CNCF project acts as a cloud-native runtime security and intrusion detection tool that monitors system calls against predefined security rules?

A.Trivy
B.Fluentd
C.Falco
D.Cert-manager
AnswerC

Falco is the CNCF runtime security project that instruments kernel system calls, evaluating them against a rule set to detect anomalous or malicious container behaviour. It satisfies the stem's requirement for runtime intrusion detection monitoring syscalls against predefined rules.

Why this answer

Falco is the CNCF-graduated cloud-native runtime security project that detects anomalous activity and intrusions by monitoring Linux system calls (and Kubernetes audit events) against a rule engine. It uses a kernel module or eBPF probe to capture syscalls and evaluates them against YAML-defined rules, generating alerts when behavior matches known attack patterns. This makes it the canonical answer for runtime threat detection in Kubernetes environments.

Exam trap

The trap is confusing scanning tools with runtime detection tools — candidates may pick Trivy because it is security-related, but Trivy scans images statically while Falco monitors live syscalls, which is what 'runtime security and intrusion detection' specifically requires.

How to eliminate wrong answers

Option A is wrong because Trivy is a vulnerability and misconfiguration scanner for container images, filesystems, and IaC — it performs static analysis, not runtime syscall monitoring. Option B is wrong because Fluentd is a log collection and forwarding agent (part of the observability stack), not a security rule engine that inspects syscalls. Option D is wrong because cert-manager automates X.509 certificate issuance and renewal (e.g., via Let's Encrypt or Vault) — it has nothing to do with runtime intrusion detection.

Practice this question →
11
MCQmedium

An auditor notices that kubelet authentication is set to always allow anonymous access in a cluster configuration. According to the CIS Benchmark, what should the kubelet configuration parameter "authentication.anonymous.enabled" be set to?

A.strict
B.auto
C.true
D.false
AnswerD

Setting `authentication.anonymous.enabled` to false disables unauthenticated requests to the kubelet API, satisfying the CIS Benchmark requirement that anonymous access be eliminated. This closes the exposure the auditor identified, forcing every request to authenticate via client certificates or bearer tokens before the kubelet processes it.

Why this answer

The CIS Kubernetes Benchmark explicitly requires that anonymous authentication to the kubelet be disabled. Setting authentication.anonymous.enabled to false ensures that unauthenticated requests to the kubelet's HTTPS endpoint are rejected, forcing all clients to authenticate. This prevents unauthorized users or workloads from querying sensitive node information or executing commands via the kubelet API.

Exam trap

KCSA often tests the misconception that 'strict' or 'auto' are valid boolean values for kubelet authentication settings, when in fact the parameter expects true or false, and the secure setting is false.

How to eliminate wrong answers

Option A is wrong because 'strict' is not a valid value for authentication.anonymous.enabled; it is a boolean field, and 'strict' might be confused with authentication.webhook.enabled or authorization modes. Option B is wrong because 'auto' is not a valid boolean value and does not correspond to any kubelet authentication setting. Option C is wrong because setting it to true would enable anonymous access, which directly violates the CIS Benchmark recommendation and exposes the kubelet to unauthenticated requests.

Practice this question →
12
Multi-Selecteasy

Which TWO actions are core tenets of the "Shift-Left" security philosophy in cloud-native compliance? (Choose TWO)

Select 2 answers
A.Disabling all automated security tooling to speed up commits
B.Scanning infrastructure-as-code (IaC) templates for misconfigurations before deployment
C.Waiting until a production breach occurs to audit logs
D.Integrating vulnerability scanning directly into the CI/CD pipeline
E.Relying entirely on manual code reviews post-release
AnswersB, D

Scanning IaC templates pre-deployment catches misconfigurations while they remain cheap, editable code rather than live cloud resources. This satisfies Shift-Left's core tenet of moving security controls into earlier development phases, before artefacts reach production, where remediation demands change requests, redeployment and potential outage windows.

Why this answer

Option B is correct because Shift-Left security means identifying misconfigurations in infrastructure-as-code (IaC) templates such as Terraform, CloudFormation, or Kubernetes manifests during development, before any resources are provisioned, so issues are caught early when they are cheapest and safest to fix. Option D is correct because embedding vulnerability scanning (for example SAST, SCA, or container image scanning) directly into the CI/CD pipeline enforces automated security gates on every commit or build, which is the operational core of shifting security left into the development lifecycle. Option A is wrong because disabling automated security tooling removes the very guardrails Shift-Left depends on and increases risk rather than reducing it.

Option C is wrong because auditing only after a production breach is a reactive, right-side-of-development approach, the opposite of Shift-Left. Option E is wrong because relying solely on manual post-release code reviews is late, non-automated, and does not prevent defects from reaching production.

Exam trap

KCSA often tests the misconception that Shift-Left means adding more manual review steps or post-release audits, when it actually means automating security checks earlier in the pipeline.

Practice this question →
13
Multi-Selectmedium

A compliance team is adopting the NIST SP 800-190 standard to secure their container image pipeline. Which THREE practices are recommended in this framework for managing container images? (Choose THREE)

Select 3 answers
A.Employ trusted base images from verified publishers
B.Implement vulnerability scanning in the CI/CD pipeline and registry
C.Store plaintext passwords directly inside Dockerfile ENV directives
D.Rely exclusively on public unverified base images to speed up development
E.Use digitally signed images to verify provenance and integrity
AnswersA, B, E

NIST SP 800-190 advises building images from trusted, verified base images to reduce inherited vulnerabilities and untrusted content. This directly addresses the image provenance risk in the pipeline, satisfying the framework's recommendation for controlling image sources.

Why this answer

NIST SP 800-190 Section 3.1 (Image Vulnerabilities) recommends using trusted base images from verified publishers (A) to reduce the risk of inheriting vulnerabilities or malicious code from untrusted sources, since every layer of a container image becomes part of the running container. The framework also calls for vulnerability scanning throughout the image lifecycle, including in the CI/CD pipeline and the registry (B), so that known CVEs are detected before deployment and continuously re-evaluated as new vulnerabilities are disclosed. Additionally, NIST SP 800-190 recommends digitally signing images and verifying those signatures (E) to establish provenance and integrity, ensuring that only images from authorized sources are deployed and that images have not been tampered with.

Option C is incorrect because storing plaintext passwords in Dockerfile ENV directives exposes secrets in image layers and metadata, directly violating NIST guidance on protecting secrets. Option D is incorrect because relying exclusively on public unverified base images increases supply-chain risk and contradicts the recommendation to use trusted, verified image sources.

Exam trap

KCSA often tests whether candidates conflate 'using containers' with 'securing containers' — the trap is picking convenience-oriented answers (public images, plaintext env vars) that speed development but violate NIST SP 800-190's explicit provenance, scanning, and secrets-management requirements.

Practice this question →
14
MCQeasy

An administrator needs to evaluate an existing Kubernetes cluster against the CIS Kubernetes Benchmark. Which tool provides automated scanning specifically tailored to this benchmark?

A.kube-hunter
B.falco
C.velero
D.kube-bench
AnswerD

kube-bench runs the CIS Kubernetes Benchmark checks directly against cluster components, covering control plane, nodes, policies and etcd. It is purpose-built for that benchmark, unlike general vulnerability or configuration scanners, so it satisfies the requirement for automated scanning specifically tailored to CIS.

Why this answer

kube-bench is an open-source tool from Aqua Security that runs automated checks directly against the CIS Kubernetes Benchmark, inspecting control plane components, kubelet configuration, and node settings. It reports PASS/FAIL/WARN results mapped to specific CIS controls, making it the purpose-built tool for benchmark evaluation.

Exam trap

KCSA often tests tool-purpose mapping, baiting candidates who confuse offensive scanners (kube-hunter) or runtime detectors (Falco) with compliance benchmark tools like kube-bench.

How to eliminate wrong answers

Option A is wrong because kube-hunter is an offensive penetration-testing tool that probes for exploitable vulnerabilities from an attacker's perspective, not a CIS benchmark scanner. Option B is wrong because Falco is a runtime security tool that detects anomalous syscall and container behavior via eBPF/kernel modules, not a configuration benchmark scanner. Option C is wrong because Velero is a backup and disaster-recovery tool for Kubernetes cluster resources and persistent volumes, unrelated to CIS compliance.

Practice this question →
15
Multi-Selectmedium

A security architect is designing role-based access control (RBAC) to comply with NIST access control principles of least privilege. Which THREE best practices should be followed when creating Roles and ClusterRoles? (Choose THREE)

Select 3 answers
A.Scrutinize and restrict the use of ClusterRoleBindings to cluster-wide resources
B.Avoid using wildcards (*) in API groups, resources, and verbs where possible
C.Allow all users to read Kubernetes Secrets by default
D.Grant cluster-admin permissions to all application service accounts for ease of deployment
E.Regularly audit RBAC permissions and bindings
AnswersA, B, E

Restricting ClusterRoleBindings to genuinely cluster-scoped resources prevents namespace-bound workloads inheriting cluster-wide permissions, directly enforcing least privilege. Because ClusterRoleBindings grant access across every namespace, scrutinising each binding limits lateral movement and privilege escalation, satisfying NIST's requirement that subjects receive only the minimum access necessary for their function.

Why this answer

Option A is correct because ClusterRoleBindings grant permissions across the entire cluster, so they should be tightly scrutinized and reserved for genuinely cluster-scoped resources to uphold least privilege. Option B is correct because wildcards (*) in API groups, resources, or verbs grant far broader access than intended, violating least privilege and increasing blast radius; explicit permissions should be enumerated instead. Option E is correct because RBAC permissions drift over time as roles and bindings accumulate, so regular auditing is essential to detect and remove excessive or stale privileges.

Options C and D are incorrect: allowing all users to read Secrets by default and granting cluster-admin to all service accounts both directly violate least privilege by providing excessive, unnecessary access.

Exam trap

The trap is that options C and D sound like they simplify administration, but they directly contradict least privilege; candidates must recognize that convenience is not a security best practice.

Practice this question →
16
MCQeasy

Which NIST framework publication specifically addresses the security of container-based applications and orchestration systems?

A.NIST SP 800-190
B.NIST SP 800-37
C.NIST SP 800-53
D.NIST SP 800-88
AnswerA

NIST SP 800-190, "Application Container Security Guide", addresses container threats and countermeasures across image, registry, orchestrator, container and host layers. It is the publication dedicated to container-based applications and orchestration systems, satisfying the stem's specific framework requirement.

Why this answer

NIST SP 800-190, 'Application Container Security Guide', specifically addresses the security of container-based applications and orchestration systems. It provides guidance on container threats, vulnerabilities, and countermeasures, making it the correct publication for this topic.

Exam trap

KCSA often tests the specific NIST publication for container security; candidates may confuse it with broader frameworks like SP 800-53 or SP 800-37, which are not container-specific.

How to eliminate wrong answers

Option B is wrong because NIST SP 800-37 is the Risk Management Framework (RMF), which is a general security lifecycle framework, not specific to containers. Option C is wrong because NIST SP 800-53 is a catalog of security and privacy controls for federal information systems, not container-specific. Option D is wrong because NIST SP 800-88 provides guidelines for media sanitization, unrelated to containers.

Practice this question →
17
MCQmedium

Under NIST guidelines for continuous monitoring in cloud-native environments, which Kubernetes mechanism allows operators to enforce cryptographic integrity of container images at runtime?

A.Image signing and verification via admission controllers
B.Increasing pod memory limits
C.Disabling the default namespace
D.Using ClusterRoleBindings with wildcards
AnswerA

Admission controllers intercept pod creation and verify cryptographic signatures against trusted keys before permitting the image to run. This enforces integrity at runtime admission, satisfying NIST continuous monitoring by blocking unsigned or tampered images from executing in the cluster.

Why this answer

Admission controllers in Kubernetes can intercept pod creation requests and validate that container images are signed by trusted authorities before allowing them to run. By integrating image signing (e.g., Cosign/Notary) with an admission controller (e.g., OPA Gatekeeper, Kyverno, or the Sigstore policy controller), operators enforce cryptographic integrity at runtime admission. This directly satisfies NIST continuous monitoring guidance for verifying artifact integrity in cloud-native environments.

Exam trap

The trap is confusing resource or RBAC settings (memory limits, namespace changes, wildcard bindings) with actual integrity enforcement mechanisms — only admission control combined with image signing provides cryptographic verification.

How to eliminate wrong answers

Option B is wrong because increasing pod memory limits is a resource tuning action with no security or integrity enforcement capability. Option C is wrong because disabling the default namespace is a weak hygiene measure that does not verify image integrity and can break workloads relying on that namespace. Option D is wrong because ClusterRoleBindings with wildcards grant excessive permissions, expanding the attack surface rather than enforcing cryptographic image integrity — it is an anti-pattern, not a control.

Practice this question →
18
MCQhard

An organization requires compliance auditing of etcd access to ensure unauthorized clients cannot communicate with the data store. According to CIS benchmarks, how should etcd client communication be secured?

A.IPsec tunnel encapsulation
B.Mutual TLS (mTLS) client certificates
C.HTTP with token bearer headers
D.Plaintext loopback interface binding
AnswerB

Mutual TLS forces both etcd server and client to present certificates signed by a trusted CA, so unauthenticated clients are rejected during the handshake. This directly satisfies the CIS benchmark requirement for encrypted, authenticated etcd client communication, preventing unauthorised access to the data store.

Why this answer

CIS Kubernetes Benchmark requires that etcd client communication be encrypted and mutually authenticated. Mutual TLS (mTLS) ensures both the client and the etcd server present certificates signed by a trusted CA, preventing unauthorized clients from connecting. This is enforced via flags like --cert-file, --key-file, --client-cert-auth, and --trusted-ca-file on the etcd server.

Exam trap

KCSA often tests the misconception that network-level controls like IPsec or loopback binding satisfy CIS etcd requirements, when the benchmark specifically mandates mutual TLS client certificate authentication.

How to eliminate wrong answers

Option A is wrong because IPsec tunnel encapsulation is a network-layer VPN technique, not the CIS-prescribed method for etcd client authentication and is not how etcd verifies client identity. Option C is wrong because HTTP with token bearer headers provides no transport encryption and etcd does not use bearer tokens for client authentication. Option D is wrong because plaintext loopback binding only restricts etcd to localhost without encryption or authentication, and it does not satisfy CIS requirements for client communication security.

Practice this question →
19
MCQmedium

A security engineer needs to verify that control plane component pods (such as kube-apiserver and etcd) have correct file ownership on the control plane node. According to CIS benchmarks, who should own these manifest files located in "/etc/kubernetes/manifests"?

A.nobody:nogroup
B.root:root
C.daemon:daemon
D.kube:kube
AnswerB

CIS benchmarks mandate root:root ownership for control plane static pod manifests in /etc/kubernetes/manifests, including kube-apiserver and etcd definitions. This prevents unprivileged users from modifying pod specifications, which could otherwise alter API server flags or etcd configuration and compromise the entire cluster's control plane integrity.

Why this answer

CIS Kubernetes Benchmark requires that control plane manifest files in /etc/kubernetes/manifests (static pod manifests for kube-apiserver, etcd, kube-controller-manager, kube-scheduler) be owned by root:root with permissions 644 or more restrictive. This prevents unprivileged users from modifying critical control plane definitions.

Exam trap

KCSA often tests the assumption that Kubernetes service accounts like kube:kube own control plane files, when in fact CIS benchmarks mandate root:root for all static pod manifests.

How to eliminate wrong answers

Option A is wrong because nobody:nogroup is used for unprivileged daemons, not for critical control plane files; assigning these files to nobody would allow any process running as nobody to tamper with the API server or etcd. Option C is wrong because daemon:daemon is a legacy Unix account for background services and is not the CIS-mandated owner for Kubernetes control plane manifests. Option D is wrong because kube:kube is not a standard system account on control plane nodes; Kubernetes components run as root in static pods, and the files must be root-owned to prevent privilege escalation.

Practice this question →
20
Multi-Selectmedium

A security team is implementing Pod Security Standards (restricted, baseline, privileged) across namespaces. Which THREE controls are enforced under the Restricted Pod Security profile? (Choose THREE)

Select 3 answers
A.Requiring all capabilities to be dropped except NET_BIND_SERVICE or dropping all (capabilities.drop: [ALL])
B.Requiring containers to run as a non-root user (runAsNonRoot: true)
C.Disallowing privilege escalation (allowPrivilegeEscalation: false)
D.Allowing unrestricted use of the host network and host PID namespaces
E.Enabling privileged mode for all standard workloads
AnswersA, B, C

Restricted builds on baseline by requiring containers to drop all Linux capabilities, permitting only NET_BIND_SERVICE to be added back. This capability restriction limits the kernel privileges a compromised container can exploit, satisfying the Restricted profile's hardening requirement.

Why this answer

The Restricted Pod Security profile is the most stringent of the three Pod Security Standards and enforces hardening controls on every container. Option A is correct because Restricted requires that Linux capabilities be dropped, either by dropping ALL (capabilities.drop: [ALL]) or by dropping all except NET_BIND_SERVICE, preventing containers from retaining dangerous privileges. Option B is correct because Restricted mandates runAsNonRoot: true, ensuring containers do not run as UID 0 (root), which limits the impact of a container compromise.

Option C is correct because Restricted requires allowPrivilegeEscalation: false, blocking processes from gaining more privileges than their parent (for example via setuid binaries or file capabilities). Options D and E are incorrect because allowing host network/host PID namespaces and enabling privileged mode are explicitly forbidden by the Restricted profile (and privileged mode is only permitted under the Privileged profile), so they do not represent enforced Restricted controls.

Exam trap

The trap here is confusing Baseline and Restricted controls; candidates often think host namespaces or privileged mode are allowed under Restricted when they are explicitly forbidden.

Practice this question →
21
MCQhard

A security team is implementing NIST SP 800-190 guidelines for container runtime security. Which kernel feature is leveraged by container runtimes to restrict system calls and meet least-privilege execution requirements?

A.Seccomp profiles
B.cgroups v2
C.AppArmor MAC profiles
D.Namespaces
AnswerA

Seccomp profiles restrict the system calls a container process may invoke, enforcing least-privilege execution at the kernel level. NIST SP 800-190 recommends this syscall filtering to reduce the container attack surface, satisfying the runtime restriction requirement.

Why this answer

Seccomp (secure computing mode) profiles are the kernel feature that filters which system calls a container process may invoke, directly enforcing least-privilege execution at the syscall boundary. NIST SP 800-190 explicitly calls out seccomp as a runtime control to reduce the kernel attack surface. By applying a seccomp profile (e.g., RuntimeDefault or a custom allowlist), the runtime blocks dangerous syscalls like ptrace or mount that a compromised container might abuse.

Exam trap

KCSA often tests the confusion between isolation primitives (namespaces), resource controls (cgroups), MAC frameworks (AppArmor/SELinux), and syscall filtering (seccomp) — candidates frequently pick namespaces or AppArmor when the question specifically asks about restricting system calls.

How to eliminate wrong answers

Option B is wrong because cgroups v2 handles resource accounting and limits (CPU, memory, I/O), not syscall filtering — it does not restrict which kernel operations a process can perform. Option C is wrong because AppArmor is a Mandatory Access Control system that confines programs by path and capability profiles, not by syscall filtering; it complements but does not replace seccomp. Option D is wrong because namespaces provide isolation of views (PID, network, mount, user) but do not restrict the set of syscalls a process can call — a container in its own namespace can still invoke any syscall the kernel allows.

Practice this question →
22
MCQhard

A financial services company runs Kubernetes clusters in multiple regions. Their compliance team must demonstrate that cryptographic keys used for etcd encryption at rest are rotated according to a defined schedule and that access to these keys is logged. Which Kubernetes feature directly supports meeting this requirement?

A.Setting the --encryption-provider-config flag on kube-apiserver with a local aescbc key.
B.Enabling encryption at rest with a KMS provider plugin.
C.Deploying a service mesh with mutual TLS between all pods.
D.Configuring etcd to use TLS client certificate authentication.
AnswerB

Using a KMS provider plugin for encryption at rest allows the cluster to delegate key management to an external key management service. This enables automatic key rotation based on the KMS provider's policies and provides audit logs of key usage from the KMS. It directly addresses both rotation and access logging, which are core compliance requirements for cryptographic key management.

Why this answer

A KMS provider plugin integrates Kubernetes with an external key management system, enabling automated key rotation and detailed audit logs of key usage. This directly satisfies the compliance need for scheduled rotation and logged access. Local encryption keys require manual rotation and lack access logging.

TLS and service mesh options address transport security, not data-at-rest key management.

Exam trap

The trap here is assuming that any encryption mechanism satisfies key rotation and logging requirements, when only a KMS provider plugin offers the necessary lifecycle management and audit trails.

Practice this question →
23
MCQeasy

Which open-source auditing tool provides compliance scores and checks against Kubernetes security frameworks such as NSA-CISA and CIS?

A.Kube-dns
B.Metric-server
C.Cilium
D.Kubescape
AnswerD

Kubescape scans Kubernetes clusters and manifests, producing compliance scores mapped to frameworks including NSA-CISA and CIS benchmarks. Its posture reports and risk scoring directly satisfy the requirement for an open-source auditing tool that grades clusters against those named security frameworks.

Why this answer

Kubescape is an open-source Kubernetes security platform that scans clusters and manifests against frameworks like NSA-CISA, MITRE ATT&CK, and CIS Benchmarks, producing compliance scores and remediation guidance. It is specifically designed for Kubernetes posture management and is widely used in CNCF-aligned environments. The other options are Kubernetes components or networking tools, not auditing/compliance scanners.

Exam trap

KCSA often tests the confusion between networking/observability tools (Cilium, Metric-server) and dedicated security posture scanners (Kubescape), leading candidates to pick a CNI tool for compliance scoring.

How to eliminate wrong answers

Option A is wrong because Kube-dns (CoreDNS) provides DNS resolution for services and pods, not security auditing or compliance scoring. Option B is wrong because Metric-server collects resource metrics for HPA and kubectl top, not security posture. Option C is wrong because Cilium is a CNI/eBPF-based networking, observability, and security tool, but it does not provide compliance scores against NSA-CISA or CIS frameworks.

Practice this question →
24
Multi-Selecthard

An enterprise is enforcing the CIS Kubernetes Benchmark for control plane configuration. Which TWO parameters must be correctly configured on the kube-apiserver to meet strict compliance auditing standards? (Choose TWO)

Select 2 answers
A.--audit-policy-file
B.--service-account-lookup=false
C.--enable-bootstrap-auth-only=true
D.--profiling=true
E.--audit-log-path
AnswersA, E

Supplying --audit-policy-file defines the audit rules and stages the API server records, satisfying the CIS requirement for a defined audit policy. Without it, no audit events are generated, so compliance auditing cannot evidence control plane activity.

Why this answer

Option A (--audit-policy-file) is correct because the CIS Kubernetes Benchmark requires the API server to have an audit policy defined that specifies what events are recorded and at what level; without this flag the apiserver cannot apply a compliant audit policy. Option E (--audit-log-path) is correct because CIS requires audit logging to be enabled and written to a defined destination, and this flag sets the file path where audit events are persisted for compliance auditing. Option B (--service-account-lookup=false) is wrong because CIS requires service account token lookup to remain enabled (true), since disabling it weakens token validation.

Option C (--enable-bootstrap-auth-only=true) is wrong because it is not a valid kube-apiserver flag and does not correspond to any CIS control. Option D (--profiling=true) is wrong because CIS recommends disabling profiling (--profiling=false) to reduce information exposure on the control plane.

Exam trap

KCSA often tests specific kube-apiserver flags required by CIS; candidates may confuse audit-related flags with other security flags like --profiling or --service-account-lookup, which are not part of the audit requirement.

Practice this question →
25
MCQhard

An auditor reviews container runtime configurations for compliance with NIST SP 800-190 recommendations on privilege escalation. Which Kubernetes feature controls whether a process can gain more privileges than its parent process?

A.allowPrivilegeEscalation: false
B.automountServiceAccountToken: false
C.runAsUser: 1000
D.privileged: false
AnswerA

Setting allowPrivilegeEscalation to false in the container's security context applies the no_new_privs kernel flag, preventing processes from gaining more privileges than their parent, such as via setuid binaries. This directly satisfies NIST SP 800-190's privilege-escalation control.

Why this answer

allowPrivilegeEscalation: false is the Kubernetes SecurityContext field that directly controls whether a process can gain more privileges than its parent process, aligning with NIST SP 800-190 guidance on preventing privilege escalation. When set to false, it sets the kernel's no_new_privs flag on the container process, blocking setuid/setgid binaries and file capabilities from elevating privileges. This is the precise control the auditor is looking for.

Exam trap

The trap is confusing related SecurityContext fields — candidates may pick runAsUser or privileged: false because they sound like privilege controls, but only allowPrivilegeEscalation: false specifically addresses a process gaining more privileges than its parent, which is the exact NIST SP 800-190 wording.

How to eliminate wrong answers

Option B is wrong because automountServiceAccountToken: false controls whether the ServiceAccount token is mounted into the Pod — it is about credential exposure, not process privilege escalation. Option C is wrong because runAsUser: 1000 sets the UID the container process runs as, which reduces privilege but does not prevent a setuid binary from escalating to root — it is a related but distinct control. Option D is wrong because privileged: false (the default) disables privileged mode (which would grant all capabilities and host device access), but it does not set no_new_privs and therefore does not block setuid-based escalation.

Practice this question →
26
Multi-Selecthard

An enterprise security auditor is reviewing Kubernetes API server admission control configurations for compliance. Which THREE admission plugins or mechanisms are critical for enforcing security policies at admission time? (Choose THREE)

Select 3 answers
A.ValidatingAdmissionWebhook
B.PodSecurity
C.InsecureServing
D.NodeRestriction
E.AlwaysAllow
AnswersA, B, D

ValidatingAdmissionWebhook calls an external HTTPS service to evaluate custom policies against incoming API requests, rejecting non-compliant objects before persistence. It satisfies the auditor's requirement for policy enforcement at admission time, enabling arbitrary organisational controls beyond built-in plugins.

Why this answer

ValidatingAdmissionWebhook (A) is correct because it lets the API server call external webhook endpoints to validate requests against custom security policies before persistence, enabling enforcement of organization-specific compliance rules. PodSecurity (B) is correct because it enforces the Pod Security Standards (privileged, baseline, restricted) at the namespace level via admission, blocking pods that violate the configured security profile. NodeRestriction (D) is correct because it is an admission plugin that limits kubelet credentials so a node can only modify its own Node object and Pods bound to it, preventing a compromised node from escalating cluster-wide.

InsecureServing (C) is not an admission plugin but a deprecated API server serving option for unauthenticated/insecure port access, and AlwaysAllow (E) is an authorization mode that permits all requests, so neither enforces security policy at admission time.

Exam trap

KCSA often tests the distinction between admission plugins (ValidatingAdmissionWebhook, PodSecurity, NodeRestriction) and authorization modes or deprecated flags (AlwaysAllow, InsecureServing) — candidates who do not know the exact plugin names pick the plausible-sounding distractors.

Practice this question →
27
MCQmedium

A security team needs to ensure that Kubernetes nodes have secure file permissions for the kubelet configuration files, in alignment with CIS benchmarks. What should the file permissions on "/etc/kubernetes/kubelet.conf" typically be set to?

A.777
B.755
C.600
D.644
AnswerC

CIS benchmarks require kubelet configuration files to be readable and writable only by their owner, with no group or other access. Mode 600 enforces this, preventing unprivileged users from reading credentials or settings that could be used to compromise the node.

Why this answer

CIS Kubernetes Benchmark control 4.1.1 requires that kubelet configuration files such as /etc/kubernetes/kubelet.conf be owned by root:root and have permissions of 600 or more restrictive. The 600 permission means only the owner (root) can read and write the file, preventing non-privileged users from reading the kubelet's credentials — which include the client certificate and key used to authenticate to the API server. If these files were world-readable, any local user could impersonate the kubelet and potentially escalate privileges within the cluster.

Exam trap

KCSA often tests whether candidates confuse 'readable by root only' (600) with 'readable by all but writable by root' (644) — the trap is picking 644 because it sounds restrictive, when in fact it exposes credential material to any local user.

How to eliminate wrong answers

Option A (777) is wrong because it grants read, write, and execute to owner, group, and others — the most permissive setting possible, allowing any user to modify the kubelet config and inject malicious settings. Option B (755) is wrong because while it restricts write access to the owner, it still allows group and others to read the file, exposing the kubelet's client certificate and key material to any local user. Option D (644) is wrong because it allows all users to read the file (world-readable), which leaks the kubelet's credentials even though write is restricted to root — CIS explicitly requires 600 or stricter.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Compliance And Security Frameworks questions.

Start 20-question session