Container Orchestration

A platform team hosts three HTTP microservices and wants a single external entry point that routes requests to each service by URL path, such as forwarding /orders and /users to different backends, while terminating TLS in one place. Which Kubernetes object is designed to provide this layer-7 path-based routing?

• AOne LoadBalancer Service per microservice, each provisioning its own cloud load balancer for the individual backend.
• BAn Ingress with an associated Ingress controller, which routes external HTTP traffic to Services based on host and URL path rules.check_circle Correct
• CA NodePort Service fronting all three microservices through one shared node port number opened on every cluster node.
• DA headless ClusterIP Service that returns the Pod addresses of all three microservices to callers.

Why A is wrong: LoadBalancer Services can expose each app, but they operate at layer 4 and cannot route by URL path, and using one per service defeats the single-entry-point goal.

Why B is correct: Ingress defines host and path routing rules for HTTP traffic and, with a controller, gives one entry point that fans out by path and can terminate TLS centrally.

Why C is wrong: NodePort is tempting as an external entry, but it forwards a raw port to a single Service and has no awareness of HTTP paths, so it cannot split /orders from /users.

Why D is wrong: A headless Service returns Pod IPs for direct discovery, but it stays internal and performs no path-based HTTP routing or TLS termination.

A platform engineer must let a data analyst list and get Pods in a single namespace called analytics, and confer no access anywhere else in the cluster. Which combination of objects grants exactly this with least privilege?

• AA ClusterRole granting get and list on pods, plus a ClusterRoleBinding that binds the analyst to that ClusterRole.
• BA Role granting get and list on pods, plus a ClusterRoleBinding that references that Role.
• CA RoleBinding in the analytics namespace that references the built-in view ClusterRole, granting the analyst read access across all namespaces.
• DA Role granting get and list on pods, plus a RoleBinding in the analytics namespace that binds the analyst to that Role.check_circle Correct

Why A is wrong: This is tempting because it does grant pod read access, but a ClusterRoleBinding applies the permission across every namespace, breaking the least-privilege boundary the requirement sets.

Why B is wrong: It looks like it scopes access via the Role, but a ClusterRoleBinding can only reference a ClusterRole, not a Role, so the API server rejects this binding and no access is granted.

Why C is wrong: Reusing the built-in view ClusterRole is attractive, but a RoleBinding only grants within its own namespace, so the described cross-namespace effect is impossible and the wording is self-contradictory.

Why D is correct: A Role is namespaced, so its rules apply only within analytics, and a RoleBinding in that namespace grants them to the analyst there and nowhere else, exactly matching the requirement.

A developer applies a PersistentVolumeClaim, but it stays in the Pending phase and the Pod that mounts it will not start. The cluster has no administrator-created PersistentVolumes that match the claim, and the claim names no storage class. The team wants Kubernetes to create a matching volume automatically whenever such a claim is made. Which object should they define and reference in the claim to enable this automatic provisioning?

• AA larger PersistentVolumeClaim requesting more capacity
• BA ConfigMap holding the storage backend connection settings
• CA StorageClass that names a provisioner for dynamic provisioningcheck_circle Correct
• DA second static PersistentVolume created by hand each time

Why A is wrong: Resizing the request seems like a fix because capacity mismatches can block binding, but no volume exists to bind to at all, so a different size still leaves the claim Pending.

Why B is wrong: A ConfigMap is plausible because storage does need backend configuration, but ConfigMaps hold application settings and play no part in provisioning or binding PersistentVolumes.

Why C is correct: A StorageClass names the provisioner Kubernetes uses to create a PersistentVolume on demand, so referencing one in the claim lets a matching volume be provisioned automatically and the claim to bind.

Why D is wrong: Manually creating a PersistentVolume would let this one claim bind, but it is static provisioning that repeats the manual work rather than the automatic provisioning the team asked for.

A Pod's container starts, runs briefly, then exits, and its restart count keeps climbing while kubectl reports the container state as CrashLoopBackOff. Which statement best describes what this status indicates?

• AThe kubelet cannot download the container image from the registry, so the container has never actually started running.
• BThe container repeatedly starts and then exits soon after, so the kubelet waits a growing back-off interval before each restart attempt.check_circle Correct
• CThe scheduler cannot find a node with enough free resources, so the Pod remains unscheduled and never binds to a node.
• DThe container exceeded its configured memory limit and was terminated once by the node, with no further restart attempts made.

Why A is wrong: This is tempting because it is also a repeating back-off state, but a registry pull failure produces ImagePullBackOff, not CrashLoopBackOff, and here the container has already run.

Why B is correct: CrashLoopBackOff means the container keeps terminating shortly after start and the kubelet applies an increasing delay between restarts, which is exactly this behaviour.

Why C is wrong: This describes a Pod stuck in Pending, which is a scheduling problem; a CrashLoopBackOff Pod has already been scheduled and its container has executed.

Why D is wrong: A single memory kill shows the reason OOMKilled and does not by itself imply the repeated start-exit cycle that defines a CrashLoopBackOff.

A platform team must run untrusted tenant workloads on a shared cluster and needs each workload isolated by a hardware-virtualisation boundary, so that a kernel exploit inside one container cannot reach the host kernel, while the workloads still schedule as ordinary Pods. Which container runtime approach meets this requirement?

• AgVisor, which runs the workloads behind its runsc user-space kernel
• BThe default runc runtime hardened with a restrictive seccomp profile
• CKata Containers, which runs each Pod inside a lightweight virtual machinecheck_circle Correct
• DRootless containers, which map the container root user to an unprivileged host user

Why A is wrong: gVisor is tempting because it also targets untrusted workloads and reduces host kernel exposure, but it intercepts system calls in a user-space kernel rather than placing each workload behind a hardware-virtualisation boundary, so it does not match the stated requirement.

Why B is wrong: A seccomp profile narrows the system calls a container may make, which looks like stronger isolation, but the container still runs directly on the shared host kernel with no virtualisation boundary, so a kernel exploit could still reach the host.

Why C is correct: Kata Containers runs each Pod inside a lightweight virtual machine with its own guest kernel, so the hardware-virtualisation boundary keeps a compromised container's kernel exploit away from the host kernel while the workloads still schedule as normal Pods.

Why D is wrong: Rootless containers reduce the damage of a breakout by mapping container root to an unprivileged host user, but they still share the host kernel and provide no hardware-virtualisation boundary, so they do not satisfy the requirement.