クイズ: ワークスペースとディレクトリ分離

local 백엔드에서 workspace 를 dev 로 선택하고 apply 했다. 상태 파일은 어디에 생기는가?

• terraform.tfstate.d/dev/terraform.tfstate
• 작업 디렉터리의 terraform.tfstate 를 dev 용으로 덮어쓴다
• .terraform/dev/terraform.tfstate
• terraform.tfstate.dev 라는 이름으로 나란히 생긴다

지금 어느 workspace 가 선택돼 있는지를 기억하는 곳은 어디인가?

• 상태 파일 안의 workspace 필드
• 작업 디렉터리의 .terraform/environment 파일
• 환경 변수 TF_WORKSPACE 만이 유일한 기록이다
• 백엔드 저장소에 사용자별로 기록된다

공식 문서가 workspace 를 쓰지 말라고 적은 상황은 무엇인가?

• 같은 설정의 임시 복제본을 만들어 변경을 시험할 때
• 기능 브랜치마다 짧게 살다 사라지는 인프라를 만들 때
• 환경마다 자격증명과 접근 제어가 갈라지는 배포를 나눌 때
• workspace 이름을 자원 태그에 넣어 구분하려 할 때

sizes 맵에 default·dev·prod 만 있는데 stage workspace 를 새로 만들어 apply 하면 어떻게 되는가?

• 맵에 없는 키라 plan 단계에서 오류로 막힌다
• stage 라는 키가 자동으로 추가되고 null 이 들어간다
• apply 는 되지만 상태가 default 와 공유된다
• lookup 의 세 번째 인자인 기본값으로 조용히 적용된다

workspace 방식과 디렉터리 분리 방식을 견줄 때 사실인 것은?

• 디렉터리 분리는 환경마다 .terraform 캐시를 따로 만들어 디스크와 초기화 비용이 더 든다
• workspace 방식은 환경마다 백엔드 설정을 다르게 줄 수 있어 자격증명을 분리할 수 있다
• 디렉터리 분리는 상태 파일이 하나로 합쳐져 잠금 경합이 줄어든다
• workspace 방식은 코드가 환경마다 따로라 리뷰에서 차이가 바로 보인다

prod 를 선택한 줄 모르고 destroy 를 치는 사고를 구조적으로 막는 방법으로 가장 적절한 것은?

• destroy 명령에만 -auto-approve 를 빼고 사람이 확인하게 한다
• 쓰기 명령 앞에서 기대한 workspace 인지 검사해 아니면 0 이 아닌 코드로 멈추는 스크립트를 거치게 한다
• prod workspace 를 삭제하고 필요할 때마다 새로 만든다
• 모든 리소스에 prevent_destroy 를 걸어 둔다