Courseiva

CCNA Overview OF Cloud Native Security Questions

45 questions · Overview OF Cloud Native Security · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQeasy

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?

A.The cloud service provider
B.The application development team
C.The container runtime vendor
D.The user (cluster administrator)
AnswerD

Under the 4Cs, the Cloud provider secures the Cloud layer, but the Cluster layer — including control plane configuration, RBAC rules and network policies — remains the cluster administrator's responsibility, since these are user-configured Kubernetes objects rather than provider-managed infrastructure.

Why this answer

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.

Exam trap

KCSA often tests the shared responsibility boundary, so candidates who equate 'managed Kubernetes' with 'provider secures everything' incorrectly choose the cloud service provider.

How to eliminate wrong answers

Option A is wrong because the cloud service provider is responsible for the Cloud layer (physical hosts, network fabric, hypervisor, and for managed offerings the managed control plane components), not for customer-defined RBAC or NetworkPolicy objects. Option B is wrong because the application development team owns the Code and Container layers—application code, dependencies, and image contents—not cluster-wide authorization and network segmentation. Option C is wrong because the container runtime vendor supplies the runtime software (e.g., containerd, CRI-O) but does not configure a customer's RBAC rules or network policies.

Practice this question →
2
Multi-Selecteasy

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

Select 2 answers
A.Cache
B.Cloud
C.Compiler
D.Cluster
E.Containerd
AnswersB, D

Cloud is one of the two remaining layers of the 4Cs model, which nests Code, Container, Cluster and Cloud. It satisfies the stem's requirement to complete the set alongside Code and Container, since the model's outer layer addresses the underlying cloud provider infrastructure and its shared-responsibility controls.

Why this answer

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.

Exam trap

The trap here is confusing implementation components (like containerd) with the conceptual 4Cs layers, or inventing plausible-sounding but non-existent layers such as Cache or Compiler.

Practice this question →
3
Multi-Selecthard

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

Select 3 answers
A.Disabling anonymous requests to the Kubernetes API server
B.Using strong authentication mechanisms (e.g., OIDC) for cluster access
C.Enabling and configuring Kubernetes audit logging
D.Using public distroless base images for Dockerfiles
E.Writing unit tests for JavaScript frontend applications
AnswersA, B, C

Disabling anonymous requests forces authentication before any API call, closing unauthenticated access to cluster resources. This satisfies the Cluster layer hardening requirement by removing a default exposure that lets anyone query or modify the API server.

Why this answer

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.

Exam trap

The trap is mixing layers — candidates may select distroless images (Container layer) or unit tests (Code layer) because they sound security-related, but the question specifically asks about the Cluster layer.

Practice this question →
4
MCQhard

A security architect is designing a multi-tenant Kubernetes platform. They need to ensure that a compromise in one tenant's namespace cannot allow packet sniffing or unauthorized traffic interception from another tenant's pods. Which Kubernetes feature should they implement to satisfy cloud native network isolation principles?

A.Kubernetes RBAC RoleBindings
B.ResourceQuotas
C.Kubernetes NetworkPolicies
D.PodSecurityStandards
AnswerC

NetworkPolicies enforce pod-level firewall rules, restricting ingress and egress traffic between namespaces so one tenant's pods cannot reach another's. This satisfies the isolation requirement by default-deny policies per namespace. However, they control traffic flow, not packet sniffing on the shared node network, so encryption or separate nodes may still be needed.

Why this answer

Kubernetes NetworkPolicies are the native mechanism for controlling pod-to-pod traffic at L3/L4, allowing the architect to define ingress and egress rules that restrict which pods can communicate. By default, Kubernetes allows all pod-to-pod traffic within a cluster, so a compromised pod in one tenant namespace could sniff or reach pods in another. NetworkPolicies enforce isolation by selecting pods via labels and permitting only explicitly allowed flows, satisfying the cloud-native network isolation principle for multi-tenancy.

Exam trap

KCSA often tests the misconception that RBAC or PodSecurityStandards provide network isolation, when in fact only NetworkPolicies (enforced by a supporting CNI) control pod-to-pod traffic.

How to eliminate wrong answers

Option A is wrong because RBAC RoleBindings control API server authorization (who can perform Kubernetes API actions), not network traffic between pods. Option B is wrong because ResourceQuotas limit namespace resource consumption (CPU, memory, object counts) and have no bearing on packet-level isolation. Option D is wrong because PodSecurityStandards govern pod security contexts (privileged, hostPath, capabilities) and do not restrict network communication between pods.

Practice this question →
5
Multi-Selectmedium

Which TWO of the following practices directly address security concerns within the 'Container' layer of the 4Cs of Cloud Native Security?

Select 2 answers
A.Scanning container images for known Common Vulnerabilities and Exposures (CVEs) prior to deployment.
B.Running containers with a non-root user ID in the Dockerfile.
C.Encrypting data at rest using cloud storage encryption keys.
D.Configuring cloud provider IAM policies for virtual machine instances.
E.Setting up Kubernetes NetworkPolicies between namespaces.
AnswersA, B

Image scanning inspects layers and installed packages for known CVEs before deployment, so vulnerable components are caught while the artefact is still in the registry. This directly addresses the Container layer, since the image itself is the container-layer artefact under scrutiny.

Why this answer

Option A is correct because scanning container images for known CVEs directly hardens the container layer by detecting vulnerable packages and base-image components before the image is deployed. Option B is correct because specifying a non-root user ID in the Dockerfile (via the USER instruction) enforces least privilege inside the container, reducing the impact of a container breakout or compromised process. Option C is not part of the container layer; encrypting data at rest with cloud storage keys belongs to the cloud/infrastructure or data layer.

Option D is also outside the container layer, as IAM policies for VM instances are cloud-provider identity and access controls at the infrastructure layer. Option E addresses pod-to-pod traffic segmentation in Kubernetes, which maps to the cluster layer rather than the container layer itself.

Exam trap

KCSA often tests whether candidates can correctly map controls to the right 'C' layer — image scanning and non-root are Container-layer, while NetworkPolicies and IAM belong to Cluster/Cloud layers.

Practice this question →
6
MCQeasy

Which of the following best describes the principle of 'Defense-in-Depth' in cloud native security architectures?

A.Implementing multiple overlapping security controls across the 4Cs so that a single failure does not lead to compromise
B.Outsourcing all security responsibilities to the cloud provider
C.Ensuring every developer has cluster admin access for rapid debugging
D.Relying entirely on a strong perimeter firewall to block all malicious actors
AnswerA

Defense-in-Depth layers independent controls across all four Cs — cloud, cluster, container and code — so that defeating one control does not grant compromise. Overlapping safeguards ensure no single point of failure exposes the whole system.

Why this answer

Defense-in-Depth means layering multiple independent, overlapping security controls across the 4Cs (Cloud, Cluster, Container, Code) so that the failure of any single control does not result in full compromise. In cloud native terms this includes network policies, RBAC, Pod Security Admission, image scanning, mTLS, runtime detection, and secrets encryption — each compensating for gaps in the others.

Exam trap

The trap here is confusing defense-in-depth with perimeter security or with full delegation to the cloud provider — candidates pick the firewall answer because it sounds 'secure', but cloud native defense-in-depth explicitly rejects the castle-and-moat model.

How to eliminate wrong answers

Option B is wrong because outsourcing all security to the cloud provider contradicts the shared responsibility model — the CSP secures the infrastructure, but the customer remains responsible for workloads, identities, configurations, and data. Option C is wrong because granting every developer cluster-admin access eliminates least privilege and dramatically expands the blast radius of a compromised credential — the opposite of defense-in-depth. Option D is wrong because perimeter-only security assumes a trusted internal network; cloud native environments are flat, dynamic, and often span multiple clusters and clouds, so a single firewall cannot contain lateral movement.

