퀴즈: 저장·발화·전달의 경계

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. PrometheusRule 생성은 성공했지만 /api/v1/rules에 그룹이 없습니다. 먼저 확인할 조합은?

   1. 규칙 네임스페이스 선택과 규칙 라벨 선택
   2. Alertmanager 수신자의 재전송 주기만
   3. 웹훅 수신 서버의 요청 본문 크기만
   4. 알림 메시지의 표시 언어와 글자 수

2. ServiceMonitor의 endpoints.port에 넣어야 하는 값은 무엇인가요?

   1. 컨테이너 포트의 정수 값을 문자열로 변환한 값
   2. 선택한 Service에 선언된 포트의 이름
   3. Pod 이름 뒤에 컨테이너 포트를 붙인 값
   4. Service의 ClusterIP에 프로토콜을 붙인 값

3. 메트릭 target은 up인데 발급 요청은 503입니다. 가장 정확한 해석은?

   1. up이면 업무 실패는 클라이언트 측 문제다
   2. 503이므로 exporter 프로세스는 반드시 종료됐다
   3. 수집 경로와 업무 의존성 상태는 서로 다르다
   4. up이므로 규칙 선택과 통지 전달도 완료됐다

4. Prometheus는 firing인데 Alertmanager API에는 알림이 없습니다. 어느 경계를 조사하나요?

   1. 사용자에게 보이는 알림 제목과 번역
   2. 이미 통과한 규칙의 YAML 들여쓰기만
   3. 수신 웹훅의 send_resolved 옵션만
   4. Prometheus의 Alertmanager 연결·발견·접근

5. Alertmanager가 알림을 받았지만 기본 sink receiver에는 전송 대상이 없습니다. 결과는?

   1. 수신해도 실제 웹훅 통지는 없을 수 있다
   2. 기본 웹훅으로 자동 전송된 것으로 본다
   3. Prometheus의 규칙이 자동으로 삭제된다
   4. 수신한 알림은 즉시 업무 성공으로 바뀐다

6. 웹훅 그룹에 옛 파드의 resolved와 새 파드의 firing이 함께 왔습니다. 무엇을 해야 하나요?

   1. resolved가 하나 있으니 새 파드도 복구로 판정
   2. 개별 알림 상태와 현재 대상 라벨을 대조
   3. 그룹이 도착했으니 모든 파드를 정상으로 판정
   4. 알림 이름만 같으면 시간과 파드를 생략

7. 구성 변경 직후 조회가 비어 있고 컨트롤러는 계속 실행 중입니다. 올바른 다음 행동은?

   1. 조회가 비었으니 즉시 환경 전체를 다시 설치
   2. 임의의 정상 JSON을 저장해 검사를 먼저 통과
   3. 설정과 반영 로그를 확인하며 같은 환경을 재관측
   4. for 값을 0으로 만들면 모든 전달 문제가 해결

8. 관측 API 호출 실패 뒤 빈 객체를 diagnose에 넣었습니다. 합당한 반환은?

   1. inactive — 경보가 없으니 정상 상태
   2. recovered — 관측할 장애가 사라진 상태
   3. notified — 전송한 뒤 비워진 것으로 추정
   4. unknown — 필요한 관측 근거가 없는 상태