Overview OF Cloud Native Security practice questions

The physical security of the data center housing the servers

Why it fails: Physical security is solely the cloud provider's responsibility.

The underlying virtualization hypervisors of the physical data center

Why it fails: Hypervisors are managed by the cloud provider.

The internal etcd cluster database consensus protocol implementation

Why it fails: Etcd and control plane components are managed by the provider in a managed Kubernetes service.

Container

Why it fails: The container layer covers image contents, runtime isolation and container hardening, not the host operating system beneath it. It is tempting because container security is a prominent Kubernetes concern, and it would be correct if the question asked about patching base images or restricting container capabilities rather than the node kernel.

Cloud

Why it fails: The cloud layer covers the AWS infrastructure, IAM, VPC and managed control plane; on EKS the worker node kernel is the node's own operating system, which sits in the node layer. It is tempting because EKS is an AWS service, and it would be correct for patching the managed control plane or cloud account configuration.

Code

Why it fails: The code layer covers application source, dependencies and pipeline integrity, not host operating system maintenance. It is tempting because code security is the innermost of the 4Cs, and it would be correct if the question asked about scanning application dependencies or securing the build pipeline rather than patching node kernels.

Code layer

Why it fails: Immutable node replacement rebuilds the host operating system and kubelet, which sit at the Node layer, not Code. Code covers application source and build artefacts; scanning or signing container images and dependency review belong there, so this option misattributes the layer the practise actually hardens.

Cloud layer

Why it fails: Node instance replacement patches the guest OS and Kubernetes components, which sit at the Node layer, not Cloud. Cloud covers the provider's infrastructure, network and IAM controls; immutable infrastructure applied to VPC, subnet or IAM configuration would correctly target the Cloud layer.

Container layer

Why it fails: Replacing the whole node instance refreshes host OS packages and kubelet binaries, which belong to the Node layer, not Container. The Container layer covers image contents, runtime isolation and admission controls; immutable images or read-only root filesystems would be the Container-layer equivalent.

Cloud layer

Why it fails: Runtime software runs on the node, not in the cloud provider control plane.

Cluster layer

Why it fails: While installed alongside cluster components, the runtime specifically manages containers.

Code layer

Why it fails: Runtimes execute images, not code source files.

The physical data center technician

Why it fails: Technicians do not manage database users.

The container registry administrator

Why it fails: Registries store images, not database schemas.

The cloud provider handles all database user access and encryption keys

Why it fails: Customers manage their own data and users.

Physical security and environmental controls of the cloud provider data center

Why it fails: Data center physical security is managed by the cloud provider.

Managing the underlying physical hypervisors hosting virtual machines

Why it fails: Hypervisors are managed by the cloud provider.

The application development team is responsible for patching the kernel via application code.

Why it fails: Application code cannot patch operating system kernels.

The CNCF security working group releases a kernel patch applied via kubectl.

Why it fails: The CNCF does not manage cloud provider infrastructure or kernel patches.

Kubernetes automatically patches the kernel using rolling update daemonsets.

Why it fails: Kubernetes manages container workloads, not host operating system kernels directly.

The container registry administrator

Why it fails: Container registry administrators manage image storage, access policies and vulnerability scanning for registry contents, not the provider's physical servers or HSMs. Under the shared responsibility model, hardware and HSM compliance belong to the cloud provider. This option is tempting because registries are infrastructure-adjacent, but they remain a tenant-managed service layer.

The application developer

Why it fails: Application developers own application code, dependencies and container images, not the provider's physical servers or HSMs. Under the shared responsibility model, hardware and HSM security and compliance rest with the cloud provider. This option is tempting because developers handle application-layer security, but they have no control over physical infrastructure.

The Kubernetes administrator

Why it fails: Kubernetes administrators manage cluster workloads, namespaces, RBAC and control-plane components, not the provider's physical servers or HSMs. Under the shared responsibility model those physical layers belong to the cloud provider. This option is tempting because administrators handle cluster-level security, but hardware and HSM compliance sit with the provider.

Code layer

Why it fails: Image signing and admission verification harden the supply chain and deployment pipeline, which sits at the cluster layer, not the Code layer. The Code layer covers application source and dependencies; Cosign and Kyverno operate on container artefacts before they run in the cluster.

Cloud layer

Why it fails: Cosign signing and Kyverno admission verification operate on images before workloads run, hardening the Code layer, not the Cloud layer. Cloud covers the underlying infrastructure and provider controls. The option tempts because admission runs inside the cluster, but the artefact being validated is code, not cloud infrastructure.

Cluster layer

Why it fails: Image signing and admission verification protect the provenance of container images, which is the Code layer; the Cluster layer covers control plane, node, and API server hardening. The option tempts because Kyverno runs as a cluster admission controller, but the control's target is the image artefact, not cluster components.

