퀴즈: 라이프사이클과 드리프트

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

1. `terraform plan -detailed-exitcode` 가 2 를 반환했습니다. 무슨 뜻인가요?

   1. 변경이 없다 — 코드와 실제 인프라가 완전히 일치해 적용할 것이 없다
   2. 상태 잠금이 걸려 있다 — 다른 실행이 끝날 때까지 기다려야 한다
   3. 오류가 발생했다 — 설정이나 프로바이더 문제로 계획을 만들지 못했다
   4. 적용할 변경이 있다 — 드리프트이거나 아직 적용되지 않은 코드 변경이다

2. 새벽 장애 대응으로 콘솔에서 인스턴스 타입을 키웠고 그 판단이 옳았습니다. 올바른 후속 조치는?

   1. 다음 apply 가 알아서 되돌리게 둔다
   2. 해당 리소스를 상태에서 제거한다
   3. 그 리소스에 ignore_changes 를 영구히 건다
   4. 변경된 값을 코드에 반영하고 커밋한다

3. `ignore_changes` 를 쓰기 좋은 대표적인 자리는?

   1. 오토스케일러가 관리하는 복제 수처럼 의도적으로 코드 밖에서 변하는 속성
   2. 배포마다 무작위 접미사가 새로 붙어 값이 달라지는 리소스 이름 속성
   3. 운영자가 콘솔에서 수시로 붙였다 떼는 모든 태그와 라벨 속성
   4. 장애 대응 중 임시로 열어 두는 일이 잦은 보안 그룹 인바운드 규칙

4. `prevent_destroy = true` 가 걸린 리소스를 코드에서 지우려고 하면?

   1. 상태에서만 지워지고 실물은 그대로 남는다
   2. 이번 계획에서는 빠지고 다음 apply 로 미뤄진다
   3. 계획 단계에서 오류가 나며 실행이 막힌다
   4. 경고 메시지만 뜨고 삭제는 그대로 진행된다

5. `create_before_destroy = true` 를 쓰는 이유는?

   1. 옛 자원의 상태 항목이 먼저 지워져 상태 파일이 작아지게 하려고
   2. 교체가 필요할 때 새 자원을 먼저 만들어 서비스 중단 구간을 없애려고
   3. 매번 새 자원을 만들어 비교함으로써 드리프트를 정확히 감지하려고
   4. 생성과 파괴가 동시에 진행되어 교체에 걸리는 시간을 줄이려고

6. 드리프트 감지를 대규모 인프라에서 자주 돌릴 때 주의할 점은?

   1. 감지할 때마다 조회 결과가 상태에 덧붙어 상태 파일이 걷잡을 수 없이 커지고 느려진다
   2. 모든 자원에 프로바이더 API 를 호출하므로 요청 제한에 걸리고 상태 잠금이 배포와 충돌할 수 있다
   3. 발견한 차이를 도구가 코드에 자동으로 반영해 버려 저장소가 조용히 바뀐다
   4. 새로고침만 하고 계획은 만들지 않아 감지 결과 출력이 늘 비어 있게 된다