Practice this question →
7
MCQmedium

An administrator is designing a security posture for a microservices application deployed in a Kubernetes cluster. According to the 4Cs of Cloud Native Security, which component falls under the 'Code' layer?

A.Container base images like Alpine Linux
B.Application dependency libraries in package.json
C.Kubernetes API server authorization policies
D.Cloud provider IAM roles
AnswerB

Application dependency libraries declared in package.json sit at the Code layer, since the 4Cs model places source code, its dependencies and build artefacts there. This satisfies the stem's constraint: identifying which component belongs to Code rather than Cluster, Container or Cloud, where runtime orchestration and host controls instead reside.

Why this answer

In the 4Cs of Cloud Native Security (Cloud, Cluster, Container, Code), the 'Code' layer refers to the application code and its dependencies. Application dependency libraries in package.json (B) are part of the code layer because they are directly included in the application's build and runtime. This layer focuses on securing the software supply chain and application logic.

Exam trap

The trap is confusing the layers, especially between Container and Code. Candidates might think base images are part of Code, but they are part of the Container layer. The exam tests precise understanding of the 4Cs model.

How to eliminate wrong answers

Option A (container base images) falls under the 'Container' layer, as it pertains to the container image and its contents. Option C (Kubernetes API server authorization policies) falls under the 'Cluster' layer, as it involves cluster configuration and access control. Option D (cloud provider IAM roles) falls under the 'Cloud' layer, as it relates to the underlying cloud infrastructure and its identity management.

Practice this question →
8
Multi-Selectmedium

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

Select 2 answers
A.Defense-in-depth across multiple architectural layers
B.Complete reliance on a static network perimeter firewall
C.Static, long-lived infrastructure that is never replaced
D.Sharing administrative credentials among all team members
E.Principle of least privilege for access and execution permissions
AnswersA, E

Defence-in-depth layers controls across infrastructure, cluster, container and application, so failure of one control does not expose the whole system. This architectural layering is a core cloud native principle because it assumes any single boundary will eventually be breached.

Why this answer

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.

Exam trap

KCSA often tests the misconception that a strong perimeter firewall or shared admin credentials are acceptable in cloud native environments, when in fact zero-trust and least privilege are the expected core principles.

Practice this question →
9
Multi-Selecthard

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)

Select 3 answers
A.Granting root SSH access to all developers on production worker nodes
B.Using automated dependency scanners (SCA) to identify vulnerable libraries in source code
C.Manually configuring physical server rack layouts in the data center
D.Cryptographically signing container images and verifying signatures at admission time
E.Generating and storing Software Bills of Materials (SBOMs) for application builds
AnswersB, D, E

Software composition analysis inspects declared dependencies and lockfiles, matching them against vulnerability databases to flag known CVEs before the image is built. This addresses the Code layer, catching vulnerable third-party libraries that would otherwise ship inside the container artifact.

Why this answer

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.

Exam trap

KCSA often tests whether candidates recognize that supply chain security requires layered controls (scanning, signing, SBOMs) and reject obviously insecure options like broad root SSH access that masquerade as operational convenience.

Practice this question →
10
Multi-Selectmedium

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

Select 3 answers
A.Security policies should be codified, automated, and enforced throughout the software lifecycle
B.Infrastructure as Code (IaC) templates should be scanned for misconfigurations prior to deployment
C.Developers should have unrestricted administrative access to production clusters for debugging
D.Container workloads should be treated as ephemeral and replaced rather than patched in place
E.Traditional perimeter firewalls are sufficient to secure modern multi-tenant cloud-native clusters
AnswersA, B, D

Codifying security policies as version-controlled code and automating their enforcement across build, deploy and runtime removes manual drift. This satisfies the stem's cloud native principle that controls must be consistent and repeatable throughout the software lifecycle.

Why this answer

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.

Exam trap

KCSA often tests cloud native security principles, and candidates may incorrectly believe that perimeter firewalls are sufficient or that developers need admin access for debugging, which are common misconceptions.

Practice this question →
11
MCQhard

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?

A.The cloud provider abstracts and manages the underlying Cloud layer, prohibiting direct node access to maintain infrastructure integrity.
B.The kubelet has been disabled by the cloud provider for security compliance.
C.Container runtime security policies have blocked the SSH daemon process.
D.NetworkPolicies applied to the kube-system namespace have dropped incoming port 22 traffic.
AnswerA

Managed services place worker nodes within the provider-managed Cloud layer, so direct SSH is blocked to preserve infrastructure integrity and the shared responsibility boundary. The administrator controls workloads, not the host, which explains the refused connection.

Why this answer

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.

Exam trap

The trap is assuming the SSH refusal is caused by a Kubernetes-level control (kubelet, NetworkPolicy, container runtime) when it is actually the cloud provider's infrastructure abstraction and host firewall enforcing the shared responsibility boundary.

How to eliminate wrong answers

Option B is wrong because the kubelet is not disabled on managed worker nodes — it must run for the node to register and for pods to be scheduled; the refusal is at the SSH/network layer, not because kubelet is off. Option C is wrong because container runtime security policies (seccomp, AppArmor, SELinux) constrain processes inside containers, not the host's sshd daemon, which runs outside the container runtime's control. Option D is wrong because NetworkPolicies apply to pod traffic within the cluster's CNI, not to SSH traffic arriving at the node's host network interface; blocking port 22 to a node is a provider-level firewall/security-group decision, not a Kubernetes NetworkPolicy.

Practice this question →
12
MCQeasy

Which of the following is a core tenet of Zero Trust architecture in cloud native environments?

A.Grant cluster-admin privileges to all operations engineers
B.Disable all encryption for internal microservice communication to improve speed
C.Verify explicitly, use least privilege access, and assume breach
D.Trust all traffic originating from inside the corporate virtual private cloud (VPC)
AnswerC

These three principles form the foundational Zero Trust model: verify explicitly using all available signals, apply least privilege access to limit blast radius, and assume breach to minimise damage. Together they satisfy the cloud native requirement for continuous verification rather than perimeter-based trust.

Why this answer

The canonical Zero Trust tenet is 'never trust, always verify,' operationalized as verify explicitly, apply least privilege access, and assume breach. Option C captures all three pillars in one statement, matching NIST SP 800-207 and industry frameworks like Google BeyondCorp. These principles apply equally to users, devices, and workloads in cloud-native environments.

Exam trap

KCSA often tests whether candidates can distinguish the three Zero Trust pillars from adjacent security practices (encryption, RBAC alone, network segmentation alone) that are necessary but not sufficient on their own.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all engineers violates least privilege and dramatically expands the blast radius of a compromised account. Option B is wrong because disabling encryption for internal microservice communication removes a core Zero Trust control (mTLS) and exposes east-west traffic to interception. Option D is wrong because trusting all traffic from inside a VPC is implicit trust — the exact assumption Zero Trust rejects, since attackers who compromise one workload can pivot freely.

Practice this question →
13
MCQeasy

When considering the principle of least privilege within a cloud native architecture, what is the recommended approach for granting permissions to a Kubernetes application running in a Pod?

A.Share a single global ServiceAccount across all namespaces in the cluster.
B.Mount the default ServiceAccount token with cluster-admin rights to ensure compatibility.
C.Disable authentication for the application namespace entirely.
D.Create a dedicated ServiceAccount with strictly scoped RBAC roles granting only required API permissions.
AnswerD

