KCSA Overview OF Cloud Native Security Practice Test 3 — 15 Questions

Question 1

An attacker gains execution inside a container and attempts to modify the container's root filesystem. The platform team has configured the deployment with `securityContext.readOnlyRootFilesystem: true`. What security mechanism does this enforce?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Filesystem immutability and prevention of unauthorized file modifications. Setting `securityContext.readOnlyRootFilesystem: true` in a Kubernetes pod spec mounts the container's root filesystem as read-only, preventing any process inside the container from writing to or modifying files on the root filesystem. This enforces filesystem immutability, which blocks attackers who gain code execution from persisting malware, modifying binaries, or tampering with configuration files. Any write attempt returns an EROFS (Read-only file system) error, forcing attackers to rely on writable volume mounts if any exist.

Answer

Automatic container image re-signing

Answer

Kernel capability escalation blocking

Answer

Network isolation via NetworkPolicies

Question 2

In a cloud native environment, what is the primary security purpose of using static code analysis (SAST) and software composition analysis (SCA) tools in the CI/CD pipeline?

Accepted Answer

To identify vulnerabilities and insecure coding patterns in the Code layer before deployment. SAST tools analyze source code for insecure coding patterns such as SQL injection or hardcoded secrets, while SCA tools identify vulnerable open-source dependencies and their licenses. Both operate on the Code layer of the CI/CD pipeline, catching issues before deployment, which is far cheaper than remediating in production.

Answer

To provision cloud networking security groups automatically

Answer

To manage worker node operating system updates

Answer

To detect running process anomalies in production pods

Question 3

Under the cloud native shared responsibility model for a managed Kubernetes service, which TWO tasks are typically the responsibility of the cloud provider? (Choose TWO)

Accepted Answer

Provisioning and securing physical data center facilities and hardware. Option C is correct because in the shared responsibility model the cloud provider owns the physical layer — data center facilities, power, cooling, physical security, and the underlying hardware hosts — which customers cannot access or control in a managed Kubernetes service. Option D is correct because with a managed Kubernetes offering (e.g., EKS, AKS, GKE) the provider operates, patches, and maintains the control plane components such as the API server, etcd, scheduler, and controller manager, including their high availability and version upgrades. Option A is not the provider's responsibility because application source code is always authored and maintained by the customer. Option B is not the provider's responsibility because RBAC rules governing who can access the cluster and its resources are configured by the customer. Option E is not the provider's responsibility because NetworkPolicies controlling pod-to-pod traffic within the customer's namespaces are defined and applied by the customer.

Answer

Writing custom application microservice source code

Answer

Configuring Kubernetes Role-Based Access Control (RBAC) rules

Answer

Applying Kubernetes NetworkPolicies between customer pods

Question 4

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 5

Which TWO of the following practices are core principles of cloud native security? (Choose TWO)

Accepted Answer

Defense-in-depth across multiple architectural layers. Option A (Defense-in-depth across multiple architectural layers) is correct because cloud native security assumes no single control is sufficient; it layers protections across identity, network, compute, orchestration, and data so that a failure in one layer (e.g., a misconfigured ingress) is contained by controls in another (e.g., network policies, workload identity, runtime detection). Option E (Principle of least privilege for access and execution permissions) is correct because cloud native environments rely on fine-grained, identity-based authorization such as Kubernetes RBAC, IAM roles, and service accounts, granting only the permissions needed for a task and limiting blast radius if credentials are compromised. The unmarked options do not belong: B is wrong because cloud native security does not rely on a static perimeter firewall, since workloads are dynamic, distributed, and often exposed via APIs and service meshes; C is wrong because immutable, ephemeral infrastructure that is continuously replaced is a core cloud native practice, not static long-lived infrastructure; and D is wrong because sharing administrative credentials violates least privilege, accountability, and non-repudiation, and is replaced by federated identity and short-lived tokens.

Answer

Complete reliance on a static network perimeter firewall

Answer

Static, long-lived infrastructure that is never replaced

Answer

Sharing administrative credentials among all team members

Question 6

An enterprise is conducting a security review of their container build and deployment pipeline. Which TWO security controls should they implement to secure the Container layer? (Choose TWO)

Accepted Answer

