퀴즈: 상태 조작과 import

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

1. `terraform state rm aws_instance.web` 을 실행하면 실제로 무슨 일이 일어나나요?

   1. 상태와 함께 코드의 리소스 블록까지 정리되어 사라진다
   2. 상태 파일에서만 항목이 사라지고 실물은 그대로 남는다
   3. 지정한 인스턴스가 백업 상태 파일로 옮겨져 따로 보관된다
   4. 실제 EC2 인스턴스가 종료되고 상태에서도 함께 지워진다

2. 리소스 이름을 코드에서만 바꾸고 상태는 그대로 두면 계획에 무엇이 뜨나요?

   1. 이름은 상태 주소와 무관하므로 변경 없음으로 나온다
   2. 리소스 이름만 바뀐다는 안내가 뜨고 실물은 그대로 유지된다
   3. 상태에 없는 주소라며 오류가 나고 계획이 중단된다
   4. 옛 이름의 파괴와 새 이름의 생성이 나란히 뜬다

3. `state mv` 대신 `moved` 블록을 쓰는 이점은?

   1. 상태 주소만 바꾸는 `state mv` 와 달리 실물 자원까지 새 이름으로 옮겨 준다
   2. 상태 전체를 다시 쓰지 않고 해당 항목만 고치므로 대규모 상태에서 훨씬 빠르다
   3. 리팩터링 이력이 코드에 남아 다른 사람이 plan 만 돌려도 같은 이주가 자동으로 일어난다
   4. 코드로 처리되므로 원격 백엔드의 상태 잠금을 잡지 않고도 이주를 끝낼 수 있다

4. 콘솔에서 만들어진 자원을 코드 관리 아래로 데려오려 합니다. 반드시 먼저 해야 할 일은?

   1. 상태 파일을 열어 리소스 항목을 손으로 적어 넣는다
   2. import 는 원격 백엔드에서만 되므로 백엔드를 먼저 옮긴다
   3. 콘솔에서 그 자원을 지우고 같은 설정으로 코드에서 다시 만든다
   4. 코드에 그 자원의 리소스 블록을 먼저 선언한다

5. import 직후 첫 계획을 반드시 읽어야 하는 이유는?

   1. import 로 올린 항목은 임시 표시가 붙어 있어 계획을 한 번 통과해야 확정되기 때문
   2. import 중에 걸린 상태 잠금이 다음 계획을 한 번 돌려야 비로소 풀리기 때문
   3. 실물의 실제 속성이 코드와 다르면 다음 apply 가 그 차이를 코드 기준으로 밀어 버리기 때문
   4. 가져오는 순간 실물의 모든 속성이 코드 블록에 자동으로 채워져 그 결과를 검토해야 하기 때문

6. 상태를 만지기 전 사본이 올바른지 확인하는 실용적인 방법은?

   1. 사본과 현재 파일의 바이트 크기가 같은지 비교한다
   2. 파일 수정 시각이 마지막 apply 시각과 맞는지 비교한다
   3. 사본과 현재 상태의 `lineage` 값이 같은지 비교한다
   4. 두 파일의 리소스 이름 목록을 눈으로 훑어 비교한다