A dedicated ServiceAccount bound to narrowly scoped RBAC roles grants the Pod only the specific API verbs and resources it needs, rather than inheriting broad default permissions. This enforces least privilege at the Kubernetes API authorisation layer.

Why this answer

Least privilege in Kubernetes is achieved by creating a dedicated ServiceAccount per workload and binding it to narrowly scoped Roles or ClusterRoles that grant only the specific API verbs and resources the application needs. This limits the blast radius if the Pod is compromised, since its mounted token can only perform the permitted actions.

Exam trap

KCSA often tests least privilege by offering 'convenience' answers like cluster-admin or a shared ServiceAccount, so candidates optimizing for compatibility rather than security pick the over-privileged option.

How to eliminate wrong answers

Option A is wrong because a single global ServiceAccount shared across namespaces violates least privilege—any compromise grants the same permissions cluster-wide and eliminates per-workload isolation. Option B is wrong because mounting the default ServiceAccount token with cluster-admin rights grants full control of the cluster, the exact opposite of least privilege, and the default token is auto-mounted unless disabled. Option C is wrong because disabling authentication removes the ability to authorize or audit requests, effectively granting anonymous access rather than restricting it.

Practice this question →
14
MCQhard

An enterprise security policy states that all infrastructure must be defined as code (IaC) and scanned for security misconfigurations before deployment. Which part of the cloud native security lifecycle does this control target?

A.Kernel patch management
B.Physical data center security
C.Pre-deployment configuration and policy-as-code validation
D.Runtime security monitoring
AnswerC

Scanning IaC templates for misconfigurations happens before any resource is provisioned, so it maps to pre-deployment configuration and policy-as-code validation. Failures block the pipeline rather than surfacing at runtime, which is precisely what the stated policy demands.

Why this answer

The policy requires infrastructure to be defined as code and scanned for misconfigurations before deployment, which directly targets the pre-deployment phase of the cloud native security lifecycle. This is where configuration and policy-as-code validation occur, ensuring that security issues are caught early in the CI/CD pipeline. Tools like Checkov, tfsec, or OPA/Gatekeeper enforce these checks.

Thus, option C correctly identifies this control.

Exam trap

The trap here is confusing pre-deployment IaC scanning with runtime security monitoring, as both involve security checks but at different lifecycle stages.

How to eliminate wrong answers

Option A is wrong because kernel patch management focuses on maintaining the host OS kernel, not on defining or scanning infrastructure as code. Option B is wrong because physical data center security involves protecting the physical environment, which is unrelated to IaC scanning. Option D is wrong because runtime security monitoring detects threats during execution, whereas the policy targets pre-deployment validation.

Practice this question →
15
MCQeasy

When discussing cloud native security, what does 'ephemeral infrastructure' refer to, and why is it beneficial for security?

A.Network connections that automatically drop after one second
B.Short-lived workloads and nodes that are frequently destroyed and recreated, reducing an attacker's persistence window
C.Virtual machines stored in volatile RAM without disk storage
D.Infrastructure that is permanent and never updated to prevent downtime
AnswerB

Ephemeral infrastructure means nodes and workloads are short-lived, continuously destroyed and recreated rather than patched in place. This shrinks the window in which an attacker can maintain persistence, since compromised instances are routinely replaced, satisfying the stem's security benefit.

Why this answer

Ephemeral infrastructure refers to short-lived workloads and nodes that are frequently destroyed and recreated rather than persisting indefinitely. In cloud native environments, this reduces an attacker's persistence window because any compromise is contained to a brief lifespan, and immutable redeployments wipe out unauthorized changes. This design principle is central to Kubernetes and container security, where pods and nodes are treated as disposable.

Exam trap

The trap here is confusing 'ephemeral' with network or memory characteristics (like short-lived connections or RAM-only VMs) rather than understanding it as a workload lifecycle property that shrinks attacker persistence.

How to eliminate wrong answers

Option A is wrong because it describes a network timeout or connection drop, not infrastructure lifecycle — ephemeral infrastructure is about workload and node lifespan, not packet-level timeouts. Option C is wrong because it describes RAM-only virtual machines (a storage/memory characteristic), not the ephemeral lifecycle concept; ephemeral workloads can still use persistent storage. Option D is wrong because it describes the opposite of ephemeral infrastructure — permanent, never-updated systems increase attack surface and persistence, which is precisely what ephemeral design avoids.

Practice this question →
16
MCQhard

A security analyst reviews an incident where an attacker compromised a container running with the `CAP_SYS_ADMIN` capability and subsequently escaped to the host node. Which cloud native security principle was violated during the initial pod configuration?

A.Zero-trust network architecture
B.Principle of least privilege
C.Shared responsibility model
D.Ephemeral infrastructure design
AnswerB

Granting CAP_SYS_ADMIN to the container gave it excessive privileges, enabling host escape. The principle of least privilege was violated because the pod received far broader capabilities than its workload required, allowing the attacker to escalate to the node.

Why this answer

The principle of least privilege (B) was violated because the container was granted the `CAP_SYS_ADMIN` capability, which is a powerful capability that allows administrative operations. Containers should run with only the minimal capabilities required. Granting such a capability increases the risk of container escape and host compromise.

Exam trap

The trap is selecting a principle that sounds relevant but is not the direct cause. Candidates might choose zero-trust or shared responsibility, but the specific violation is least privilege due to excessive capabilities.

How to eliminate wrong answers

Option A (zero-trust network architecture) is not directly violated; it concerns network segmentation and authentication, not capabilities. Option C (shared responsibility model) is a broader framework, not a specific principle violated by capability assignment. Option D (ephemeral infrastructure design) is about short-lived resources, not about privilege assignment.

Practice this question →
17
MCQhard

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?

A.Filesystem immutability and prevention of unauthorized file modifications
B.Automatic container image re-signing
C.Kernel capability escalation blocking
D.Network isolation via NetworkPolicies
AnswerA

Setting readOnlyRootFilesystem mounts the container's root filesystem read-only, so any write attempt by the attacker fails with a filesystem error. This enforces immutability of the container image layers, blocking persistence or tampering within the running container.

Why this answer

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.

Exam trap

KCSA often tests the confusion between runtime filesystem controls (readOnlyRootFilesystem) and supply-chain controls (image signing) or network controls (NetworkPolicies), causing candidates to pick a mechanism that operates at a completely different layer of the stack.

How to eliminate wrong answers

Option B is wrong because image re-signing is a supply-chain security function handled by tools like Cosign or Notary, not by a runtime securityContext field — readOnlyRootFilesystem has no cryptographic signing capability. Option C is wrong because kernel capability escalation is controlled by `securityContext.capabilities` (e.g., dropping CAP_SYS_ADMIN) and seccomp/AppArmor profiles, not by filesystem mount flags. Option D is wrong because NetworkPolicies are separate Kubernetes resources that control pod-to-pod traffic at L3/L4; they have no relationship to filesystem mount options in a pod's securityContext.

Practice this question →
18
MCQhard

A security engineer is hardening a Kubernetes cluster against container breakout attacks. They configure AppArmor profiles and ensure pods run with a non-root user. Which of the 4Cs layers are these security measures primarily designed to protect?

A.Cluster layer
B.Container layer
C.Cloud layer
D.Code layer
AnswerB

AppArmor profiles and non-root user enforcement operate at the Container layer, satisfying the stem's container breakout constraint. These controls restrict syscalls and privilege escalation within individual containers, directly mitigating breakout attempts. The Cloud, Cluster, and Code layers address different concerns, so Container is the correct 4Cs layer here.

Why this answer

