퀴즈: 선언형과 상태

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

1. Terraform 이 상태 파일을 두는 근본적인 이유는?

   1. init 이 내려받은 프로바이더 플러그인과 모듈 사본을 담아 두는 캐시이기 때문
   2. 누가 언제 무엇을 적용했는지 사람이 나중에 확인하려고 남기는 감사 기록이기 때문
   3. 코드에 선언한 리소스와 실제 리소스의 매핑을 저장해 차이를 계산하는 기준이 되기 때문
   4. 매번 클라우드 API 를 전부 조회하기에는 느려서 결과를 담아 두는 성능 캐시이기 때문

2. 상태 파일의 `serial` 과 `lineage` 에 대한 설명으로 옳은 것은?

   1. `serial` 은 프로바이더 스키마 버전이고 `lineage` 는 상태 파일 포맷 버전이라, 둘 다 도구를 업그레이드할 때만 바뀌고 평소 적용에서는 그대로다
   2. `serial` 은 상태가 바뀔 때마다 오르는 번호로 충돌 감지에, `lineage` 는 상태 파일의 고유 식별자로 다른 계보의 상태가 섞이는 것을 막는 데 쓰인다
   3. `serial` 은 상태에 등록된 리소스 개수이고 `lineage` 는 마지막으로 적용한 시각이라, 둘을 보면 스택의 규모와 최신성을 한눈에 알 수 있다
   4. 둘 다 백엔드 설정에 사람이 직접 적어 주는 값이라, 팀에서 상태를 구분하려면 이름 규칙을 정해 손으로 관리해야 한다

3. `.terraform.lock.hcl` 을 저장소에 커밋해야 하는 이유는?

   1. 프로바이더 버전과 해시를 못 박아 내 노트북과 CI 가 같은 것을 받게 하기 때문
   2. 이 파일이 있어야 `init` 이 프로바이더를 찾을 수 있어 없으면 초기화가 실패하기 때문
   3. 상태 파일이 깨졌을 때 복구에 쓰는 리소스 목록 백업본이 함께 들어 있기 때문
   4. 변수 파일에 적은 비밀 값을 해시로 바꿔 담아 저장소에 안전하게 남기기 때문

4. 적용이 끝난 뒤 관리 중인 파일을 셸에서 손으로 지웠습니다. 다음 `plan` 의 결과로 가장 알맞은 것은?

   1. 실물이 사라진 것을 감지해 코드의 리소스 선언까지 함께 지워 준다
   2. 상태 파일에는 그대로 남아 있으므로 변경 없음으로 나온다
   3. 실제를 조회한 뒤 그 리소스를 다시 만들겠다는 계획을 낸다
   4. 상태와 실물이 어긋났다며 오류를 내고 계획을 중단한다

5. 다른 리소스가 만든 값을 눈으로 보고 문자열에 그대로 적었을 때 생기는 문제는?

   1. 같은 값이 두 리소스에 중복 저장되어 상태 파일이 커지고 조회가 느려진다
   2. 참조가 아니라 문자열이므로 계획에서 그 인자가 `(known after apply)` 로 표시된다
   3. `validate` 단계에서 참조되지 않은 값이라며 문법 오류로 걸러진다
   4. 의존 관계가 생기지 않아 생성·삭제 순서가 보장되지 않고 앞 값이 바뀌어도 따라가지 않는다

6. 상태 파일을 Git 저장소에 커밋하면 안 되는 가장 중요한 이유는?

   1. 한 줄짜리 JSON 이라 diff 가 통째로 바뀌어 리뷰에서 변경점을 읽을 수 없어서
   2. Git 이 파일 권한을 바꿔 버려 도구가 상태를 잠그거나 갱신하지 못하게 되어서
   3. 비밀번호·토큰이 평문으로 들어 있고 동시 작업 시 병합 충돌이 리소스 유실로 이어져서
   4. 상태 포맷 버전이 도구 업그레이드마다 바뀌어 옛 커밋으로 되돌리면 읽을 수 없어서