Quiz: Declarative Style and State

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

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

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

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

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

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

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

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

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

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

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

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