AppArmor profiles and running pods as a non-root user are security measures that apply to the container runtime and the containerized processes. These controls restrict what a container can do, such as limiting system calls or preventing privilege escalation, which are part of the Container layer in the 4Cs model. Therefore, the Container layer is the primary target.

Exam trap

KCSA often tests the 4Cs layers, and candidates may confuse Container layer controls with Cluster layer controls because both involve security configurations, but the key is that Container layer is about the container runtime and its processes.

How to eliminate wrong answers

Option A is wrong because the Cluster layer focuses on securing the Kubernetes control plane, nodes, and cluster-wide policies, not individual container runtime restrictions. Option C is wrong because the Cloud layer pertains to the underlying cloud infrastructure and services, such as network and IAM, not container-level controls. Option D is wrong because the Code layer is about the application code itself, including secure coding and dependencies, not runtime container security.

Practice this question →
19
MCQhard

A security incident response team discovers that a vulnerability in a third-party Python library allowed remote code execution inside a pod. In the context of defense-in-depth and the 4Cs, which layer primarily failed or was unmitigated, requiring remediation at the source?

A.Cloud layer
B.Cluster layer
C.Container layer
D.Code layer
AnswerD

The vulnerable Python library executes within the container's application code, so the flaw originates at the Code layer of the 4Cs. Remediation belongs at source: patching or upgrading the dependency, since node, cluster and cloud layers did not introduce the remote code execution flaw.

Why this answer

A vulnerability in a third-party Python library that enables RCE inside a pod is a Code-layer failure. The Code layer encompasses application code, dependencies, libraries, and the software supply chain. Remediation must occur at the source — patching or replacing the vulnerable library, scanning dependencies, and rebuilding the image — because the flaw originates in the application's code/dependency stack, not in the cluster or container runtime.

Exam trap

KCSA often tests the distinction between the Container layer and the Code layer — candidates see 'inside a pod' and pick Container, but the root cause (third-party library) belongs to the Code layer, and remediation must happen at the source.

How to eliminate wrong answers

Option A is wrong because the Cloud layer covers infrastructure and provider controls, not application dependencies. Option B is wrong because the Cluster layer covers Kubernetes control plane and node components (API server, kubelet, RBAC), not Python libraries inside a pod. Option C is wrong because the Container layer covers the runtime, image integrity, and isolation primitives — while the image may need rebuilding, the root cause is the vulnerable library in the Code layer.

Practice this question →
20
MCQeasy

According to the shared responsibility model for a cloud-managed Kubernetes service, who is responsible for managing application data encryption keys (using KMS) and application-level secrets?

A.The cloud provider
B.The customer
C.The Linux Foundation
D.The container runtime vendor
AnswerB

KMS key management and application-level secrets sit in the customer's data and identity domain, not the provider's managed infrastructure. The provider secures the platform; the customer controls encryption keys and secret material for their workloads.

Why this answer

Under the shared responsibility model for managed Kubernetes (EKS, AKS, GKE), the cloud provider secures the control plane and physical infrastructure, but the customer always owns their data and the keys protecting it. Application data encryption keys managed via KMS and application-level secrets (API keys, DB credentials, tokens) remain the customer's responsibility regardless of service model.

Exam trap

The trap here is assuming 'managed' means 'fully managed' — candidates over-attribute security duties to the cloud provider and forget that data, secrets, and encryption keys always remain the customer's responsibility.

How to eliminate wrong answers

Option A is wrong because the cloud provider manages the control plane, nodes (in managed node pools), and physical security — not customer application data or its encryption keys. Option C is wrong because the Linux Foundation is a standards/governance body (CNCF parent), not a party in the operational shared responsibility model. Option D is wrong because the container runtime vendor supplies the runtime software (containerd, CRI-O) but has no operational responsibility for customer secrets or KMS keys.

Practice this question →
21
MCQmedium

An administrator notices that unauthorized users can view sensitive ConfigMaps across different namespaces because default RoleBindings were overly permissive. Which security principle was violated?

A.Least privilege access
B.Shared responsibility model
C.Immutable infrastructure
D.Supply chain security
AnswerA

Least privilege means each user and service account gets only the permissions its task needs, in the narrowest scope. Bindings that let users read ConfigMaps across namespaces they do not work in break that. Use namespaced Roles and RoleBindings instead of broad ClusterRoleBindings, avoid wildcards, and audit with 'kubectl auth can-i --list --as <user> -n <namespace>'. Sensitive values belong in Secrets, not ConfigMaps.

Why this answer

Overly permissive default RoleBindings that allow unauthorized users to view ConfigMaps across namespaces violate the principle of least privilege. Least privilege requires granting only the minimum permissions necessary for a user or service to perform its function. Default RoleBindings that grant broad read access to ConfigMaps across namespaces exceed that minimum and expose sensitive configuration data.

Exam trap

KCSA often tests the distinction between least privilege and other security principles — candidates may pick 'shared responsibility' because it sounds like a governance issue, but the specific violation of granting more access than needed is least privilege.

How to eliminate wrong answers

Option B is wrong because the shared responsibility model defines which party (cloud provider vs. customer) secures which layer — it does not describe access control violations. Option C is wrong because immutable infrastructure means replacing rather than modifying servers, which is unrelated to RBAC permissions. Option D is wrong because supply chain security concerns the integrity of software artifacts and dependencies, not namespace-level RBAC misconfigurations.

Practice this question →
22
Multi-Selectmedium

Which TWO of the following principles are core tenets of cloud native security?

Select 2 answers
A.Shift-left security, integrating security checks early into the development and CI/CD pipeline.
B.Hardcoding administrative credentials directly into source code for operational simplicity.
C.Implicit trust of internal microservices communicating within the same cluster network.
D.Defense-in-depth, implementing multiple overlapping security controls across the 4Cs.
E.Perimeter-only defense, relying exclusively on an external corporate firewall.
AnswersA, D

Shift-left moves security controls into earlier development phases, embedding scanning, policy checks and testing into CI/CD pipelines. This catches misconfigurations and vulnerabilities before deployment, reducing remediation cost and satisfying cloud native security's emphasis on securing the software supply chain.

Why this answer

Option A is correct because shift-left security is a foundational cloud native principle: security checks (SAST, SCA, container image scanning, IaC validation) are integrated early into development and the CI/CD pipeline so vulnerabilities are caught before deployment rather than after. Option D is correct because defense-in-depth is a core tenet of cloud native security, layering overlapping controls across the 4Cs (Cloud, Cluster, Container, Code) so that no single control failure compromises the workload. Option B is wrong because hardcoding administrative credentials in source code violates secrets management and least-privilege practices, creating a critical vulnerability rather than a security principle.

Option C is wrong because implicit trust between microservices is an anti-pattern; cloud native security requires zero-trust, mutual authentication (e.g., mTLS) and explicit authorization between services. Option E is wrong because perimeter-only defense assumes a hard outer shell with a soft interior, which fails against lateral movement, insider threats, and compromised workloads in dynamic cloud environments.

Exam trap

KCSA often tests whether candidates recognize that implicit trust and perimeter-only defense are outdated models — the exam presents them as plausible options to catch those who haven't internalized zero-trust and defense-in-depth.

Practice this question →
23
Multi-Selecthard

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)

Select 2 answers
A.Scanning container images for known CVEs before deployment
B.Enforcing non-root execution and secure container security contexts
C.Writing application unit tests in Python or Go
D.Procuring dedicated physical server racks from the cloud provider
E.Writing Terraform scripts to provision AWS VPCs
AnswersA, B

Scanning images for known CVEs before deployment removes vulnerable packages from the container layer, satisfying the stem's container-layer control requirement. It catches flaws at build time rather than relying on runtime detection after workloads are already scheduled.

