Sample questions
Cse Container Workload SecurityDifficulty 1
What is the primary security purpose of cryptographically signing a container image before it is pushed to a registry?
- aIt lets consumers verify the image was produced by a trusted publisher and has not been tampered with since signing✓
- bIt compresses the image layers so pulls complete faster across slow network links
- cIt automatically removes any known-vulnerable packages from the final image layers
- dIt replaces the need for a container registry by embedding the image inside the signature file
Explanation:Image signing (e.g. with cosign/Sigstore or Notary) binds a cryptographic signature to the image digest. At deploy time, an admission controller can verify that signature against a trusted key/identity, proving provenance and integrity, but it does not compress images, patch vulnerabilities, or replace the registry.
Cse Container Workload SecurityDifficulty 1
What does an SBOM (Software Bill of Materials) provide for a container image?
- aA record of which Kubernetes nodes the image's pods were scheduled on during the last 30 days
- bThe CPU and memory limits that should be applied to any pod running that image
- cA list of the RBAC roles that were bound to the service account used by the workload
- dA structured inventory of the libraries, packages, and their versions included in the image✓
Explanation:An SBOM enumerates every component (OS packages, language libraries, transitive dependencies) and their versions baked into an image. It is what security teams cross-reference against vulnerability databases to know exactly what is exposed when a new CVE is disclosed; it says nothing about scheduling, resource limits, or RBAC.
Cse Container Workload SecurityDifficulty 1
What is the security role of a Kubernetes admission controller such as OPA Gatekeeper or Kyverno?
- aIt scans running container filesystems every night and deletes any file that matches a malware signature
- bIt intercepts API server requests after auth and can validate or mutate the object before it is persisted, enforcing policy.✓
- cIt replaces kube-proxy to route traffic between pods based on network policy rules
- dIt issues TLS certificates to nodes so kubelet can authenticate to the API server
Explanation:Admission controllers (validating and mutating webhooks) sit in the API request pipeline after authentication and authorization but before the object is written to etcd. Policy engines like OPA Gatekeeper or Kyverno use this hook to enforce rules (e.g. deny privileged: true) or mutate manifests (e.g. inject defaults). They are not runtime file scanners, network routers, or certificate authorities.
Cse Container Workload SecurityDifficulty 1
Kubernetes Pod Security Standards define three policy levels. Which set correctly names them from most permissive to most restrictive?
- aPrivileged, Baseline, Restricted✓
- bBasic, Standard, Premium
- cPublic, Internal, Confidential
- dOpen, Locked, Sealed
Explanation:The Pod Security Standards define exactly three levels: Privileged (unrestricted, for trusted system workloads), Baseline (blocks known privilege escalations while staying broadly compatible), and Restricted (enforces current pod hardening best practices such as dropping all capabilities and requiring non-root).
Cse Container Workload SecurityDifficulty 2
A runtime container security tool like Falco primarily works by doing what?
- aStatically parsing the Dockerfile before the image is built to flag insecure base images
- bObserving kernel-level syscalls and container events at runtime and matching them against rules to flag anomalous behavior.✓
- cDiffing successive image tags in the registry to detect unexpected layer changes
- dSigning the running container's process list and pushing it as an attestation to a transparency log
Explanation:Falco (and similar runtime security tools) taps into kernel syscalls (via eBPF or a kernel module) and Kubernetes audit events, evaluating them in real time against detection rules -- e.g. alerting when a shell is spawned in a container that never does so, or when a sensitive file is read. This is runtime behavioral detection, not static Dockerfile analysis, registry diffing, or attestation signing.
Cse Container Workload SecurityDifficulty 1
Why is storing a sensitive value in a plain Kubernetes Secret object, without any additional controls, not sufficient confidentiality protection on its own?
- aSecrets can only be consumed by pods running on the same node where the Secret was created
- bKubernetes Secrets are stored using a one-way hash, so the original value can never be retrieved even by the cluster administrator
- cSecrets are automatically synced to every namespace in the cluster, so restricting access is impossible
- dThe Secret's value is only base64-encoded by default, which is trivially reversible by anyone who can read the Secret object.✓
Explanation:By default, Kubernetes Secret data is base64-encoded, not encrypted -- encoding provides no confidentiality. Anyone with RBAC read access to the Secret object, or direct access to unencrypted etcd, can decode it instantly. This is why encryption at rest and RBAC restrictions (or an external secret store) are needed in addition to the Secret abstraction.