These questions cover Kubernetes fundamentals and cloud native concepts — the core of the KCNA and where the exam tests understanding of the "why" behind containers and orchestration, not just terminology.
Question 1
You have a Deployment running a web application. You want external users on the internet to reach it. Which Kubernetes Service type provides an externally accessible IP address?
- A) ClusterIP — provides a stable internal IP within the cluster
- B) NodePort — exposes the service on a port of each cluster node
- C) LoadBalancer — provisions an external load balancer with a public IP
- D) ExternalName — maps the service to an external DNS name
Answer: C — LoadBalancer
A LoadBalancer service instructs the cloud provider (AWS, GCP, Azure) to provision an external load balancer and assign a public IP or DNS name to it. Traffic from the internet hits the load balancer, which forwards it to the cluster nodes and then to the pod.
Kubernetes Service types:
| Type | Accessible from | Use case |
|---|---|---|
| ClusterIP | Within the cluster only | Internal services, DBs |
| NodePort | Node IP + static port (30000–32767) | Dev/test, on-premises clusters |
| LoadBalancer | External internet via cloud LB | Production web-facing services |
| ExternalName | Internal DNS only | Routing to external services by name |
NodePort does expose the application outside the cluster, but it requires knowing a specific node's IP and port — not suitable for user-facing production traffic where node IPs can change.
</details>Question 2
A security team requires that container images deployed to production cannot be modified after being pushed to the registry. Which property of container images supports this requirement?
- A) Container images are stored in encrypted volumes by default
- B) Container images are immutable — their content is fixed to a specific SHA-256 digest at build time
- C) Container images require a digital signature before deployment
- D) Container images are read-only at the filesystem level inside the container
Answer: B — Container images are immutable by content-addressable SHA-256 digest
A container image is a static bundle of layers. When pushed to a registry, the image receives a digest — a SHA-256 hash of its exact content. Pulling an image by digest (not just by tag) guarantees you get the exact bytes that were pushed, with no possibility of modification.
docker pull myapp@sha256:abc123...
Tags are mutable pointers (:latest can be overwritten), but digests are permanent. If the image content changes, the digest changes — there's no way to modify an image and keep the same digest.
This is a cloud native security principle: build once, promote the same immutable image through dev/staging/production. Never rebuild for different environments — use environment variables and config instead.
Image signing (Cosign, Notary) adds cryptographic attestation on top of immutability but is a separate feature from the core immutability property.
</details>Question 3
An operations team notices that adding mutual TLS between every microservice is creating significant certificate management overhead. Which cloud native component handles service-to-service mTLS automatically without changing application code?
- A) A Kubernetes NetworkPolicy applied to each namespace
- B) A service mesh such as Istio or Linkerd with automatic sidecar injection
- C) An Ingress controller configured with TLS termination
- D) Kubernetes Secrets storing TLS certificates mounted into each pod
Answer: B — A service mesh
A service mesh (Istio, Linkerd, Cilium) injects a sidecar proxy (Envoy in Istio's case) into each pod automatically. The sidecar handles mTLS between services transparently — the application thinks it's making a plain HTTP call; the sidecar intercepts, upgrades to mTLS, and authenticates the destination service's identity.
What a service mesh provides:
- mTLS: Automatic certificate issuance and rotation, no app code changes
- Observability: Request traces, error rates, and latency per service pair
- Traffic management: Canary releases, retries, circuit breaking
- Policy: Access control between services
NetworkPolicies control which pods can communicate at the IP/port level but don't handle TLS or authentication. Ingress TLS terminates external traffic at the cluster edge — it doesn't affect internal service-to-service traffic. Kubernetes Secrets mounted as certificates still require application code to use them for mTLS.
</details>Key Takeaways
LoadBalancerservice = cloud provider provisions a public IP;ClusterIP= internal only;NodePort= node IP + static port- Container images are immutable by SHA-256 digest; tags are mutable pointers — pull by digest for guaranteed content
- A service mesh (Istio, Linkerd) provides automatic mTLS, observability, and traffic management via injected sidecars, with no app code changes