Why this answer

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.

Exam trap

KCSA often tests the distinction between container-layer controls (image scanning, security contexts) and other layers (code, cluster, infrastructure), so candidates may mistakenly choose application testing or infrastructure provisioning as container security measures.

Practice this question →
24
MCQeasy

When evaluating cloud native security principles, why is reliance on a traditional network firewall (perimeter security) considered insufficient for modern Kubernetes environments?

A.Because Kubernetes natively disables all network traffic by default
B.Because cloud providers prohibit the use of firewalls
C.Because container workloads have dynamic IP addresses and high east-west traffic that perimeter firewalls cannot inspect effectively
D.Because firewalls cannot run on Linux operating systems
AnswerC

Pods receive ephemeral IP addresses and communicate heavily east-west between services, traffic that never crosses the perimeter. Firewalls therefore cannot inspect or attribute these flows, making them insufficient for Kubernetes environments where identity-based, workload-level controls are required instead.

Why this answer

Kubernetes pods receive ephemeral IPs from the CNI plugin and are constantly created, destroyed, and rescheduled, so static perimeter firewall rules cannot reliably identify or track workloads. Additionally, most traffic in a cluster is east-west (pod-to-pod, service-to-service), which never crosses the perimeter and therefore is invisible to a traditional firewall. This is why Kubernetes-native controls like NetworkPolicies, service meshes, and zero-trust identity are required.

Exam trap

KCSA often tests the misconception that firewalls are useless or unsupported in cloud/Kubernetes, when the real point is that perimeter firewalls lack visibility into dynamic, east-west container traffic — candidates must distinguish 'insufficient' from 'impossible'.

How to eliminate wrong answers

Option A is wrong because Kubernetes does not disable network traffic by default — in fact, absent NetworkPolicies, all pod-to-pod traffic is allowed (a flat network), which is the opposite of the claim. Option B is wrong because cloud providers fully support firewalls (security groups, NACLs, cloud firewalls); they do not prohibit them. Option D is wrong because firewalls absolutely run on Linux — iptables, nftables, and pfSense are Linux-based, and Kubernetes itself uses iptables/IPVS rules for service routing.

Practice this question →
25
MCQmedium

A security auditor is evaluating a cloud-native deployment. The team states they practice 'shift-left' security. Which of the 4Cs does this practice primarily target?

A.Container
B.Cluster
C.Code
D.Cloud
AnswerC

Shift-left security moves testing, scanning and secure coding earlier into development, so it primarily targets the Code layer of the 4Cs. This addresses vulnerabilities at their origin rather than relying on runtime or host controls later in the pipeline.

Why this answer

'Shift-left' security means moving security practices earlier in the software development lifecycle — into design, coding, and CI/CD — which maps to the 'Code' layer of the 4Cs (Cloud, Cluster, Container, Code). This includes SAST, dependency scanning, secrets detection, and secure coding standards applied before deployment.

Exam trap

KCSA often tests whether candidates map 'shift-left' to the wrong C — the trap is picking Container or Cluster because those feel security-related, when shift-left is fundamentally about code-time practices.

How to eliminate wrong answers

Option A is wrong because the Container layer covers image scanning, minimal base images, and runtime container security — important, but shift-left primarily targets code-time practices. Option B is wrong because the Cluster layer covers Kubernetes RBAC, network policies, and admission controllers — these are deployment/runtime controls, not shift-left. Option D is wrong because the Cloud layer covers IAM, network segmentation, and cloud provider security — infrastructure-level, not code-level shift-left.

Practice this question →
26
MCQhard

An enterprise is deploying a zero-trust architecture across their Kubernetes environments. They mandate that all container images must be signed using Cosign and verified at admission time using Kyverno. This technical control directly hardens which of the 4Cs layers?

A.Code layer
B.Cloud layer
C.Container layer
D.Cluster layer
AnswerC

Cosign signing and Kyverno admission verification operate on the image artefact itself, validating its signature and provenance before it runs. This hardens the Container layer of the 4Cs model, which covers image integrity and supply chain trust.

Why this answer

Cosign image signing combined with Kyverno admission-time verification is a container-layer control because it governs the integrity and provenance of the container image artifact itself before it is admitted to run. The Container layer of the 4Cs (Cloud, Cluster, Container, Code) covers image contents, image provenance, and runtime configuration of the container. Signing and verifying images ensures only trusted, unmodified images execute, which is a direct hardening of that layer.

Exam trap

KCSA often tests the boundary between the Container layer (image artifact integrity) and the Cluster layer (admission control enforcement), causing candidates to pick Cluster because Kyverno is a cluster component — but the control hardens the image artifact, which is Container layer.

How to eliminate wrong answers

Option A is wrong because the Code layer addresses application source code, dependencies, and CI/CD pipeline security (e.g., SAST, SCA, secret scanning), not the signed container artifact verified at admission. Option B is wrong because the Cloud layer covers the underlying cloud provider infrastructure, IAM, network, and API security, not image signing. Option D is wrong because the Cluster layer covers control plane components, RBAC, admission controllers configuration, network policies, and node hardening — Kyverno is the enforcement mechanism, but the artifact being protected (the signed image) belongs to the Container layer.

Practice this question →
27
Multi-Selectmedium

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

Select 3 answers
A.Relying entirely on network firewalls at the cloud perimeter
B.Explicitly verifying identity and context for every access request
C.Assuming breach and implementing micro-segmentation
D.Applying the principle of least privilege access
E.Implicit trust for all traffic originating inside the internal corporate network
AnswersB, C, D

Zero Trust replaces implicit network trust with per-request authentication and authorisation. Every access request must be explicitly verified using identity and contextual signals such as device posture, location and workload identity, satisfying the model's requirement that no request is trusted by default.

Why this answer

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.

Exam trap

KCSA often tests whether candidates recognize that 'internal network = trusted' is the anti-pattern Zero Trust was created to eliminate, so any option implying implicit internal trust is wrong.

Practice this question →
28
MCQhard

A security team implements mutual TLS (mTLS) between all microservices using Istio Service Mesh. Which principle of cloud native security does this implementation primarily exemplify?

A.Zero-trust network segmentation and encryption in transit
B.Perimeter-based network defense
C.Shared fate computing
D.Physical host isolation
AnswerA

mTLS requires every microservice to present and verify certificates, authenticating both ends of each connection. Istio enforces this identity-based verification plus encryption in transit, which is exactly the zero-trust segmentation and encrypted-transit principle the stem asks about.

Why this answer

Implementing mTLS between all microservices with Istio exemplifies zero-trust network segmentation and encryption in transit. Zero-trust assumes no implicit trust based on network location; every service must authenticate and encrypt its traffic. mTLS provides both mutual authentication (both sides present certificates) and encryption, which is the core of zero-trust service-to-service communication.

Exam trap

KCSA often tests the confusion between zero-trust and perimeter security — candidates may pick 'perimeter-based' because mTLS is about network traffic, but the correct principle is zero-trust segmentation and encryption in transit.

How to eliminate wrong answers

Option B is wrong because perimeter-based defense relies on a trusted internal network and a hardened boundary — the opposite of zero-trust, which assumes the network is hostile. Option C is wrong because shared fate computing refers to designing systems where components fail together gracefully (e.g., bulkheads, circuit breakers), not to authentication/encryption. Option D is wrong because physical host isolation is an infrastructure control, not a service-mesh authentication mechanism.

Practice this question →
29
MCQmedium

A security team discovers that a vulnerability in a third-party open-source npm library has been exploited inside a running container in a production Kubernetes cluster. Based on the 4Cs of Cloud Native Security, which layer should be modified first to fix the root cause of this vulnerability?

