Knowledge Check - Production Operations
Test your understanding of the key concepts from Module 5. Select the best answer for each question, then submit to see your results. You need to score at least 60% to pass.
A developer deploys TaskBoard to Managed Kubernetes and then opens the Logging Service Grafana, expecting to see the cluster's pod and control-plane logs. The view is empty. What is the correct fix?
Kubernetes control-plane events do NOT flow through the IONOS Logging Service automatically; the platform does not ship cluster logs for you. You must forward them yourself with a Fluent Bit DaemonSet or by enabling Central Logging. Retention values and the JSON-only constraint apply to the HTTP source, not the Kubernetes forward path, and there is no creation-time loggingEnabled flag that solves this.
A developer creates a Monitoring Service pipeline, sees a successful 201 response, then closes the terminal without reading the body. The next day their metrics agent returns 401 on every push to /api/v1/push and they cannot find a way to retrieve the ingest key. What happened?
The Monitoring Service returns the per-pipeline ingest key only once, in metadata.key on creation, and never again for security reasons. If the response body is not captured, the key cannot be recovered and you must provision a fresh pipeline or rotate the key. Prometheus, Grafana Agent, and OpenTelemetry all authenticate with the APIKEY header, so the header format is correct; there is no daily key TTL.
A developer is debugging a connectivity failure between TaskBoard tiers. Application logs are silent, so they need to confirm at the network layer whether traffic is being blocked. They add a Flow Log on the NIC, then realize they set the wrong capture direction. What is the correct way to change it?
Flow Log configuration is immutable after creation, and there is one flow log per resource. To change any setting, including capture direction, you delete the existing flow log and create a new one; there is no in-place update path via PATCH or Terraform, and you cannot attach a second flow log to the same resource.
A developer needs the TaskBoard CI pipeline to authenticate to the IONOS API and wants a leak of that credential to be contained and recoverable fast. Which token approach is correct?
The safe pattern is one token per service per environment (up to 100 per user) with the shortest tolerable TTL from the fixed set, rotated generate-then-revoke so there is never a gap. A shared contract-wide token means a single leak takes down everything, Basic Authentication is being discontinued and should not be used in automation, and the token value is shown exactly once with no read-again endpoint.
A developer exposes TaskBoard on MKS with a Service of type: LoadBalancer. In production they observe that all traffic lands on one worker node, the client source IP is lost, and throughput plateaus around 2 Gbit/s. Which statement correctly explains this and the production fix?
On MKS a type: LoadBalancer Service assigns a reserved public IP as a secondary IP to a single ingress node and kube-proxy NATs to the pod, so source IP is lost (fixed with externalTrafficPolicy: Local) and throughput is capped at that node's 2 Gbit/s ceiling. Production traffic should go through a separately provisioned Managed ALB from the Terraform layer. NSGs do not bind to managed load balancers or MKS nodes, and a PodDisruptionBudget protects availability during rebuilds rather than affecting routing.