The thirty-second answer
Start from what a user experiences, not from what the infrastructure reports. Measure request rate, error rate, latency as a distribution, and saturation of every limited resource — utilisation alone hides the queueing that causes most incidents. Logs, metrics and traces serve different purposes: metrics tell you something is wrong and are cheap to keep, traces tell you where in a request path, logs tell you exactly what happened and are expensive at volume. Alert on symptoms users feel rather than on causes, so novel failures still page someone, and make every alert actionable — if the response is to look and do nothing, it should be a dashboard, not a page. Define service level objectives so there is an agreed threshold rather than a judgement call during every incident.
Say this first, then expand into the areas below as the interviewer steers.