* gVisor:
* Google-developed, implemented as auser-space kernelthat intercepts and emulates syscalls made by containers.
* Providesstrong isolationwithout requiring a full VM.
* Official docs: "gVisor is a user-space kernel, written in Go, that implements a substantial portion of the Linux system call interface."
* Source: https://gvisor.dev/docs/
* Firecracker:
* AWS-developed,lightweight virtualization technologybuilt on KVM, used in AWS Lambda and Fargate.
* Optimized for running secure, multi-tenant microVMs (MicroVMs) for containers and FaaS.
* Official docs: "Firecracker is an open-source virtualization technology that is purpose-built for creating and managing secure, multi-tenant container and function-based services."
* Source: https://firecracker-microvm.github.io/
* Key difference:gVisor # syscall interception in userspace kernel (container isolation). Firecracker # lightweight virtualization with microVMs (multi-tenant security).
* Therefore, optionAis correct.
References:
gVisor Docs: https://gvisor.dev/docs/
Firecracker Docs: https://firecracker-microvm.github.io/

* In STRIDE,Tamperingis the threat category forunauthorized modification of data or code/artifacts. A trojanized container image is, by definition, an attacker'smodificationof the build output (the image) after compromising the CI/build system-i.e., tampering with the artifact in the software supply chain.
* Why not the others?
* Spoofingis about identity/authentication (e.g., pretending to be someone/something).
* Repudiationis about denying having performed an action without sufficient audit evidence.
* Denial of Servicetargets availability (exhausting resources or making a service unavailable).The scenario explicitly focuses on analtered imageresulting from a compromised build server-this squarely maps toTampering.
Authoritative references (for verification and deeper reading):
* Kubernetes (official docs)- Supply Chain Security (discusses risks such as compromised CI/CD pipelines leading to modified/poisoned images and emphasizes verifying image integrity/signatures).
* Kubernetes Docs#Security#Supply chain securityandSecuring a cluster(sections on image provenance, signing, and verifying artifacts).
* CNCF TAG Security - Cloud Native Security Whitepaper (v2)- Threat modeling in cloud-native and software supply chain risks; describes attackers modifying build outputs (images/artifacts) via CI
/CD compromise as a form oftamperingand prescribes controls (signing, provenance, policy).
* CNCF TAG Security - Software Supply Chain Security Best Practices- Explicitly covers CI/CD compromise leading tomaliciously modified imagesand recommends SLSA, provenance attestation, and signature verification (policy enforcement via admission controls).
* Microsoft STRIDE (canonical reference)- DefinesTamperingasmodifying data or code, which directly fits a trojanized image produced by a compromised build system.

* Inhigh-availability clusters, multiple API server instances run behind a load balancer.
* Thisdistributes client requests across multiple API servers, preventing a single API server from being overwhelmed.
* Exact extract (Kubernetes Docs - High Availability Clusters):
* "A highly available control plane runs multiple instances of kube-apiserver, typically fronted by a load balancer, so that if one instance fails or is overloaded, others continue serving requests."
* Other options clarified:
* A: Network segmentation does not directly mitigate API server DoS.
* C: Adding resources helps, but doesn't solve single-point-of-failure.
* D: Rate limiting is a valid mitigation but not provided by HA alone.
References:
Kubernetes Docs - Building High-Availability Clusters: https://kubernetes.io/docs/setup/production- environment/tools/kubeadm/high-availability/

* Audit loggingrecords API server requests and responses for security monitoring.
* TheRequestResponse levellogs the full request and response bodies, which can:
* Significantly increasestorage and performance overhead.
* Potentially log sensitive data (including Secrets).
* Therefore, while comprehensive, it introduces risks of performance degradation and excessive log volume.
References:
Kubernetes Documentation - Auditing
CNCF Security Whitepaper - Logging and monitoring: trade-offs between verbosity, storage, and security.

* kube-controller-managerruns a set of controllers that regulate the cluster's state.
* Exact extract (Kubernetes Docs):"The kube-controller-manager runs controllers that are core to Kubernetes. Examples of controllers are: Node controller, Replication controller, Endpoints controller, Namespace controller, and ServiceAccounts controller."
* Why D is correct:All listed are actual controllers within kube-controller-manager.
* Why others are wrong:
* A:Job and CronJob controllers are managed by kube-controller-manager, but DaemonSet controller is managed by the kube-scheduler/deployment logic.
* B:Pod, Service, Ingress controllers are not part of kube-controller-manager.
* C:ConfigMap and Secret do not have dedicated controllers.
References:
Kubernetes Docs - kube-controller-manager: https://kubernetes.io/docs/reference/command-line-tools- reference/kube-controller-manager/