Container base images like Alpine Linux

Why it fails: Container base images sit in the Container layer of the 4Cs, not Code. It is tempting because image contents are code-like, but the Code layer covers application source, dependencies and CI/CD pipeline artefacts, while the Container layer covers image provenance and hardening.

Kubernetes API server authorization policies

Why it fails: API server authorisation policies belong to the Cluster layer of the 4Cs, governing control-plane access. It is tempting because policies are written as code, but the Code layer addresses application source, dependencies and build pipeline integrity, not cluster RBAC configuration.

Cloud provider IAM roles

Why it fails: Cloud provider IAM roles fall under the Cloud layer, covering the underlying infrastructure and its identity controls. It is tempting because IAM policies resemble code, but the Code layer concerns application source, dependencies and CI/CD artefacts, not provider-level access management.

Cloud layer

Why it fails: The cloud layer covers the underlying infrastructure, hypervisor and network controls, none of which introduced the library flaw. It is tempting because cloud misconfiguration is a frequent root cause, and hardening IAM, network policies or node images is correct when the provider's shared infrastructure is the exposure.

Cluster layer

Why it fails: The vulnerability sat in a third-party Python library, which is application code, so the application layer failed; cluster controls such as network policies or admission controllers cannot patch library code. Cluster hardening is the right remediation for infrastructure-level exposure, not for a dependency flaw requiring a source-level fix.

Container layer

Why it fails: The container layer covers image provenance, runtime isolation and admission controls, not the library's own code. A vulnerable dependency executes with the pod's privileges regardless of container hardening, so remediation belongs at the application layer. Container-layer controls would be the right focus for a malicious base image or an escape via misconfigured runtime settings.

Container

Why it fails: Shift-left targets the code and build stages, mapping to the Code and Container layers where scanning occurs in CI pipelines. The Container 4C covers image and runtime hardening, not the earliest development-phase security activity. It tempts because container scanning is a common shift-left example, but the practice itself spans code-level controls first.

Cluster

Why it fails: The Cluster 4C layer concerns control plane, node, and network hardening, which is operational rather than development-time. Shift-left embeds security into source code, dependencies, and CI pipelines before deployment. It tempts because cluster admission policies can enforce security, but that is runtime enforcement, not shifting detection earlier into the build.

Cloud

Why it fails: The Cloud 4C layer covers the underlying infrastructure, IAM, and provider controls, which sit outside the development lifecycle shift-left addresses. Shift-left moves security into code, build, and deployment pipelines, not cloud account configuration. It tempts because cloud misconfigurations are security concerns, but they are remediated through platform governance, not earlier coding.

The Linux kernel maintainers

Why it fails: Linux kernel maintainers have no role in EKS access entries or RBAC; they maintain upstream kernel code. Tempting because Kubernetes runs on Linux, so kernel security underpins container isolation, but cluster authorisation configuration sits with the customer under the shared responsibility model.

The cloud provider only

Why it fails: AWS secures the control plane infrastructure, but IAM access entries and Kubernetes RBAC roles are customer-managed configuration, so the provider alone cannot own them. Tempting because AWS operates the EKS control plane, yet identity mapping and authorisation inside the cluster remain the customer's responsibility.

The CNCF security committee

Why it fails: The CNCF is a vendor-neutral foundation governing Kubernetes project standards, not an operational authority over any tenant's cluster. Tempting because CNCF publishes Kubernetes security guidance, but configuring IAM access entries and RBAC roles for a specific EKS cluster belongs to the customer.

Because Kubernetes natively disables all network traffic by default

Why it fails: Kubernetes applies no default-deny; pods communicate freely unless a NetworkPolicy selects them. The real gap is that perimeter firewalls cannot enforce identity-based, per-pod east-west segmentation. A default-deny NetworkPolicy is the correct control when pod-level isolation is required.

Because cloud providers prohibit the use of firewalls

Why it fails: Cloud providers do not prohibit firewalls; they offer security groups and network policies, so the premise is false. Perimeter firewalls are tempting because they filter north-south traffic, but Kubernetes workloads communicate east-west between pods, which firewalls at the network edge cannot inspect or segment.

Because firewalls cannot run on Linux operating systems

Why it fails: Firewalls do run on Linux, so the premise is false. Perimeter controls inspect north-south traffic at network boundaries; Kubernetes workloads communicate east-west between pods, which a boundary firewall never sees. Firewalls remain valid for protecting cluster ingress and external endpoints.

Cluster layer

Why it fails: AppArmor profiles and non-root users constrain processes inside a container, which is the container layer of the 4Cs, not the cluster layer. Cluster-layer controls cover API server access, RBAC, network policies and node hardening. This option would fit questions about securing cluster-wide orchestration components.

Cloud layer

