クイズ: リソースと依存関係

암묵적 의존성이 만들어지는 조건은?

• 리소스 이름이 알파벳 순으로 이어질 때
• 다른 리소스의 속성을 식으로 참조했을 때
• 같은 프로바이더를 쓰는 리소스끼리 자동으로
• 같은 파일 안에 리소스를 위아래로 배치했을 때

depends_on 을 써야 하는 상황으로 가장 적절한 것은?

• 다른 리소스가 만든 ID 를 인자로 써야 해서 순서를 확실히 해 두고 싶을 때
• 값으로는 드러나지 않는 부수 효과 때문에 순서가 필요할 때
• 삭제 순서는 그래프로 정해지지 않으므로 파괴 순서를 직접 지정하고 싶을 때
• 모듈을 여러 개 호출할 때 모듈 사이의 실행 순서를 보장하려면 항상

depends_on 을 여기저기 남발했을 때 나타나는 실질적 손해는?

• 명시적 의존이 걸린 리소스의 속성은 output 으로 내보낼 수 없게 되어 모듈 인터페이스가 좁아진다
• 상태의 dependencies 가 명시 목록으로 덮여 삭제 순서를 도구가 계산하지 못하게 된다
• 그래프가 커질 때마다 .terraform.lock.hcl 의 해시가 다시 계산되어 잠금 파일이 계속 갱신된다
• 동시에 처리할 수 있던 작업이 줄을 서고, 앞 리소스가 재생성될 때 뒤 리소스까지 함께 재생성되는 범위가 넓어진다

코드에서 리소스 선언을 지웠는데도 도구가 올바른 순서로 삭제할 수 있는 이유는?

• 상태 파일의 각 인스턴스에 dependencies 가 기록돼 있기 때문
• 삭제는 의존 관계와 상관없이 병렬로 한꺼번에 수행돼 순서 자체가 필요 없기 때문
• .terraform.lock.hcl 에 리소스 생성 순서가 함께 기록돼 있기 때문
• 프로바이더가 실제 인프라의 참조 관계를 조회해 순서를 되살리기 때문

.terraform.lock.hcl 안의 h1: 또는 zh: 해시가 뜻하는 것은?

• 리소스 속성이 코드와 달라졌는지 비교할 때 쓰는 체크섬
• 원격 백엔드에서 상태 잠금을 걸 때 쓰는 잠금 식별자
• 실제로 내려받은 프로바이더 패키지가 그것이 맞는지 확인하는 지문
• 상태 파일이 손상되지 않았는지 확인하는 무결성 검사값

관리 중인 리소스를 코드 밖에서 고쳤을 때, 다음 정상 배포에서 벌어지는 일은?

• 도구가 그 변경을 무시하고 그대로 둔다
• 적용이 거부되고 오류로 끝난다
• 도구가 그 변경을 코드에 자동으로 반영한다
• 도구가 코드에 적힌 상태로 되돌린다