Select Two (Multi-Select) Questions

runAsNonRoot: true

Correct. Containers must run as non-root.

seccompProfile.type: RuntimeDefault

Correct. The restricted profile requires seccomp to be set to RuntimeDefault or Localhost.

capabilities must drop ALL

Correct. The restricted profile requires all capabilities to be dropped, except NET_BIND_SERVICE can be added.

An HPA resource targeting the Deployment

The HPA defines the scaling policy.

metrics-server installed in the cluster

Provides CPU metrics.

CPU resource requests set on the container

HPA uses requests to calculate utilization.

min

Correct. `min` specifies the minimum amount of resources a container can request or consume.

defaultRequest

Correct. `defaultRequest` sets the default resource request for a container when not specified in the pod spec.

maxLimitRequestRatio

Incorrect. `maxLimitRequestRatio` is a valid LimitRange field, but it enforces a ratio between limit and request, not a direct resource constraint. It is not one of the three fields that directly enforce resource constraints at the container level as asked.

strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 2

Absolute numbers match constraints.

strategy: rollingUpdate: maxSurge: 16% maxUnavailable: 33%

16% of 6 is ~1 (ceil=1), 33% of 6 is ~2 (ceil=2), so same constraints.

NodePort

A NodePort service exposes a specific static port (30000–32767) on every cluster node’s IP address, forwarding inbound traffic from that port to the target pods. This mechanism satisfies the stem’s constraint of enabling external access from outside the cluster because any external client can reach the service by targeting `<NodeIP>:<NodePort>`, bypassing the cluster-internal network boundary.

LoadBalancer

LoadBalancer integrates with cloud providers for external access.

Overlays are used to customize resources for different environments.

Overlays apply environment-specific patches.

Overlays can patch resources defined in a base.

Overlays can modify resources from a base.

To store the name of the CI/CD tool that deployed the resource

Annotations can hold deployment tool metadata.

To record the build version or commit hash for auditing

Common use case for annotations.

To attach arbitrary non-identifying metadata to an object

Annotations are designed for arbitrary metadata.

Service Mesh (e.g., Istio VirtualService)

Service Mesh provides fine-grained traffic splitting.

Ingress with canary annotation

Ingress controllers like NGINX support canary.

kubectl create secret generic mysecret --from-file=key=file.txt

The generic subcommand with --from-file=key=file.txt explicitly assigns the file's contents to a chosen key inside the Secret's data map. This is the canonical way to create a Secret that holds a single arbitrary file, and kubectl automatically base64-encodes the value when the Secret is created, though the command line uses the raw file content. It is the recommended approach when you need to mount the file as a volume in a Pod.

kubectl create secret generic mysecret --from-env-file=file.txt

Correct: `kubectl create secret generic mysecret --from-env-file=file.txt` creates a Secret from an environment file, where each line in the file represents a key-value pair. This is a valid way to create a Secret from a file.

kubernetes.io/ssh-auth

Correct. `kubernetes.io/ssh-auth` is a built-in Secret type for SSH credentials.

kubernetes.io/tls

The `kubernetes.io/tls` Secret type stores a TLS certificate and its associated private key, encoded as `tls.crt` and `tls.key` data fields respectively, which the kubelet automatically uses to secure pod-to-pod or ingress traffic. This satisfies the stem’s requirement for a valid, built-in Secret type that Kubernetes recognises for TLS termination, distinct from opaque or generic Secrets.

Opaque

Incorrect for this question. Although `Opaque` is a valid Secret type, the question expects the specific types `kubernetes.io/ssh-auth` and `kubernetes.io/tls` as the two answers.

kubectl apply -f service.yaml

Applying a YAML manifest creates the Service.

kubectl expose deployment my-deploy --port=80

Expose creates a Service from a deployment.

Mounting the ConfigMap as a volume

Correct. Mounting a ConfigMap as a volume makes its data available as files.

Using configMapKeyRef in env.valueFrom

Correct. Using `configMapKeyRef` in `env.valueFrom` injects a specific key as an environment variable.

Using envFrom with configMapRef

Correct: Using envFrom with configMapRef is a valid way to inject all keys from a ConfigMap as environment variables.

Replace

The `Replace` policy is a valid concurrencyPolicy value, but it is not one of the two selected as correct in this question. It terminates the currently running job and starts a new one when the next scheduled time arrives.

Allow

The `Allow` policy is the default `concurrencyPolicy` and permits a new job to be created even if a previously scheduled job is still running. This means multiple job Pods from the same CronJob can overlap, which is useful for workloads that are safe to run concurrently. However, you must ensure your application can handle parallel instances.

Forbid

The `Forbid` policy ensures that if the job from the previous schedule is still active, the CronJob controller skips the new scheduled run. This prevents overlapping executions and is ideal for batch jobs that must process sequentially. Note that the missed run is not queued or retried later; it is simply dropped until the next schedule.

Forbid

Forbid is correct because it is one of the three valid concurrency policies, which prevents concurrent runs by skipping new runs if a previous one is still active.

Allow

Allow is correct because it is one of the three valid concurrency policies, and it is the default, allowing multiple CronJob instances to run concurrently.

Create two Deployments for blue and green, and update the Service selector to point to the new version

Classic blue-green with Service selector.

Use an Ingress resource to route traffic to different Services, each backing a different version

Blue-green can be implemented with Ingress.

Use 'pod-security.kubernetes.io/audit=restricted' to log violations without enforcement.

Setting the audit label logs violations without enforcement, which helps assess the impact before enforcing. It is a recommended step but not strictly required for enforcement. However, in this scenario, it is considered a required step for implementation.

Create a ServiceAccount for exempted pods and label it with 'pod-security.kubernetes.io/enforce=privileged'.

Creating a ServiceAccount and labeling it with 'pod-security.kubernetes.io/enforce=privileged' exempts pods that use that ServiceAccount from the restricted policy, allowing them to run privileged containers. This is required for exemption.

Set the namespace label 'pod-security.kubernetes.io/enforce=restricted' on the 'secure' namespace.

Setting the namespace label 'pod-security.kubernetes.io/enforce=restricted' is the primary step to enforce the restricted policy on the 'secure' namespace.

kubectl apply can update existing resources; kubectl create cannot.

Correct. `kubectl apply` can update existing resources; `kubectl create` cannot update and will fail if the resource exists.

kubectl apply stores the last applied configuration in an annotation.

It uses the annotation 'kubectl.kubernetes.io/last-applied-configuration'.

kubectl create configmap app-config --from-file=app.properties

--from-file uses the filename as the key and the file content as the value.

kubectl create configmap app-config --from-env-file=app.properties

--from-env-file parses the file as environment variables (KEY=VALUE lines).

kubectl create service clusterip my-svc --tcp=80:80

Valid: `kubectl create service clusterip` creates a Service directly.

kubectl apply -f service.yaml

Valid: `kubectl apply -f service.yaml` creates a Service if the YAML defines a Service.

kubectl expose deployment my-deploy --port=80

Valid: `kubectl expose deployment` creates a Service that exposes the deployment.

NodePort

Valid type.

ClusterIP

Valid type.