Back to the course
Test yourself

Kubernetes security & hardening

Final exam · 61 questions · answers explained as you pick
Cluster Setup
11 questions
01The instant you apply a default-deny egress policy, what breaks first?
Incorrect — the API server is not reached over pod egress; it keeps working.
Incorrect — ingress termination is unaffected by pod egress rules.
Correct — pods can no longer reach kube-dns on port 53, so every hostname lookup fails — always allow DNS egress alongside a default-deny.
Incorrect — once a policy selects the pod for Egress, egress flips to deny-all.
02What does kube-bench actually check a node against?
Incorrect — that is image scanning (Trivy); kube-bench checks configuration.
Correct — it scores control-plane flags, file permissions, and kubelet settings against CIS and cites each item.
Incorrect — kube-bench does not evaluate network policy.
Incorrect — signature verification happens at admission, not in kube-bench.
03Why block egress to 169.254.169.254 from workload pods?
Correct — a compromised pod that reaches it can often assume the node’s cloud role and pivot into the account.
Incorrect — CoreDNS has a normal ClusterIP; 169.254.169.254 is the link-local metadata address.
Incorrect — the API server is not on the metadata address.
Incorrect — blocking metadata has nothing to do with DNS performance.
04A NetworkPolicy selects a pod for Ingress only. What happens to that pod’s egress?
Incorrect — a policy only affects the directions it names; egress stays open here.
Correct — naming only Ingress leaves egress untouched (allow-all) until a policy covers it.
Incorrect — only the named direction (Ingress) flips to deny-all.
Incorrect — egress, including DNS, is unaffected by an Ingress-only policy.
05In a NetworkPolicy from-rule, two selectors as separate list items mean…
Correct — separate list items are ORed; combine them under one item for AND.
Incorrect — that is when namespaceSelector and podSelector sit under a single item.
Incorrect — it is valid; it just means OR.
Incorrect — from-rules allow; they do not deny.
06Terminating TLS at an Ingress means the certificate is stored…
Incorrect — the point of edge termination is that backends do not each hold a cert.
Incorrect — TLS material belongs in a Secret, not a ConfigMap.
Correct — the controller presents it and forwards plaintext internally.
Incorrect — it is a Secret object — and should be encrypted at rest.
07To force HTTPS at an ingress-nginx Ingress you set…
Incorrect — network policy does not perform HTTP redirects.
Correct — they 308-upgrade HTTP requests to HTTPS.
Incorrect — a security context is unrelated to redirects.
Incorrect — PSA governs pods, not ingress redirects.
08You verify platform binaries (kubectl, kubelet) before trusting them by…
Correct — catches a corrupted download or a man-in-the-middle swap.
Incorrect — privilege does not verify integrity.
Incorrect — kube-bench audits config, not binary hashes.
Incorrect — a timestamp proves nothing about contents.
09You express "allow all egress except the metadata IP" with…
Incorrect — NetworkPolicy has no explicit deny rule.
Correct — you permit the world and carve out the metadata address.
Incorrect — that selects pods; it does not carve out an IP.
Incorrect — that is unrelated to egress carve-outs.
10A default-deny that breaks nothing is impossible unless you also allow…
Incorrect — pods rarely need the API; DNS is the universal need.
Incorrect — that defeats the deny entirely.
Correct — without DNS every hostname lookup times out.
Incorrect — inbound internet access is not what a default-deny universally needs.
11Your CNI is installed but NetworkPolicies seem to do nothing. Likely cause?
Correct — Calico/Cilium/Weave enforce it; some default/bridge CNIs silently ignore every policy.
Incorrect — policies apply without a reboot.
Incorrect — they work in any namespace.
Incorrect — ingress controllers are unrelated to L3/L4 policy enforcement.
11 questions · explanations appear as you answer
Cluster Hardening
10 questions
01Which API server setting most directly opens the whole cluster if wrong?
Incorrect — profiling is an information-exposure concern, not a full bypass.
Correct — it disables authorization entirely — anyone who reaches the API can do anything. Use Node,RBAC.
Incorrect — this only controls how long audit logs are retained.
Incorrect — log verbosity does not affect access control.
02Which RBAC permission is effectively self-escalation and should be granted almost never?
Incorrect — reading pods is low-risk and routine.
Incorrect — listing services grants no privilege escalation.
Correct — these let a subject grant themselves more than their own role allows — treat them as near-admin.
Incorrect — watching events is read-only and harmless.
03Why disable automountServiceAccountToken on pods that never call the API?
Correct — no reason to hand every container an API credential it never uses — turn automount off and opt in per-pod.
Incorrect — the security benefit, not startup time, is the point.
Incorrect — tokens work fine; the issue is mounting them where unused.
Incorrect — the two settings are unrelated.
04The kubelet API is historically a soft target. Which config hardens it?
Incorrect — that is the weak default — switch it to Webhook.
Correct — require auth, let the API server vet each call, and close the unauthenticated port.
Incorrect — the read-only port (10255) is exactly what you disable.
Incorrect — it already runs as root; that is not the hardening.
05kubectl auth can-i is authoritative because it…
Correct — so "can-i create secrets --as ..." is a fact, not a guess.
Incorrect — it evaluates effective permissions, not just files.
Incorrect — it queries authorization, not past events.
Incorrect — unrelated to RBAC.
06A Role vs a ClusterRole differ in that a Role…
Incorrect — that is a ClusterRole.
Correct — prefer a namespaced Role over a ClusterRole wherever you can.
Incorrect — either can bind users, groups, or service accounts.
Incorrect — both define apiGroups/resources/verbs.
07Modern service-account tokens are safer than the legacy ones because they are…
Incorrect — tokens are not kept in ConfigMaps.
Incorrect — they are mounted when needed; the improvement is their lifetime.
Correct — a leaked one expires and is scoped to the API server.
Incorrect — that is not how projected tokens work.
08NodeRestriction admission limits a compromised kubelet to…
Correct — so one node cannot relabel others or read secrets it was not assigned.
Incorrect — it scopes writes to the node’s own objects, not blanket read-only.
Incorrect — the kubelet still manages its own node.
Incorrect — it is about node/pod objects, not networking.
09Staying on a supported Kubernetes version matters because…
Incorrect — speed is not the security point.
Correct — the API server is the highest-value target — patch on a short clock.
Incorrect — cost is not the driver.
Incorrect — skew is bounded but old servers still respond.
10Auditing RBAC, the first over-grants to hunt are…
Incorrect — those are low risk.
Incorrect — scoped Roles are the goal, not the problem.
Correct — name explicit verbs; the wildcard is how privilege quietly accumulates.
Incorrect — location alone is not the red flag; wildcards and cluster-admin are.
10 questions · explanations appear as you answer
System Hardening
10 questions
01What is the quickest high-value seccomp win for most workloads?
Incorrect — valuable where the threat model demands it, but not the quick, low-risk default.
Correct — it turns the runtime’s curated syscall filter back on with near-zero risk of breaking the app.
Incorrect — that removes protection entirely — the opposite of hardening.
Incorrect — privileged disables protections, it does not add them.
02seccomp filters syscalls. What does AppArmor add that seccomp does not?
Incorrect — that is image scanning; AppArmor is a runtime LSM.
Correct — seccomp cannot limit which files a process touches — AppArmor confines resource access.
Incorrect — AppArmor confines access; it does not encrypt anything.
Incorrect — AppArmor operates on the host, not on API authorization.
03Why load a new AppArmor profile in complain mode before enforce?
Incorrect — the modes are about logging vs blocking, not encryption.
Incorrect — enforce is the goal state; complain is the safe way to reach it.
Correct — exercise the app, read the denials, tighten, then enforce.
Incorrect — performance is not the reason; correctness is.
04Kubernetes runs pods seccomp-unconfined unless you ask, so RuntimeDefault…
Correct — a one-line, high-value default that blocks the risky syscalls.
Incorrect — it applies a curated allowlist, not a total block.
Incorrect — it is independent of the base image.
Incorrect — RuntimeDefault needs no custom file — that is Localhost.
05A custom seccomp profile (Localhost mode) is shipped to nodes under…
Incorrect — profiles are files on the node, not ConfigMaps.
Correct — localhostProfile paths resolve relative to it.
Incorrect — etcd stores objects, not seccomp files.
Incorrect — the profile lives on the node, referenced by the pod.
06You build a seccomp allowlist for an app by…
Incorrect — guessing breaks the app or leaves it loose.
Incorrect — a tight profile denies by default.
Correct — let the log tell you, then flip the default action to errno.
Incorrect — syscall needs differ per app.
07The most common way seccomp ends up disabled on a pod is…
Correct — privileged also restores all caps and exposes host devices.
Incorrect — non-root does not disable seccomp.
Incorrect — probes are unrelated to seccomp.
Incorrect — unrelated to syscall filtering.
08On a RHEL-family host, the mandatory-access-control LSM is…
Incorrect — AppArmor is the Debian/Ubuntu default; RHEL uses the other.
Correct — container_t may only touch container_file_t content.
Incorrect — seccomp filters syscalls; it is not the file-MAC layer.
Incorrect — a firewall, not an LSM.
09Host-level system hardening for a node means, above all…
Incorrect — agents help, but the core idea is reduction.
Incorrect — more services is more surface — the opposite.
Correct — the node is inside the trust boundary; shrink what an intruder finds.
Incorrect — you default-deny and open only what Kubernetes needs.
10When seccomp and AppArmor are not enough (untrusted/multi-tenant code), you reach for…
Correct — a user-space kernel or lightweight VM gives its own kernel boundary.
Incorrect — capacity does not add isolation.
Incorrect — that reduces isolation, not increases it.
Incorrect — unrelated to workload isolation.
10 questions · explanations appear as you answer
Microservice Security
10 questions
01Which securityContext trio is the core of a hardened container?
Incorrect — these are the red flags that turn an escape into a host takeover — the opposite of hardened.
Correct — non-root, no escalation, and a minimal capability set are the high-value baseline.
Incorrect — that grants root and every capability — maximally permissive.
Incorrect — that is unrelated to the container privilege posture and generally best off.
02The Pod Security Standard restricted profile requires, among others…
Incorrect — restricted forbids host namespaces.
Incorrect — restricted bans privilege escalation and privileged mode.
Correct — that is exactly the restricted baseline PSA enforces via namespace labels.
Incorrect — restricted pushes toward read-only roots, not writable ones.
03When would you reach for a sandboxed runtime (gVisor / Kata) via RuntimeClass?
Correct — a user-space kernel or lightweight VM contains a kernel-level escape.
Incorrect — sandboxes cost performance and syscall compatibility — use them where risk justifies it.
Incorrect — a sandbox isolates the kernel, not the network.
Incorrect — sandboxing and signing are unrelated controls.
04Pod Security Admission is configured via…
Incorrect — PSA is built in and label-driven; webhooks are for policy engines.
Correct — three independent modes set per namespace.
Incorrect — the context is what PSA checks, not how PSA is configured.
Incorrect — you do not edit etcd; you label namespaces.
05Before flipping a busy namespace to enforce=restricted you should…
Correct — enforcing outright rejects every non-compliant pod on next deploy.
Incorrect — unnecessary and disruptive.
Incorrect — unrelated and dangerous.
Incorrect — that violates restricted entirely.
06A Kubernetes Secret is protected at rest only when you…
Incorrect — base64 is encoding, not encryption — trivially reversible.
Incorrect — ConfigMaps are also plaintext and less appropriate.
Correct — the API server then encrypts secret data before writing etcd.
Incorrect — network policy does not encrypt storage.
07Turning on encryption at rest does NOT encrypt existing secrets until you…
Incorrect — a restart alone does not rewrite existing objects.
Correct — only future writes are encrypted, so you rewrite in place.
Incorrect — unnecessary; a rewrite suffices.
Incorrect — rotation does not rewrite unencrypted objects.
08Encryption at rest does nothing against…
Correct — keep secrets:get scoped tight — encryption and least-privilege are different controls.
Incorrect — that is exactly what it protects against.
Incorrect — that too is defeated by encryption.
Incorrect — encrypted data on a lost disk is protected.
09mTLS between services (via a mesh, STRICT mode) gives you…
Incorrect — mTLS authenticates and encrypts; authorization is a separate rule.
Correct — so a service knows it is really talking to who it expects.
Incorrect — that is admission-time supply-chain, not mTLS.
Incorrect — unrelated to mTLS.
10The safest way for a pod to consume a Secret is…
Incorrect — env leaks through inspect, crash dumps, and child processes.
Incorrect — that ships the secret in a layer to everyone who can pull.
Correct — a file is read only by code that opens it, and can be made read-only.
Incorrect — annotations are plain, visible metadata.
10 questions · explanations appear as you answer
Supply Chain
10 questions
01Why run Trivy in two passes (exit-code 0 then exit-code 1)?
Incorrect — a single Trivy pass already covers both; the two passes are about severity.
Correct — pass one reports for visibility; pass two gates on what you would actually page for.
Incorrect — caching is configured separately, not by running twice.
Incorrect — the two passes differ by severity and exit code, not retries.
02What does static analysis with Kubesec inspect that image scanning does not?
Incorrect — that is the scanner’s domain, not Kubesec’s.
Incorrect — runtime syscalls are Falco’s domain.
Correct — Kubesec scores how you ask to run the workload; scanning reads the image.
Incorrect — signature checks happen at admission, not in Kubesec.
03A signature-verification admission policy alone is not enough because…
Correct — you must also pin allowed registries and the expected signer identity.
Incorrect — verification overhead is not the gap being described.
Incorrect — keyless signing uses short-lived certs by design — a feature.
Incorrect — admission verification does not depend on a mesh.
04Cosign keyless signing avoids a leaked key by…
Incorrect — there is no long-lived key stored anywhere.
Correct — no durable private key to steal.
Incorrect — that is not how keyless signing works.
Incorrect — signing is independent of registry auth.
05The step that actually ENFORCES the supply chain is…
Incorrect — build produces the artifact; it enforces nothing.
Incorrect — scanning produces evidence, not enforcement.
Correct — unsigned/untrusted images are refused before a pod runs.
Incorrect — signing is evidence; verification is what refuses to run without it.
06A minimal (distroless) base image helps supply-chain security because…
Correct — less surface for both patching and post-exploitation.
Incorrect — signing is a separate step.
Incorrect — it can, via an SBOM; smaller is the benefit.
Incorrect — the nonroot variant does the opposite.
07To stop an attacker signing their own image and passing, pair verification with…
Incorrect — capacity is irrelevant.
Correct — "is it signed" is not the question — "signed by us, from our registry" is.
Incorrect — that removes the gate entirely.
Incorrect — probes do not gate provenance.
08You gate a CI build on manifest risk (privileged, hostPath) by…
Incorrect — Trivy scans the image, not the manifest settings.
Incorrect — Falco is runtime detection, not a CI gate.
Correct — static manifest analysis catches the privileged pod in review.
Incorrect — network policy does not analyze manifests.
09An SBOM lets you scan a scratch/distroless image with no package DB because it…
Correct — syft generates it; grype/trivy scan it.
Incorrect — an SBOM is an inventory, not encryption.
Incorrect — signing is separate from an SBOM.
Incorrect — it is a static bill of materials.
10Provenance is not a one-time gate because…
Incorrect — not the reason — verification re-checks anyway.
Correct — minimal helps, but "few" is not "none".
Incorrect — a digest is immutable — that is the point.
Incorrect — not the reason provenance is ongoing.
10 questions · explanations appear as you answer
Monitoring & Runtime
10 questions
01How does Falco detect a threat like a shell spawned in a container?
Incorrect — that is supply-chain scanning; Falco watches runtime behaviour.
Correct — a shell in a container or a write to /etc fires in real time against a rule.
Incorrect — the audit log is the API server’s view; Falco taps the kernel on the node.
Incorrect — Falco is event-driven on syscalls, not metrics-based.
02You need to change a shipped Falco rule’s output. Where do you do it?
Incorrect — the default rules file is overwritten on upgrade — never edit it in place.
Incorrect — no rebuild is needed to change a rule.
Correct — the local file takes precedence over a shipped rule of the same name and survives upgrades.
Incorrect — deleting loses the detection; overriding locally keeps and adjusts it.
03To avoid logging secret contents while still recording access, an audit rule for secrets should use level…
Incorrect — that captures full bodies — exactly the secret contents you do not want in logs.
Correct — Metadata records who, what, and when without the request/response bodies.
Incorrect — None drops the event entirely, so you would not know secrets were accessed.
Incorrect — Request still logs the body, which for a secret write includes the data.
04The API audit log sees ___, while Falco sees ___.
Correct — the two feeds answer different halves of an investigation.
Incorrect — that reverses them.
Incorrect — neither tool does those.
Incorrect — both are event streams, not metrics/logs generically.
05An audit policy is evaluated…
Incorrect — it is top-down, first match wins.
Correct — so you drop noise first, then set levels for sensitive resources.
Incorrect — evaluation is deterministic and ordered.
Incorrect — it applies to reads and writes per your rules.
06Why key Falco rules to behaviours an attacker cannot cheaply avoid?
Incorrect — the goal is signal quality, not CPU.
Incorrect — Falco is not a scanner.
Correct — noise buries the one alert that matters.
Incorrect — syscalls are not encrypted; that is irrelevant.
07Auditing everything at RequestResponse is a bad idea because it…
Correct — log sensitive verbs in detail, everything else at Metadata or None.
Incorrect — it is supported — just harmful at scale.
Incorrect — the two are independent.
Incorrect — it does not encrypt anything.
08Why ship audit logs and Falco alerts off the node?
Incorrect — disk is a minor benefit; integrity is the point.
Correct — off-box storage preserves the evidence.
Incorrect — it can; shipping off-box is about trust.
Incorrect — unrelated to kubelet performance.
09When Falco fires "shell in container", you pivot to the audit log to learn…
Incorrect — irrelevant to the investigation.
Incorrect — not what correlates the two feeds.
Correct — that turns "something happened" into a concrete account of the intrusion.
Incorrect — unrelated to the audit trail.
10Container immutability makes runtime detection sharper because…
Correct — hardening turns the workload into a tripwire.
Incorrect — it complements Falco, not disables it.
Incorrect — immutability is not encryption.
Incorrect — the audit log stays; immutability sharpens its signal.
10 questions · explanations appear as you answer