Scanning container images for known CVEs before deployment. Option A is correct because scanning container images for known CVEs before deployment (e.g., with Trivy, Clair, or Grype) detects vulnerable OS packages and application dependencies in image layers, preventing exploitable images from reaching the registry or runtime. Option B is correct because enforcing non-root execution and secure container security contexts (via runAsNonRoot, readOnlyRootFilesystem, dropped Linux capabilities, and seccomp/AppArmor profiles) reduces the impact of a container compromise by limiting privileges and blocking privilege-escalation paths. Option C is incorrect because unit tests in Python or Go verify application logic, not container-layer security controls. Option D is incorrect because dedicated physical server racks address physical infrastructure isolation, not the container layer. Option E is incorrect because Terraform scripts provisioning AWS VPCs secure the network layer, not the container layer itself.

Answer

Writing application unit tests in Python or Go

Answer

Procuring dedicated physical server racks from the cloud provider

Answer

Writing Terraform scripts to provision AWS VPCs

Question 7

Which THREE of the following are characteristics of Zero Trust security models in cloud-native environments? (Choose THREE)

Accepted Answer

Explicitly verifying identity and context for every access request. Option B is correct because Zero Trust requires explicit verification of identity and context (user, device, location, workload) for every access request rather than granting access based on network location. Option C is correct because Zero Trust operates on an 'assume breach' mindset, using micro-segmentation to limit lateral movement between workloads and services. Option D is correct because least privilege access is a core Zero Trust principle, granting only the minimum permissions needed for a specific task and enforcing just-in-time and just-enough-access. Option A is incorrect because relying solely on perimeter firewalls reflects a traditional castle-and-moat model, which Zero Trust explicitly rejects in favor of identity-centric controls. Option E is incorrect because implicit trust for internal traffic is the opposite of Zero Trust, which treats all networks as untrusted and verifies every request regardless of origin.

Answer

Relying entirely on network firewalls at the cloud perimeter

Answer

Implicit trust for all traffic originating inside the internal corporate network

Question 8

An organization is hardening their Kubernetes cluster configuration to secure the Cluster layer. Which THREE configurations or practices should they implement? (Choose THREE)

Accepted Answer

Disabling anonymous requests to the Kubernetes API server. Option A is correct because disabling anonymous requests to the Kubernetes API server (via the --anonymous-auth=false flag on kube-apiserver) prevents unauthenticated users from reaching API endpoints, which is a fundamental Cluster-layer hardening control. Option B is correct because strong authentication mechanisms such as OIDC ensure that cluster access is tied to verified identities rather than weak or shared credentials, directly securing the Cluster layer's control plane access. Option C is correct because enabling and configuring Kubernetes audit logging records API requests and actions, providing the visibility needed to detect and investigate suspicious activity against the cluster. Options D and E are not Cluster-layer hardening practices: distroless base images address container image and workload security, while unit tests for JavaScript frontend applications concern application code quality and are unrelated to securing the Kubernetes cluster configuration.

Answer

Using public distroless base images for Dockerfiles

Answer

Writing unit tests for JavaScript frontend applications

Question 9

Which THREE of the following represent security risks or anti-patterns in cloud native application design? (Choose THREE)

Accepted Answer

Exposing the Kubernetes dashboard or debug endpoints publicly without authentication. Option A is correct because exposing the Kubernetes dashboard or debug endpoints (e.g., /debug/pprof, actuator endpoints) to the public internet without authentication gives attackers an unauthenticated administrative or diagnostic interface, enabling cluster takeover or information disclosure. Option D is correct because running container processes as UID 0 (root) violates least privilege; if an attacker escapes or exploits the container, root inside the container eases privilege escalation, host filesystem access via mounted volumes, and bypassing of Pod Security Standards such as restricted policies requiring runAsNonRoot. Option E is correct because Kubernetes ConfigMaps store data as plaintext in etcd and are not designed for secrets; API keys and database passwords placed there are readable by anyone with get/list on ConfigMaps and are exposed in backups and manifests, so Secrets (ideally with encryption at rest and external KMS/vault integration) should be used instead. Option B does not belong because automated vulnerability scanning in CI/CD pipelines is a security best practice that detects known CVEs early, not a risk or anti-pattern. Option C does not belong because immutable infrastructure for cluster worker nodes is a recommended pattern that reduces configuration drift and limits persistent attacker footholds, not a security risk.

Answer

Implementing automated vulnerability scanning in CI/CD pipelines

Answer

Using immutable infrastructure principles for cluster worker nodes

Question 10

When designing a defense-in-depth strategy across the 4Cs, which THREE independent security controls can be applied at different layers? (Choose THREE)

Accepted Answer

