[
  {
    "courseSlug": "ops-basics",
    "question": "장애의 3대 신호 중 사용자에게 '서버 오류' 페이지가 보이는 500 에러가 떴을 때, 코스가 꼽은 흔한 범인 후보는 무엇인가?",
    "option1": "DB 느린 쿼리나 트래픽 폭주",
    "option2": "도메인이나 인증서 설정 문제",
    "option3": "백엔드 예외(코드 버그)나 DB 연결 끊김",
    "option4": "서버 다운이나 컨테이너 죽음",
    "answerIndex": 2,
    "explanation": "500 에러는 요청은 도착했는데 처리 중 예외가 터진 상태로, 범인은 대부분 백엔드 코드나 DB 연결이다. DB 느린 쿼리는 '느림', 서버 다운이나 도메인·인증서 문제는 '접속 불가'의 범인 후보다."
  },
  {
    "courseSlug": "ops-basics",
    "question": "코스에서 배운 '원인 좁히기'는 정전 때 동네 전체 → 두꺼비집 → 방 스위치 → 전구 순서로 확인하듯 바깥에서 안쪽으로 진행한다. 올바른 확인 순서는?",
    "option1": "DB → 앱 로그 → 컨테이너 → 서버",
    "option2": "서버 → 컨테이너 → 앱 로그 → DB",
    "option3": "컨테이너 → 서버 → DB → 앱 로그",
    "option4": "앱 로그 → DB → 서버 → 컨테이너",
    "answerIndex": 1,
    "explanation": "섹션 3의 핵심은 큰 범위에서 작은 범위로 좁히는 것이다. 서버 생존(ping·SSH) → 컨테이너(docker ps) → 앱 로그(docker logs) → DB 순서로 확인해야 헛수고가 없다."
  },
  {
    "courseSlug": "ops-basics",
    "question": "docker ps를 쳤더니 어떤 컨테이너의 STATUS가 'Exited (137)'로 나왔다. 코스 설명에 따르면 137 코드가 자주 의미하는 것은?",
    "option1": "정상적으로 가동을 마치고 종료됐다는 뜻",
    "option2": "죽었다 살아나기를 반복하는 중이라는 뜻",
    "option3": "디스크 용량 부족으로 기록이 멈췄다는 뜻",
    "option4": "메모리 부족(OOM)으로 강제 종료됐다는 뜻",
    "answerIndex": 3,
    "explanation": "코스의 docker ps STATUS 읽는 법에서 Exited (137)은 메모리 부족(OOM)으로 강제 종료됐을 때 자주 보이는 코드라고 설명한다. 죽었다 살아나기를 반복하는 상태는 'Restarting'으로 표시된다."
  },
  {
    "courseSlug": "ops-basics",
    "question": "'재시작의 정석'에 따르면 docker restart 명령을 치기 전에 가장 먼저 해야 하는 일은 무엇인가?",
    "option1": "docker logs로 로그를 파일로 저장해 증거부터 확보한다",
    "option2": "docker compose down으로 전체 컨테이너를 내린다",
    "option3": "curl로 사이트가 200을 반환하는지 확인한다",
    "option4": "최근 백업 파일로 DB를 즉시 복구한다",
    "answerIndex": 0,
    "explanation": "재시작은 병을 고치는 동시에 현장을 치워 버리는 행동이라, 재시작 전에 로그부터 저장하지 않으면 원인을 영영 모르게 된다. curl 확인은 재시작 후 마지막 단계이고, 전체를 내리는 명령은 코스가 '절대 하지 말 것'으로 경고한다."
  },
  {
    "courseSlug": "ops-basics",
    "question": "아침에 확인해 보니 학습 플랫폼 사이트 자체는 잘 열리는데, 로그인 버튼만 누르면 500 에러가 난다. 코스의 원인 좁히기 논리대로라면 가장 먼저 무엇을 해야 할까?",
    "option1": "ping과 SSH로 서버가 살아 있는지부터 확인한다",
    "option2": "도메인과 인증서 설정이 꼬였는지 확인한다",
    "option3": "서버와 Caddy는 무죄로 보고 백엔드(Spring Boot) 로그부터 확인한다",
    "option4": "제1용의자인 최근 배포 내역을 확인하고 이전 버전으로 롤백한다",
    "answerIndex": 2,
    "explanation": "사이트가 '열린다'는 사실 자체가 서버와 Caddy는 살아 있다는 알리바이가 되어 용의선상에서 빠진다. 시나리오 B처럼 범위가 이미 백엔드·DB로 좁혀졌으므로 백엔드 로그부터 보는 것이 순서다."
  }
]
