A strong answer

• Names something concrete they operated, not just wrote - a home server, a hosted bot, a lab
• Has a failure story with a real diagnosis: disk filled, certificate expired, memory leak, DNS
• Describes what they changed so it would not happen again
• Shows they cared whether it stayed up, not just whether it started

Red flagOnly has coursework where the marker never saw it run for more than an hour.

A strong answer

• Communicates first - acknowledges, sets an expectation for the next update
• Establishes scope and blast radius before diagnosing
• Asks what changed recently - a deploy, a config change, a certificate, a scheduled job
• Considers mitigating (roll back, fail over) separately from fixing

Red flagDives straight into logs in silence and forgets anyone is waiting.

A strong answer

• Can name the process and why they thought it was unnecessary
• Followed it while raising the concern through the right channel
• Either understood the reason afterwards, or successfully changed it
• Shows awareness that in a health context some processes exist because of harm

Red flagProudly describes routing around a control.

A strong answer

• Recognises availability affects patient care, not just revenue
• Talks about change control, auditability and reversibility
• Understands that access to production data is restricted for a reason
• Does not treat safety as opposed to speed - small reversible changes are both

Red flagSees regulation purely as bureaucracy to work around.

A strong answer

• Goes to the source: source code, provider docs, actual error output, a reproducible test
• Builds a small isolated case rather than guessing in the real system
• Writes down the corrected version for the next person
• Knows when to stop and ask someone

Red flagKeeps trying variations of the same command hoping one works.

A strong answer

• Reaches for df to see which filesystem, then du to walk down into it
• Knows logs and container images and old build artefacts are the usual culprits
• Mentions that a deleted file held open by a process still consumes space
• Thinks about a permanent fix - rotation, retention, an alert threshold - not just deleting things

Red flagSuggests only 'make the disk bigger'.

A strong answer

• DNS, load balancer or ingress, service, pod, container, process
• Knows a service is a stable address in front of changing pods
• Can say where TLS is terminated in their picture
• Comfortably says which layers they are less sure about

Red flagUses the words without being able to place them in order.

A strong answer

• Containers share the host kernel; VMs run their own
• Consequences: startup time, image size, isolation strength
• Knows a container image is layers plus a manifest, not a running thing
• Bonus: knows why you cannot run a Windows container on a Linux kernel

Red flagDescribes a container as 'a lightweight VM' and cannot go further.

A strong answer

• Resolver, root, TLD, authoritative - or a coherent approximation
• TTL controls how long an answer is cached, and where
• Connects it to practice: lowering TTL before a cutover, and why changes seem not to take effect
• Knows to check with a direct query rather than trusting the browser

Red flagThinks DNS changes are instant.

A strong answer

• Configuration passed into a process at start
• Knows they leak - process listings, crash dumps, logs, child processes, CI output
• Names a secret manager and the idea of short-lived credentials
• Mentions that rotation matters more than storage location

Red flagHas committed credentials to a repository and does not see the issue.

A strong answer

• Build, test, scan, package, deploy to a lower environment, verify, promote
• Knows the pipeline should fail loudly and block, not warn
• Mentions artefact immutability - build once, promote the same artefact
• Bonus: talks about how you would roll back

Red flagDescribes a pipeline that deploys straight to production on every push and sees no risk.

A strong answer

• Reviewable, versioned, repeatable, and the same in every environment
• Knows drift is the enemy and that a plan or diff is the point
• Mentions review and audit trail - who changed what, when, approved by whom
• Honest that IaC introduces its own problems: state files, blast radius, slow feedback

Red flagSays 'automation is good' with no mechanism behind it.

A strong answer

• A record mapping configuration to real resources
• Knows it must be shared and locked when a team uses it
• Understands it can contain secrets and must be protected
• Knows the same problem turns up in OpenTofu and Pulumi, and that CloudFormation and Bicep keep that record server side instead
• Bonus: knows what happens when something is changed by hand in the console

Red flagHas used Terraform but never thought about where state lives.

A strong answer

• Liveness restarts an unhealthy container; readiness removes it from traffic
• A liveness probe that checks a database will restart healthy pods during a database blip
• A missing readiness probe sends traffic to a pod that is still starting
• Reasons about it even if the exact terms are shaky

Red flagRecites definitions but cannot say what breaks.

A strong answer

• Gives the workload an identity instead of a key - an IAM role on AWS, a service account with workload identity on Google Cloud, a managed identity on Azure
• Recognises it is the same mechanism on all three: an identity attached to the workload, and a policy on the bucket that trusts it
• Least privilege: this bucket, these actions, not a wildcard
• Knows credentials are then short-lived and rotated for them
• Bonus: mentions checking with a policy simulator or by testing that the denial actually happens

Red flagSuggests a long-lived access key or connection string in an environment variable and stops there.

A strong answer

• Treats alert fatigue as a real risk to reliability
• Investigates whether the condition matters at all before changing the threshold
• Either makes it actionable with a runbook, or deletes it
• Wants alerts tied to user-visible symptoms rather than internal metrics

Red flagWould leave it because 'it might catch something one day'.

A strong answer

• Logs are events with detail; metrics are aggregated numbers over time; traces follow one request across services
• Metrics tell you something is wrong, traces tell you where, logs tell you why
• Knows high-cardinality data is expensive in a metrics system
• Has actually used at least one of the three in anger

Red flagOnly knows print statements and does not ask what the others are.

A strong answer

• Confirms scope: all practices or some, all endpoints or one
• Asks what else changed - a scheduled job, a data migration, traffic, an upstream dependency, a certificate
• Looks at the database before the application: connections, slow queries, locks
• Separates mitigation from diagnosis and says which one they are doing
• Communicates to stakeholders on a stated interval

Red flagRestarts everything as a first move and hopes it resolves.

A strong answer

• Follows the process, and knows whether an emergency change path exists
• Gets the second approver rather than skipping the control
• Documents what was done and why while it is still fresh
• Does not treat urgency as permission

Red flagApplies it directly and plans to write the record tomorrow.

A strong answer

• Blameless - the question is how the change got through, not who wrote it
• Asks what would have caught it: review, a migration check, a staging load test, an alert
• Focuses the actions on the system, not on retraining one person
• Would want the graduate in the room, not shielded from it

Red flagWants the person spoken to, and stops there.

A strong answer

• Chooses one thing and can defend it against the alternatives
• Prefers detection or reversibility over prevention if prevention is expensive
• Considers what other teams would have to change to adopt it
• Says how they would know it worked

Red flagLists eight improvements and cannot prioritise.