Container image signing with Cosign and admission verification for Container. Option B is correct because container image signing with Cosign plus an admission controller that verifies signatures enforces supply-chain integrity at the Container layer, ensuring only trusted, unmodified images are admitted to the cluster. Option C is correct because Kubernetes NetworkPolicies provide Cluster-layer microsegmentation, restricting pod-to-pod traffic to explicitly allowed flows and limiting lateral movement if a workload is compromised. Option E is correct because SAST scanning in the CI/CD pipeline addresses the Code layer, detecting insecure code patterns and vulnerabilities before artifacts are built or deployed. Option A is not a valid independent control since relying solely on a cloud provider's default network security group creates a single point of failure and violates defense-in-depth. Option D is not a security control at all; granting all developers cluster-admin permissions violates least privilege and dramatically expands the attack surface.

Answer

Relying solely on the cloud provider's default network security group for all protection

Answer

Granting all developers cluster-admin permissions for operational speed

Question 11

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 12

An organization is adopting Kubernetes and wants to understand where their responsibility lies under the shared responsibility model. According to the 4Cs of Cloud Native Security, who is primarily responsible for configuring the RBAC rules and network policies within the Kubernetes control plane and worker nodes?

Accepted Answer

The user (cluster administrator). Under the 4Cs of Cloud Native Security, the customer (cluster administrator) is responsible for everything above the Cloud layer—including RBAC role bindings, network policies, admission control, and workload configuration inside the control plane and on worker nodes. The cloud provider secures the physical and virtualized infrastructure, but Kubernetes-level authorization and segmentation are always the user's job.

Answer

The cloud service provider

Answer

The application development team

Answer

The container runtime vendor

Question 13

An auditor is assessing an organization's cloud-native supply chain security posture. Which THREE controls should be in place to ensure artifact integrity and safety across the Code and Container layers? (Choose THREE)

Accepted Answer

Using automated dependency scanners (SCA) to identify vulnerable libraries in source code. Option B is correct because Software Composition Analysis (SCA) tools automatically scan source code and dependency manifests (e.g., package-lock.json, pom.xml) to detect known-vulnerable open-source libraries, directly protecting the Code layer of the supply chain. Option D is correct because cryptographically signing container images (e.g., with Sigstore/Cosign or Notary) and enforcing signature verification via an admission controller (e.g., OPA Gatekeeper, Kyverno) ensures only trusted, untampered images are deployed to the Container layer. Option E is correct because generating and storing Software Bills of Materials (SBOMs, e.g., in SPDX or CycloneDX format) provides a verifiable inventory of components in each build, enabling rapid vulnerability tracing and integrity auditing across both layers. Option A is incorrect because granting root SSH access to all developers on production worker nodes violates least privilege and expands the attack surface rather than ensuring artifact integrity. Option C is incorrect because manually configuring physical server rack layouts is a data-center facilities task unrelated to cloud-native Code and Container supply chain security controls.

Answer

Granting root SSH access to all developers on production worker nodes

Answer

Manually configuring physical server rack layouts in the data center

Question 14

An administrator is auditing a managed Kubernetes service (such as Amazon EKS, Google GKE, or Azure AKS) to verify compliance with cloud native security principles. The administrator attempts to SSH directly into the underlying worker node to inspect system logs. The connection is refused. Why is this restriction expected under the cloud native security model?

Accepted Answer

The cloud provider abstracts and manages the underlying Cloud layer, prohibiting direct node access to maintain infrastructure integrity.. In a managed Kubernetes service the provider owns and operates the control plane and the underlying host/cloud layer, and direct SSH access to worker nodes is deliberately blocked to preserve the provider's infrastructure integrity, patching cadence, and security guarantees. The cloud native security model expects operators to use Kubernetes-native and provider APIs (kubectl, logging/metrics services, node debugging tools) rather than logging into nodes, which enforces the shared responsibility boundary.

Answer

The kubelet has been disabled by the cloud provider for security compliance.

Answer

Container runtime security policies have blocked the SSH daemon process.

Answer

NetworkPolicies applied to the kube-system namespace have dropped incoming port 22 traffic.

Question 15

A security engineer is designing a defense-in-depth strategy for a cloud native application deployment. Which of the following best exemplifies the 'defense-in-depth' principle across the 4Cs layers?

Accepted Answer

Implementing security controls at every layer from Code to Cloud so that a compromise at one layer does not result in total system failure.. Defense-in-depth across the 4Cs means implementing security controls at every layer — Cloud, Cluster, Container, and Code — so that a compromise at one layer does not cascade into total system failure. This layered approach ensures no single point of failure exists in the security posture.

Answer

Granting cluster-admin permissions to all developers to ensure rapid troubleshooting.

Answer

Disabling authentication mechanisms to reduce operational overhead.

Answer

Applying strong firewall rules only at the perimeter of the corporate network.