A.Container layer
B.Code layer
C.Cluster layer
D.Cloud layer
AnswerB

The vulnerable npm library is application source code, so remediation belongs at the Code layer of the 4Cs model. Patching or upgrading the dependency, then rebuilding the image, eliminates the root cause rather than merely containing it. Container, cluster and cloud layers cannot fix a defect originating in third-party application code.

Why this answer

In the 4Cs of Cloud Native Security (Cloud, Cluster, Container, Code), the Code layer refers to the application code and its dependencies. Since the vulnerability is in a third-party npm library used by the application, fixing the root cause requires updating or patching that library in the application code, which is part of the Code layer.

Exam trap

KCSA often tests the 4Cs model, and candidates may confuse the Container layer with the Code layer, thinking that container scanning alone fixes vulnerabilities, but the root cause is in the code dependencies.

How to eliminate wrong answers

Option A is wrong because the Container layer involves the container image and runtime, but the vulnerability originates from the application's dependency, not the container base image. Option C is wrong because the Cluster layer concerns the orchestration and infrastructure, not application dependencies. Option D is wrong because the Cloud layer refers to the underlying cloud infrastructure, which is not where the vulnerability resides.

Practice this question →
30
MCQeasy

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?

A.Granting cluster-admin permissions to all developers to ensure rapid troubleshooting.
B.Disabling authentication mechanisms to reduce operational overhead.
C.Applying strong firewall rules only at the perimeter of the corporate network.
D.Implementing security controls at every layer from Code to Cloud so that a compromise at one layer does not result in total system failure.
AnswerD

Defence-in-depth layers independent controls across Code, Container, Cluster and Cloud, so bypassing one control does not grant full access. This satisfies the stem's requirement for coverage across all 4Cs rather than hardening a single layer.

Why this answer

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.

Exam trap

KCSA often tests whether candidates confuse defense-in-depth with perimeter defense — the exam includes perimeter-only and disabled-authentication options that sound like simplifications but actually eliminate security layers.

How to eliminate wrong answers

Option A is wrong because granting cluster-admin to all developers violates least privilege and creates a massive privilege escalation risk — it is the opposite of defense-in-depth. Option B is wrong because disabling authentication removes the ability to verify identity, which is a foundational security control; it eliminates a layer rather than adding one. Option C is wrong because perimeter-only firewall rules assume the network boundary is sufficient, which fails against insider threats and compromised credentials that originate inside the perimeter.

Practice this question →
31
MCQeasy

Under the cloud native shared responsibility model, who is responsible for ensuring that the underlying physical servers and hardware security modules (HSMs) are secure and compliant?

A.The container registry administrator
B.The application developer
C.The Kubernetes administrator
D.The cloud service provider
AnswerD

Under the cloud native shared responsibility model, the cloud service provider owns security of the cloud: physical servers, hardware, and HSMs in its data centres. This satisfies the requirement, as customers cannot secure hardware they do not control.

Why this answer

Under the cloud native shared responsibility model, the cloud service provider (CSP) owns and operates the physical infrastructure layer — data centers, physical servers, networking hardware, and hardware security modules (HSMs). Customers consume these as abstracted services and cannot patch, inspect, or physically secure them, so the CSP is contractually and technically responsible for their security and compliance (e.g., FIPS 140-2 validated HSMs, SOC 2, ISO 27001 attestations).

Exam trap

KCSA often tests the boundary of the shared responsibility model — candidates incorrectly assume that because they 'own' their workloads they also own the physical layer, when in fact the CSP always retains responsibility for physical servers, hypervisors, and HSMs.

How to eliminate wrong answers

Option A is wrong because a container registry administrator only manages image repositories, access policies, and vulnerability scanning of stored artifacts — they have no visibility or control over physical hardware. Option B is wrong because application developers operate at the code/container layer and cannot influence physical server or HSM security. Option C is wrong because a Kubernetes administrator manages cluster-level resources (RBAC, workloads, namespaces, node pools) but the physical hosts and HSMs sit beneath the abstraction boundary owned by the CSP.

Practice this question →
32
MCQeasy

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?

A.To provision cloud networking security groups automatically
B.To manage worker node operating system updates
C.To identify vulnerabilities and insecure coding patterns in the Code layer before deployment
D.To detect running process anomalies in production pods
AnswerC

SAST inspects source code for insecure patterns, while SCA identifies vulnerable dependencies, both operating on the Code layer. Running them in the CI/CD pipeline catches these flaws before deployment, satisfying the requirement to secure the Code layer early.

Why this answer

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.

Exam trap

KCSA often tests the confusion between static analysis (code layer) and runtime security (production), so candidates may incorrectly select options about monitoring running pods or managing infrastructure.

How to eliminate wrong answers

Option A is wrong because provisioning cloud networking security groups is an infrastructure-as-code or cloud automation task, not the purpose of SAST/SCA. Option B is wrong because managing worker node OS updates is a runtime infrastructure concern, typically handled by the cloud provider or node management tools, not by code analysis. Option D is wrong because detecting running process anomalies in production pods is runtime security (e.g., Falco, eBPF), not static analysis.

Practice this question →
33
MCQmedium

An organization wants to prevent supply chain attacks where compromised base images are pulled from public registries. Which control directly addresses this risk in a cloud native environment?

A.Implementing Kubernetes Horizontal Pod Autoscalers
B.Disabling all outbound internet access from cluster worker nodes
C.Enabling audit logging on the Kubernetes API server
D.Restricting container image pulls to approved, scanned internal registries using admission controllers
AnswerD

Admission controllers validate pod specs at creation, rejecting images whose registry is not on the approved internal list. This enforces the constraint that only scanned, trusted images are pulled, blocking compromised public base images before they reach nodes.

Why this answer

Restricting container image pulls to approved, scanned internal registries using admission controllers directly prevents compromised base images from public registries from being deployed. Admission controllers can enforce policies that reject pods referencing untrusted registries, ensuring only vetted images run in the cluster. This is a targeted supply chain control.

Exam trap

The trap is choosing broad network controls (disabling internet) or logging (audit) instead of the precise admission-controller-based registry restriction that directly addresses image provenance.

How to eliminate wrong answers

Option A is wrong because Horizontal Pod Autoscalers adjust replica counts based on load, not image provenance or registry restrictions. Option B is wrong because disabling outbound internet access is a broad network control that may break legitimate dependencies and does not specifically validate image sources; it also does not prevent pulling from public registries if a proxy or mirror is used. Option C is wrong because audit logging records API activity for forensics and compliance but does not block or prevent compromised image pulls.

Practice this question →
34
MCQmedium

A developer builds a Docker container image using an outdated base image that contains known critical operating system vulnerabilities. Before deploying this image to a production Kubernetes cluster, which security practice should be enforced to detect this issue?

A.Enabling Kubernetes Role-Based Access Control (RBAC).
B.Configuring static container image vulnerability scanning in the CI/CD pipeline.
C.Deploying a network mesh like Istio with mutual TLS.
D.Applying Pod Security Standards at the Restricted level.
AnswerB

Static scanning in the CI/CD pipeline inspects the built image against vulnerability databases before deployment, catching known OS package flaws inherited from the outdated base image. This satisfies the stem's requirement to detect critical vulnerabilities prior to production release.

Why this answer

Configuring static container image vulnerability scanning in the CI/CD pipeline is correct because it inspects the image's OS packages and application dependencies against CVE databases before the image is deployed. This directly detects outdated base images with known critical vulnerabilities, allowing the pipeline to fail the build or block promotion. It is the earliest and most cost-effective control point for this class of issue.

