퀴즈: 리소스와 의존성

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

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

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

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

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

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

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

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

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

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

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

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

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