Why it fails: The cloud layer covers the underlying infrastructure, network and IaaS controls; AppArmor and non-root execution operate within the container itself. Cloud-layer hardening addresses provider networking, IAM and host isolation. These measures would be the answer when the question asks about securing the platform beneath the cluster.

Code layer

Why it fails: The code layer concerns application source, dependencies and build pipeline security; AppArmor and non-root users are runtime container controls. Code-layer measures include scanning images, signing artefacts and reviewing source. This option would be correct if the question asked about securing application code rather than containing a breakout.

Outsourcing all security responsibilities to the cloud provider

Why it fails: The shared responsibility model leaves customers accountable for securing their own workloads, identities, configurations and data, so outsourcing everything leaves those layers undefended. It is tempting because providers do secure the underlying infrastructure, and would be reasonable for that infrastructure layer alone, not the whole stack.

Ensuring every developer has cluster admin access for rapid debugging

Why it fails: Granting every developer cluster admin access removes the layered, least-privilege boundaries that defense-in-depth depends on, collapsing multiple controls into one. It is tempting because broad access speeds debugging, and would suit a disposable sandbox cluster, not a production architecture requiring segmented privilege.

Relying entirely on a strong perimeter firewall to block all malicious actors

Why it fails: A single perimeter firewall provides one control at one boundary; defense-in-depth requires independent, overlapping layers so no single failure exposes the workload. It is tempting because strong perimeter filtering is genuinely valuable, and would be correct as one component within a layered strategy, not as the sole defence.

Detective manual control

Why it fails: Admission control validation blocks non-compliant pods before they run, making it a preventive technical control; a detective manual control only identifies violations after the fact through human review. It is tempting because admission controllers do log rejections, and manual detection would be correct for auditing existing workloads without enforcement.

Corrective physical control

Why it fails: Admission control validation is a preventive technical control, not a corrective physical one; it blocks privileged pods before scheduling rather than physically repairing or reversing an incident. It is tempting because corrective controls restore state after violations, and a physical corrective control would be correct for hardware or facility-level remediation, not Kubernetes admission policy.

Compensating detective control

Why it fails: Admission control validation prevents privileged containers from being admitted, so it is preventive and technical, not a compensating detective control. It is tempting because compensating controls address gaps when primary controls are impractical, and a detective compensating control would be correct where enforcement cannot be automated and monitoring substitutes for it.

Perimeter-based network defense

Why it fails: mTLS authenticates and encrypts service-to-service traffic inside the mesh; it does not create or rely on a network perimeter, which cloud native design explicitly discards. It is tempting because firewalls and DMZs also control traffic, but those operate on network boundaries rather than workload identity.

Shared fate computing

Why it fails: Shared fate computing concerns accepting that cloud provider failures affect you and designing for resilience across trust boundaries; mTLS instead enforces zero trust between workloads. It is tempting because both involve distributed trust assumptions, but shared fate is about provider dependency, not service authentication.

Physical host isolation

Why it fails: Physical host isolation concerns hardware separation of workloads, which mTLS at the application layer neither provides nor depends on. It is tempting because isolation is a security goal, but mTLS addresses identity verification between services, not the physical placement of the hosts running them.

Zero-trust network architecture

Why it fails: Zero-trust network architecture governs identity-based segmentation and least-privilege access between workloads; it does not govern Linux capability assignment inside a pod. It is tempting because zero trust is a headline cloud native principle, and it would be correct where lateral movement between services went unrestricted.

Shared responsibility model

Why it fails: The shared responsibility model allocates duties between provider and customer; it is not a pod-level configuration control. The violation was granting CAP_SYS_ADMIN, which enables privileged operations and container escape. The shared responsibility model would be the correct framing when deciding which security tasks Microsoft Azure or the customer must perform.

Ephemeral infrastructure design

Why it fails: Ephemeral infrastructure design concerns short-lived, immutable, replaceable workloads; it says nothing about which Linux capabilities a container receives. It is tempting because ephemeral containers are a cloud native best practise, and it would be correct where long-running, manually patched pods drift from their declared image.

The cloud provider

Why it fails: The cloud provider secures the managed control plane and underlying infrastructure, not customer application data, keys or secrets. Providers handle physical hosts and API server availability; managing KMS keys and application-level secrets remains the customer's responsibility under the shared responsibility model.

The Linux Foundation

Why it fails: The Linux Foundation is a non-profit governing open-source projects such as Kubernetes; it neither operates the cluster nor holds customer data. It is relevant when discussing project stewardship and certification, but responsibility for application encryption keys and secrets sits with the customer deploying the workload.

The container runtime vendor

Why it fails: The container runtime vendor supplies the CRI implementation, not the cluster's data or key material, so it holds no responsibility for application encryption keys or secrets. Vendors are relevant when selecting runtime software, but the shared responsibility model assigns these application-layer controls to the customer.