Exam trap

KCSA often tests whether candidates confuse runtime hardening controls (RBAC, PSS, mTLS) with supply-chain controls (image scanning); the trap is picking a runtime control for a build-time vulnerability detection problem.

How to eliminate wrong answers

Option A is wrong because RBAC controls who can perform actions on Kubernetes API resources; it does not inspect image contents for CVEs. Option C is wrong because Istio with mutual TLS secures service-to-service communication (encryption and identity), not the vulnerability status of container images. Option D is wrong because Pod Security Standards Restricted level enforces runtime pod hardening (non-root, no privileged, seccomp), but does not scan for known OS vulnerabilities in the image.

Practice this question →
35
MCQmedium

An organization wants to enforce that no containers run with privileged security contexts across multiple clusters. They implement admission control validation. In the context of cloud native security principles, what type of control is this?

A.Preventative automated policy control
B.Detective manual control
C.Corrective physical control
D.Compensating detective control
AnswerA

Admission control evaluates workloads before they are admitted, rejecting any pod whose securityContext sets privileged: true. Blocking non-compliant configurations prior to execution makes this a preventative automated policy control rather than a detective or reactive one.

Why this answer

Admission control validation in Kubernetes intercepts API requests before an object is persisted, and if the validating webhook rejects the request, the privileged pod is never created. This is a preventative control because it stops the non-compliant configuration from ever reaching the cluster, rather than detecting it after the fact. In cloud native security terms, it is automated (policy-as-code, e.g., OPA Gatekeeper or Kyverno) and preventative by design.

Exam trap

KCSA often tests the conflation of 'admission control' with 'detective' or 'corrective' controls — candidates who equate validation with monitoring pick detective, missing that blocking admission is inherently preventative.

How to eliminate wrong answers

Option B is wrong because a detective control observes and reports after the fact (e.g., audit logs, runtime scanning) and a manual control requires human intervention — admission validation is automated and blocks before persistence. Option C is wrong because 'corrective' implies remediating an existing violation and 'physical' refers to tangible controls like locks or guards, neither of which applies to a software admission webhook. Option D is wrong because 'compensating detective' describes an alternative monitoring control used when a primary control cannot be applied — admission validation is the primary preventative control itself, not a compensating detective one.

Practice this question →
36
Multi-Selecthard

Which THREE of the following components are typically the responsibility of the user (rather than the cloud provider) in a managed Kubernetes service (like EKS, GKE, or AKS) under the shared responsibility model?

Select 3 answers
A.Implementing container image vulnerability management and hardening base images.
B.Manufacturing the physical hardware and server racks in the data center.
C.Configuring Kubernetes RBAC roles and role bindings.
D.Writing secure application code and managing third-party dependencies.
E.Applying security patches to the managed cloud control plane master nodes.
AnswersA, C, D

Managed services patch the control plane and node OS, but image contents are tenant-supplied. Scanning images and hardening base images therefore remain customer duties, since the provider cannot inspect or rebuild artefacts pushed to the cluster's registries.

Why this answer

In a managed Kubernetes service, the cloud provider secures the managed control plane, while the customer remains responsible for what runs on and is configured within the cluster. Option A is correct because container image vulnerability management and base-image hardening are customer duties: you must scan images (e.g., with Trivy or ECR scanning) and build minimal, patched images, since the provider does not control your image supply chain. Option C is correct because Kubernetes RBAC roles and role bindings are cluster-level authorization objects that the user defines and maintains to enforce least privilege; the provider only secures the API server infrastructure, not your authorization policy.

Option D is correct because writing secure application code and managing third-party dependencies (libraries, CVEs, SBOMs) is entirely the customer's responsibility, as the provider has no visibility into or control over your application logic and packages. Option B is not correct because manufacturing physical hardware and server racks is the cloud provider's responsibility, not the user's. Option E is not correct because patching the managed control plane master nodes is handled by the cloud provider in EKS, GKE, and AKS under the shared responsibility model.

Exam trap

KCSA often tests the boundary of the shared responsibility model — candidates incorrectly assume 'managed' means the provider handles RBAC, image scanning, or app security, when in fact those remain customer responsibilities.

Practice this question →
37
MCQmedium

An organization's security team mandates that all Kubernetes worker nodes must be scanned for Common Vulnerabilities and Exposures (CVEs) on a scheduled basis. Under the 4Cs, what layer does node vulnerability scanning address?

A.Container layer
B.Cloud layer
C.Cluster layer
D.Code layer
AnswerC

Node CVE scanning targets the operating system, kernel and runtime packages of the worker nodes themselves, which sit in the Cluster layer of the 4Cs; it does not address application code, container image contents or cloud provider infrastructure.

Why this answer

Under the 4Cs (Cloud, Cluster, Container, Code), the cluster layer encompasses the control plane components, worker nodes, kubelet, container runtime, and node OS. Scanning worker nodes for CVEs addresses vulnerabilities in the node operating system, kernel, and installed packages — squarely a cluster-layer concern. This is distinct from scanning container images (container layer) or application source (code layer).

Exam trap

KCSA often tests whether candidates can correctly map a security activity to the right C of the 4Cs, tempting them to pick 'Container' whenever containers or Kubernetes are mentioned, even when the target is the node OS itself.

How to eliminate wrong answers

Option A is wrong because the container layer covers the container image contents, base image packages, and runtime configuration — not the underlying node OS. Option B is wrong because the cloud layer refers to the cloud provider's infrastructure, IAM, network controls, and managed service configuration, not node-level OS patching. Option D is wrong because the code layer addresses application source code, dependencies, and CI/CD pipeline security, not host-level vulnerabilities.

Practice this question →
38
MCQhard

A healthcare company is designing a new cloud native platform and wants to apply the principle that no single security control should be the sole barrier protecting a critical asset. Their architects propose encrypting data at rest and relying on that encryption as the primary defense against unauthorized database access by a compromised pod. Which design change best reflects the intended principle?

A.Add network policies, workload identity with scoped RBAC, and runtime detection so that encryption is one layer among several independent controls.
B.Move the database to a private subnet and remove its public endpoint, treating network isolation as the replacement for all other controls.
C.Store the encryption keys in the same namespace as the application so that pods can retrieve them quickly and avoid external key management latency.
D.Increase the encryption key length and rotate keys more frequently so that brute-force decryption of the storage volume becomes computationally infeasible.
AnswerA

This correctly implements defense in depth. Encryption at rest protects stored bytes, but a compromised pod using valid credentials can still read decrypted data through the database API. Layering network segmentation, least-privilege identity, and runtime detection creates independent barriers so no single failure exposes the asset.

Why this answer

Defense in depth assumes any single control can fail or be bypassed, so critical assets need multiple independent barriers. Encryption at rest only protects stored bytes; a pod with valid credentials reads decrypted data normally. Adding segmentation, scoped workload identity, and runtime detection ensures a compromise of one mechanism does not directly expose the asset.

Exam trap

The trap here is treating stronger encryption of one layer as equivalent to adding independent layers of defense.

Practice this question →
39
Multi-Selectmedium

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

Select 3 answers
A.Exposing the Kubernetes dashboard or debug endpoints publicly without authentication
B.Implementing automated vulnerability scanning in CI/CD pipelines
C.Using immutable infrastructure principles for cluster worker nodes
D.Running container processes with root user IDs inside the container
E.Storing sensitive API keys and database passwords in plain text within Kubernetes ConfigMaps
AnswersA, D, E

