测验：计划性能及其代价

큰 상태에서 plan 시간의 대부분을 차지하는 단계는 어디인가?

• 설정 파일을 읽고 의존 그래프를 만드는 단계
• 상태에 적힌 것이 실제로 그대로인지 확인하는 단계
• 변경 목록을 사람이 읽을 형식으로 그리는 단계
• 잠금을 잡고 상태 파일을 내려받는 단계

-refresh=false 를 썼을 때 잃는 것은?

• 설정 문법 검사를 건너뛰어 오타를 못 잡는다
• 상태 잠금을 잡지 않아 동시 실행에 취약해진다
• 도구 밖에서 생긴 변경(드리프트)을 계획에 반영하지 못한다
• 출력값이 계산되지 않아 다른 상태가 읽을 수 없다

-parallelism 값을 바꾸면 무엇이 달라지는가?

• 계획에 담기는 변경 항목이 줄어든다
• 새로 고침 자체를 건너뛴다
• 상태가 여러 파일로 나뉘어 저장된다
• 계획의 내용은 그대로이고 걸리는 시간만 달라진다

공식 문서가 -target 에 대해 적고 있는 권고는?

• 실수에서 복구하거나 도구의 한계를 우회하는 예외적인 상황에서만 쓰라
• 큰 설정에서는 기본으로 사용해 계획 시간을 줄여라
• apply 에만 쓰고 plan 에는 쓰지 마라
• 모듈 단위 주소에만 쓰고 개별 리소스에는 쓰지 마라

상태를 두 개로 나눴을 때 실제로 줄어드는 것은?

• 전체 계획 시간의 합
• 한 사람이 자기 변경을 보기까지 기다리는 시간
• 프로바이더 플러그인이 차지하는 디스크
• 설정 파일의 총 줄 수

저장해 둔 계획 파일을 적용하려는데 그 사이 다른 적용이 상태를 바꿨다. 어떻게 되는가?

• 바뀐 부분만 다시 계산해 적용한다
• 경고를 내고 저장된 계획대로 적용한다
• 계획이 낡았다며 적용을 거절한다
• 상태를 계획 시점으로 되돌린 뒤 적용한다