测验：可观测性与运营

정상 99%에서도 PlatformProvisionFailing이 firing입니다. 식이 ratio < bool 0.95입니다. 가장 직접적인 원인은?

• for가 경과하면 모든 비율이 오류로 바뀐다
• bool 비교가 값 0인 계열을 남겨 알림이 활성화된다
• critical 라벨이 PromQL 비교 결과를 1로 바꾼다
• 기록 규칙은 알림에서 비교 연산을 지원하지 않는다

1분 평가에서 첫 실패 계열이 t=1분에 나타나고 for=10m 동안 계속 유지됩니다. 기대하는 최초 발화는?

• t=1분: 최초 실패와 동시에 발화
• t=10분: 시작 시각부터 열 번째 평가
• t=11분: 활성 시작부터 10분이 지난 평가
• t=25분: 입력 데이터가 끝난 다음 평가

성공 계열 없이 실패 카운터만 증가합니다. 과제의 성공률과 알림은 어떻게 되어야 하나요?

• 비율이 비어 있어 알림도 비활성이다
• 0으로 나누었으므로 성공률 100%다
• 결과 계열이 하나이므로 성공률 50%다
• 성공률 0%이며 지속 조건 뒤 발화한다

인스턴스 A는 1000건 중 990건 성공, B는 10건 중 0건 성공했습니다. 합산 성공률은?

• 990 / 1010, 약 98.02%
• 두 성공률 평균, 49.5%
• 990 / 1000, 정확히 99%
• 성공 서버 비율, 정확히 50%

파일과 PrometheusRule의 그룹 이름이 같지만 API의 expr가 vector(1)입니다. 올바른 판정은?

• 그룹 이름이 같으므로 동일 규칙이다
• 검증한 groups 전체와 달라 배포 증거로 인정할 수 없다
• API가 수락했으므로 경고 메시지만 남긴다
• 알림 규칙 수가 같으면 기록 규칙은 달라도 된다

Deployment에 원하는 replicas가 있지만 Pod는 없고 ReplicaSet에 quota 초과 FailedCreate 이벤트가 있습니다. 어디부터 조사하나요?

• nodeSelector를 제거해 기존 Pod를 재배치한다
• 이미지 다운로드가 끝나도록 kubelet을 재시작한다
• 생성 거절의 쿼터 사용량과 요청 리소스를 확인한다
• 아직 없는 Pod의 Running 상태가 될 때까지 기다린다

무트래픽 또는 시계열 관측이 없는 구간을 과제에서 처리하는 올바른 방법은?

• 둘 다 성공률 100%로 채워 대시보드를 안정시킨다
• 관측 없음만 성공 100%로 채우고 요청 없음은 0%다
• 둘 다 실패 0%로 채워 발급 실패 호출을 유지한다
• 성공률 계열을 만들지 않고 계측 이상은 별도로 조사한다

GPU 풀 선택자를 지우자 KWOK 파드가 Running이 됐습니다. 이 실습의 복구 완료로 인정할 수 있나요?

• 아니요. 과제의 선택자를 유지해 복구하고 실제 GPU 실행과 구별해야 한다
• 예. Running이면 GPU 장치 접근도 확인된 것이다
• 예. 선택자는 언제나 권고라 지워도 의미가 없다
• 아니요. 어떤 상황에서도 워크로드 요구 변경은 금지된다