An unauthenticated Kubernetes dashboard or debug endpoint grants direct cluster control, enabling workload creation, secret retrieval and privilege escalation. Exposing these interfaces publicly removes the authentication boundary the API server otherwise enforces, making them a recognised cloud native anti-pattern.

Why this answer

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.

Exam trap

KCSA often tests whether candidates can distinguish security best practices from anti-patterns; the trap is selecting options that sound security-related (like scanning or immutable infrastructure) as risks when they are actually controls.

Practice this question →
40
Multi-Selectmedium

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)

Select 2 answers
A.Writing custom application microservice source code
B.Configuring Kubernetes Role-Based Access Control (RBAC) rules
C.Provisioning and securing physical data center facilities and hardware
D.Managing and patching the managed Kubernetes control plane infrastructure
E.Applying Kubernetes NetworkPolicies between customer pods
AnswersC, D

Physical data centre facilities, power, cooling, hardware and perimeter security remain entirely under the cloud provider's control in every managed Kubernetes offering. Customers cannot access or secure these layers, so the provider owns them regardless of cluster configuration.

Why this answer

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.

Exam trap

KCSA often tests the boundary between control plane and workload responsibilities — candidates incorrectly assume the provider manages RBAC or NetworkPolicies because those are 'Kubernetes' features, when they are actually customer-managed in a shared responsibility model.

Practice this question →
41
Multi-Selecteasy

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

Select 2 answers
A.Container
B.Client
C.Crypto
D.Code
E.Compliance
AnswersA, D

Container is the innermost of the four cumulative layers — Cloud, Cluster, Container, Code — so it is a primary component. Hardening the container layer covers image provenance, runtime isolation and least-privilege SecurityContexts, satisfying the stem's requirement for a named 4Cs component.

Why this answer

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.

Exam trap

KCSA often tests candidates who confuse the 4Cs with generic security domains like compliance or cryptography, rather than the specific Cloud, Cluster, Container, Code layers.

Practice this question →
42
MCQmedium

A DevOps team is building container images using Dockerfiles. They decide to use official minimal distroless base images instead of standard Ubuntu images containing package managers and shell utilities. Which security benefit does this provide?

A.It reduces the container attack surface by removing unused binaries and shells
B.It encrypts the container image layers at rest in the registry
C.It automatically configures cloud IAM roles for the container
D.It guarantees zero vulnerabilities in application code dependencies
AnswerA

Distroless images omit package managers, shells and unused binaries, directly shrinking the exploitable attack surface. With fewer executables present, attackers cannot pivot via shell access or install tooling after compromise, satisfying the stem's requirement to reduce risk compared with Ubuntu images that ship these utilities by default.

Why this answer

Distroless images contain only the application and its runtime dependencies — no package manager, no shell, no standard Linux utilities. Removing these components eliminates entire classes of attack vectors such as shell injection, package-manager abuse, and exploitation of unpatched utilities like bash or curl. This directly reduces the container attack surface, which is exactly what option A states.

Exam trap

The trap is assuming 'distroless' or 'minimal' means 'secure by default' — candidates pick options claiming automatic encryption or zero vulnerabilities, but distroless only reduces the OS-level attack surface, not application code or registry-side concerns.

How to eliminate wrong answers

Option B is wrong because image encryption at rest is a registry/repository feature (e.g., ECR encryption, Artifact Registry CMEK) and has nothing to do with the base image choice — distroless images are not automatically encrypted. Option C is wrong because IAM role configuration is handled by the orchestrator (Kubernetes service accounts, workload identity) or cloud metadata services, not by the base image contents. Option D is wrong because distroless images only reduce OS-level vulnerabilities; application dependencies (npm, pip, Maven packages) still carry their own CVEs and must be scanned separately with tools like Trivy or Grype.

Practice this question →
43
MCQmedium

A security engineer is reviewing the security posture of an enterprise Kubernetes deployment. They note that developers push container images directly to a private registry without vulnerability scanning. Which of the 4Cs is directly impacted by this gap?

A.Code layer
B.Cluster layer
C.Cloud layer
D.Container layer
AnswerD

The container layer covers image contents, so unscanned images pushed to the private registry leave vulnerabilities undetected within the artefacts themselves. This directly satisfies the stem's gap: no scanning occurs before images reach the registry, meaning the container layer's integrity is compromised regardless of cluster or cloud controls.

Why this answer

The Container layer is correct because the gap described — pushing images to a registry without vulnerability scanning — directly concerns the contents and integrity of container images. In the 4Cs model (Cloud, Cluster, Container, Code), the Container layer covers image provenance, image scanning, minimal base images, and runtime hardening. Unscanned images may contain known CVEs in OS packages or libraries, which is precisely a Container-layer concern.

Exam trap

KCSA often tests confusion between the 4Cs layers; candidates mistakenly attribute image scanning to the Code layer (because it involves code dependencies) or the Cluster layer (because it involves admission control), when the image itself is a Container-layer artifact.

How to eliminate wrong answers

Option A is wrong because the Code layer refers to application source code security (SAST, dependency scanning of application libraries, secure coding), not the container image build and registry workflow. Option B is wrong because the Cluster layer covers the control plane and worker node configuration — API server hardening, RBAC, network policies, admission controllers — not image scanning. Option C is wrong because the Cloud layer refers to the underlying IaaS/PaaS infrastructure (VPCs, IAM, hypervisor, managed service configuration), which is separate from image content.

Practice this question →
44
Multi-Selecthard

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

Select 3 answers
A.Relying solely on the cloud provider's default network security group for all protection
B.Container image signing with Cosign and admission verification for Container
C.Kubernetes NetworkPolicies for microservice isolation in the Cluster
D.Granting all developers cluster-admin permissions for operational speed
E.Static Application Security Testing (SAST) scanning in the CI/CD pipeline for Code
AnswersB, C, E

Cosign signing plus admission verification enforces supply-chain integrity at the Container layer, blocking unsigned or tampered images before they run. This gives an independent control at a distinct 4Cs layer, satisfying the stem's defence-in-depth requirement.

Why this answer

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.

Exam trap

The trap is selecting options that sound security-related but actually weaken posture (cluster-admin for all, single default control) — candidates must recognise that defense-in-depth requires independent, layered controls, not convenience shortcuts.

Practice this question →
45
MCQmedium

An organization uses AWS IAM to restrict access to their EKS cluster control plane endpoints. According to the shared responsibility model, configuring and maintaining these access entries and cluster RBAC roles is the responsibility of whom?

A.The Linux kernel maintainers
B.The cloud provider only
C.The CNCF security committee
D.The customer
AnswerD

AWS secures the managed control plane infrastructure, but access entries and Kubernetes RBAC roles governing who may reach that endpoint are customer-configured identity controls. The customer therefore owns this configuration under the shared responsibility model.

Why this answer

Under the AWS shared responsibility model, AWS is responsible for security 'of' the cloud (the infrastructure), while the customer is responsible for security 'in' the cloud. For EKS, the control plane infrastructure is managed by AWS, but configuring IAM access entries and Kubernetes RBAC roles that govern who can access the cluster is a customer responsibility.

Exam trap

KCSA often tests the misconception that the cloud provider manages all aspects of a managed Kubernetes service; candidates must remember that identity and access configurations remain the customer's responsibility under the shared responsibility model.

How to eliminate wrong answers

Option A is wrong because Linux kernel maintainers are not a party in the AWS shared responsibility model; they maintain the upstream kernel, not customer-specific access controls. Option B is wrong because the cloud provider only secures the managed infrastructure, not the customer's identity and access configurations. Option C is wrong because the CNCF security committee is a standards body, not an operational entity responsible for a customer's EKS cluster.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Overview OF Cloud Native Security questions.

Start 20-question session