Course Test

Question 1

Which incident triage phase must always have a human make the final call, even when the agent has produced a severity assessment?

Select one answer

Detect

Assess Severity

Diagnose

Stabilize

Question 2

Why should every write operation in an agent runbook be preceded by an approval point?

Select one answer

To give the agent time to re-read the runbook before executing

Because Kubernetes rejects writes that are not preceded by a human confirmation flag

Because write operations change production state and a wrong action can worsen the incident

To satisfy audit logging requirements imposed by Meshery Operator

Question 3

Which mesheryctl command records a corrected configuration in Meshery for audit trail purposes after a fix is applied?

Select one answer

mesheryctl system check

mesheryctl perf apply

mesheryctl design import -f designs/microservices-demo.yaml -s "Kubernetes Manifest"

mesheryctl system start

Question 4

What is the purpose of a stop condition in an agent runbook?

Select one answer

To pause the runbook until a Prometheus alert clears

To terminate runbook execution when the environment is outside the runbook's designed scope

To restart the agent process if it consumes too much memory

To notify MeshSync that the runbook has completed

Question 5

In the incident walkthrough, what did the on-call engineer independently verify before typing APPROVE?

Select one answer

That the payments service had no open circuit breakers in the service mesh

That the target rollback image tag existed and was healthy in the registry

That Meshery Operator was running and had synced the latest design

That all three pods had been evicted before issuing the rollback command

Question 6

Which of the following correctly describes how postmortem findings should be converted into durable guardrails?

Select all that apply

Update runbooks to fix gaps exposed during the incident - missing stop conditions, late approval points

Import and extend policy guardrail designs to encode constraints that prevent recurrence

Delete all runbooks involved in the incident and rewrite them from scratch

Add missing observability signals so the same failure class is detected sooner next time