Cloud Native Architecture

A platform team fixes production bugs by opening an SSH session into running containers and editing files in place. Over time the containers drift apart and nobody can reproduce a given container's exact state. Which cloud native practice removes this drift by treating running instances as disposable?

• AMutable configuration management, where an agent continuously re-applies a desired file state onto each running container.
• BVertical scaling, where each container is granted more CPU and memory so that fewer manual fixes are ever needed.
• CImmutable infrastructure, where a change is shipped as a rebuilt image and the old container is replaced rather than edited.check_circle Correct
• DBlue-green deployment, where traffic is split between two container versions so that live edits can be tested safely.

Why A is wrong: Tempting because configuration-management agents do enforce a target state, but they keep mutating live instances, which is the very source of drift, so instances never become disposable.

Why B is wrong: Tempting because more resources reduce some failures, but adding capacity does nothing about in-place edits or reproducibility and leaves the drift untouched.

Why C is correct: Correct: rebuilding the image and replacing the container means running instances are never modified, so every instance is reproducible from its image and drift cannot accumulate.

Why D is wrong: Tempting because blue-green does swap between versions, but it is a traffic and release strategy that still permits editing running containers and does not make instances immutable.

A team defines that 99.9 percent of API requests should complete in under 300 milliseconds, measured over each rolling 30-day window, and they use this figure internally to decide when to slow feature work and focus on reliability. It is a target they set for themselves, not a contract with customers and with no financial penalty attached. Which observability term describes this figure?

• AA service level objective (SLO), an internal target set against a chosen reliability measurecheck_circle Correct
• BA service level agreement (SLA), the externally committed guarantee that carries consequences if breached
• CA service level indicator (SLI), the raw measured value of the reliability signal itself
• DAn error budget, the amount of unreliability permitted before action is required

Why A is correct: An SLO is precisely an internal reliability target defined over a measurement, used to steer engineering effort, matching the self-imposed 99.9 percent goal with no external contract.

Why B is wrong: An SLA is tempting because it also expresses a reliability figure, but an SLA is a contractual commitment to customers with penalties, whereas the described target is internal and penalty-free.

Why C is wrong: An SLI is tempting because it names the underlying measurement, but the SLI is the measured proportion of fast requests, not the target that proportion is meant to reach.

Why D is wrong: An error budget is a related concept derived from the target, but it is the allowance of failure the target leaves room for, not the target figure being described.

A team already stores metrics in Prometheus but cannot tell why a specific request was slow, because each service reports its own latency in isolation with no link between them. They want to introduce a signal that correlates the work done for one request across every service it touches. Which capability and matching CNCF project should they adopt?

• ACentralised log aggregation, using Fluentd, a CNCF graduated project, to collect and forward log lines from every service.
• BDistributed tracing, using Jaeger, a CNCF graduated project, to correlate the spans of one request across all the services it passes through.check_circle Correct
• CAdditional metrics scraping, using Prometheus, a CNCF graduated project, to record more latency histograms per service.
• DEvent recording, using Argo, a CNCF graduated project, to emit a notification each time a service handles the request.

Why A is wrong: Log aggregation with Fluentd is genuinely useful and Fluentd is correctly named as graduated, but aggregated logs still arrive as per-service records and do not by themselves correlate the work of one request across services.

Why B is correct: Distributed tracing is the signal that links a single request's work across services, and Jaeger is the CNCF graduated tracing backend built for exactly this correlation.

Why C is wrong: More Prometheus histograms tempt because latency is the symptom, but metrics aggregate across requests and cannot isolate why one particular request was slow across the service chain.

Why D is wrong: This pairs a plausible-sounding idea with a real graduated project, but Argo is a workflow and delivery toolset, not a tracing system, and discrete events do not correlate one request end to end.

A background worker consumes messages from a broker queue. When the queue is empty the team wants the worker Deployment scaled to zero Pods, and when messages accumulate they want the replica count to grow in proportion to the queue length rather than to CPU usage. Which tool is designed to drive this event-based autoscaling?

• AA HorizontalPodAutoscaler configured with an average CPU target on the worker.
• BThe VerticalPodAutoscaler, which adjusts the worker's CPU and memory requests as load changes.
• CKEDA, which scales a Deployment based on external event sources such as queue length and can scale it to zero when there are no events.check_circle Correct
• DKnative Serving, which autoscales the worker on incoming HTTP request concurrency.

Why A is wrong: A CPU-based HorizontalPodAutoscaler is the default autoscaler, which makes it tempting, but it reacts to CPU rather than queue length and does not scale to zero, so an empty queue would leave Pods running.

Why B is wrong: It does respond to load, but the VerticalPodAutoscaler changes resource requests on existing Pods rather than the replica count, so it cannot scale out with the queue or scale to zero.

Why C is correct: KEDA reads metrics from external event sources like broker queue depth, scales the workload in proportion to pending events, and supports scaling to zero when the source is idle, matching every requirement.

Why D is wrong: Knative Serving also offers scale to zero, which is tempting, but it is driven by HTTP request concurrency and does not read a broker queue's depth, so it does not fit a message-consuming worker.

A security team wants every service-to-service call inside the cluster to be encrypted in transit and wants each workload to present a verifiable cryptographic identity, without asking application developers to add TLS code to each service. Which service mesh capability directly delivers this?

• ANetwork policies that restrict which Pods may open connections to which other Pods by label selectors.
• BIngress TLS termination, which decrypts external HTTPS at the cluster edge before forwarding requests onward.
• CMutual TLS between sidecar proxies, which encrypts traffic and gives each workload a certificate-based identity managed by the mesh.check_circle Correct
• DSecrets mounted into each Pod holding a shared static key that all services use to encrypt their payloads.

Why A is wrong: Tempting because network policy is a real security control and limits traffic, but it filters connections rather than encrypting them or issuing workload identities, so it does not meet the encryption-in-transit requirement.

Why B is wrong: Tempting because Ingress does handle TLS, but it secures the edge boundary and typically forwards in plaintext internally, so it does not encrypt every internal service-to-service call.

Why C is correct: Correct: a mesh can enable mutual TLS between the sidecars so both ends authenticate via certificates the mesh issues and rotates, encrypting traffic and providing workload identity with no application TLS code.

Why D is wrong: Tempting because Secrets do store sensitive material, but a shared static key gives no per-workload identity and shifts the encryption burden back into application code, which the requirement explicitly rules out.