[
  {
    "courseSlug": "docker-intro",
    "question": "이 코스는 이미지와 컨테이너를 붕어빵에 비유해 설명합니다. 두 개념의 관계로 옳은 것은 무엇인가요?",
    "option1": "이미지는 실행 중인 프로그램이고, 컨테이너는 그 프로그램의 설계도다",
    "option2": "이미지와 컨테이너는 같은 것을 가리키는 두 가지 다른 이름이다",
    "option3": "이미지는 붕어빵틀처럼 읽기 전용 설계도이고, 컨테이너는 그 틀로 찍어낸 실행 실체다",
    "option4": "이미지는 컨테이너가 종료된 뒤에 남는 실행 기록(로그)을 모아 둔 것이다",
    "answerIndex": 2,
    "explanation": "섹션 2의 붕어빵 비유 그대로, 이미지는 실행에 필요한 모든 것을 구워 놓은 읽기 전용 틀이고 컨테이너는 그 이미지를 실행한 실체입니다. 틀 하나(postgres:17)로 여러 개의 컨테이너를 찍어낼 수 있어요."
  },
  {
    "courseSlug": "docker-intro",
    "question": "도커 5대 기본 명령 중, 실행 중인 컨테이너 '안으로 직접 들어갈' 때 쓰는 명령은 무엇인가요?",
    "option1": "docker ps -a — 멈춘 컨테이너까지 전부 확인한다",
    "option2": "docker exec -it <이름> bash — 컨테이너 안으로 들어간다",
    "option3": "docker logs -f <이름> — 로그를 실시간으로 따라가며 본다",
    "option4": "docker stop <이름> — 컨테이너를 정중하게 멈춘다",
    "answerIndex": 1,
    "explanation": "섹션 4에서 exec은 '문 열고 들어가기'로 기억하라고 했어요. 문제가 생기면 먼저 logs로 일기장을 읽고, 더 파야 할 때 exec으로 컨테이너 안에 직접 들어갑니다."
  },
  {
    "courseSlug": "docker-intro",
    "question": "실습에서 docker compose down으로 DB 컨테이너를 지웠다가 다시 띄웠는데, 어제 만든 hello 테이블과 데이터가 그대로 남아 있었습니다. 코스 내용에 따르면 그 이유는 무엇인가요?",
    "option1": "컨테이너를 삭제하면 도커가 내부 데이터를 자동으로 백업해 두기 때문",
    "option2": "postgres:17 이미지 자체에 사용자가 만든 데이터가 함께 저장되기 때문",
    "option3": "docker compose가 삭제 직전에 데이터를 Git 저장소로 옮겨 두기 때문",
    "option4": "데이터가 컨테이너 밖의 볼륨(practice-data)에 저장되어 컨테이너와 운명을 같이하지 않기 때문",
    "answerIndex": 3,
    "explanation": "섹션 6의 핵심입니다. 컨테이너는 지우면 안이 통째로 사라지는 일회용 도시락통이라, 데이터는 컨테이너 밖의 외장하드인 볼륨에 두어 컨테이너가 죽어도 살아남게 합니다."
  },
  {
    "courseSlug": "docker-intro",
    "question": "우리 docker-compose.yml에서 backend의 DB 주소가 IP가 아니라 jdbc:postgresql://db:5432/mirim처럼 그냥 'db'로 적혀 있습니다. 이게 동작하는 이유는 무엇인가요?",
    "option1": "compose로 띄운 컨테이너들은 같은 가상 네트워크에 들어가고, 서비스 이름이 그대로 도메인 이름이 되기 때문",
    "option2": "도커가 모든 컨테이너의 IP 주소를 항상 'db'라는 고정 별칭 하나로 통일해 주기 때문",
    "option3": "'db'는 호스트 PC의 localhost를 가리키도록 도커가 예약해 둔 특별한 키워드이기 때문",
    "option4": ".env 파일에 'db'라는 이름으로 실제 IP 주소가 미리 등록되어 주입되기 때문",
    "answerIndex": 0,
    "explanation": "섹션 5의 ⑪번 해설 내용입니다. compose가 만든 같은 가상 네트워크 안에서는 서비스 이름(db, backend)이 곧 도메인 이름이 되어, 네트워크 코스에서 배운 DNS가 컨테이너 세계 안에서도 작동하는 셈입니다."
  },
  {
    "courseSlug": "docker-intro",
    "question": "수습 개발자 A가 실습대로 docker compose up -d를 실행했더니 'port is already allocated' 에러가 났습니다. 알고 보니 A의 PC에는 로컬 PostgreSQL이 이미 5432번 포트를 쓰고 있었어요. 코스에서 배운 해결 방법은 무엇인가요?",
    "option1": "ports를 \"5432:15432\"로 바꿔 컨테이너 안의 포스트그레스가 다른 포트를 듣게 한다",
    "option2": "docker compose down -v로 볼륨까지 전부 지운 뒤 처음부터 다시 올린다",
    "option3": "ports를 \"15432:5432\"처럼 바깥쪽(호스트) 번호만 바꿔서 포트 충돌을 피한다",
    "option4": "depends_on 목록에 로컬 PostgreSQL을 추가해서 켜지는 순서를 맞춰 준다",
    "answerIndex": 2,
    "explanation": "포트 매핑은 '바깥:안쪽' 순서라서, 내 PC 쪽 포트가 이미 쓰이고 있으면 바깥 번호만 15432처럼 바꾸면 됩니다. 섹션 7의 회피 기술이자 섹션 8의 '흔한 막힘 포인트'로 소개된 내용이에요."
  }
]
