Terraform Associate 004 #8 신규 범위 집중: ephemeral, write-only, 메타 인수
이번 편은 004에서 새로 들어왔거나 비중이 커진 항목을 한자리에 모은, 이 시리즈에서 003 자료와 가장 차이가 나는 편입니다. 다행히 트랙을 따라온 분에게는 전부 실습해 본 내용입니다. 실전 #6의 시크릿 구성과 기초 #6·#7의 메타 인수가 그것이며, 시험이 묻는 각도로 재정렬합니다.
ephemeral: 기록에 남지 않는 값 #
ephemeral(임시) 값은 plan과 state 어디에도 저장되지 않고 실행 중에만 존재하는 값입니다. 출제 포인트는 어떤 성질을 갖는지와 어디에 쓸 수 있는지입니다.
- 성질: 실행마다 새로 평가되며, 기록이 남지 않으므로 시크릿 취급에 적합합니다.
- 자리:
ephemeral "random_password"같은 ephemeral 리소스,ephemeral = true를 붙인 변수·output, 그리고 ephemeral 값을 받을 수 있는 곳(write-only 인수, provider 설정 등)이 짝을 이룹니다. - 제약: ephemeral 값은 일반 리소스 인수처럼 state에 저장되는 자리에는 넣을 수 없습니다. 넣으려면 다음의 write-only 인수가 필요합니다. 이 제약이 곧 다음 절과의 연결 고리이자 시험의 연결 문항 포인트입니다.
write-only 인수: state 평문 문제의 근본 대응 #
#5에서 “state는 평문"이라는 문제를 확인했고, sensitive는 화면만 가린다고 했습니다. write-only 인수는 이 문제의 언어 차원 해법입니다. password_wo처럼 _wo 접미사가 붙은 인수는 값을 provider에 전달만 하고 plan·state에 저장하지 않습니다.
ephemeral "random_password" "db" {
length = 24
}
resource "aws_db_instance" "main" {
# ...
password_wo = ephemeral.random_password.db.result
password_wo_version = 1
}출제가 집중되는 지점은 _wo_version의 존재 이유입니다. 값이 state에 없으므로 테라폼은 값의 변경을 감지할 수 없고, 그래서 교체하고 싶을 때는 값을 바꾸는 것이 아니라 버전 번호를 올려 변경을 알립니다. “write-only 값을 로테이션하는 방법은?“의 답이 _wo_version 증가입니다. sensitive(출력 마스킹) → ephemeral(기록 없는 값) → write-only(기록 없는 전달)로 이어지는 3단 구분을 정리해 두면 이 영역의 비교 문항이 전부 풀립니다.
depends_on: 언제가 정답인가 #
메타 인수 쪽으로 넘어갑니다. depends_on 문항의 정답 방향은 기초 #6의 원칙 그대로입니다. 테라폼은 참조에서 의존성을 자동 추론하므로, depends_on은 참조로 표현되지 않는 숨은 의존(IAM 정책이 부여된 뒤에야 동작하는 리소스 등)에만 씁니다. “모든 리소스에 depends_on을 명시해 순서를 확실히 한다"는 선택지는 오답입니다. 불필요한 선언은 병렬성만 줄입니다.
count vs for_each #
- count: 정수로 복제,
count.index사용,조건 ? 1 : 0의 조건부 생성 관용구. - for_each: 맵·셋으로 복제,
each.key·each.value사용, 리스트는toset()필요. - 선택 기준: 동일 복제·조건부 생성은 count, 이름 있는 집합은 for_each. count는 중간 요소 제거 시 인덱스가 밀려 의도치 않은 재생성이 일어난다는 함정이 출제 단골입니다.
lifecycle 세 인수: 효과로 구분 #
| 인수 | 효과 | 대표 용도 |
|---|---|---|
create_before_destroy | 교체 순서를 “만들고 지우기"로 반전 | 무중단 교체, name_prefix와 짝 |
prevent_destroy | 삭제 계획이 생기면 에러로 차단 | 운영 DB·데이터 리소스 보호 |
ignore_changes | 지정 속성의 외부 변경을 plan에서 무시 | 오토 스케일링이 바꾸는 desired_capacity |
여기에 #4의 -replace 플래그(taint 명령의 후속)와 # forces replacement 표시(기초 #7)를 묶으면 교체 관련 문항 세트가 완성됩니다. prevent_destroy의 한계(콘솔 삭제는 못 막고, 블록 삭제와 함께 보호도 사라짐)도 상황 문항으로 나옵니다.
정리 #
이번 글에서 다룬 내용입니다.
- ephemeral 값은 plan·state에 남지 않는 실행 중 전용 값이며, state에 저장되는 일반 인수 자리에는 넣을 수 없습니다
- write-only 인수는 값을 전달만 하고 기록하지 않으며, 교체는 값 변경이 아니라 _wo_version 증가로 트리거합니다
- sensitive는 화면 마스킹, ephemeral은 기록 없는 값, write-only는 기록 없는 전달이라는 3단 구분이 비교 문항의 축입니다
- depends_on은 참조로 표현 안 되는 숨은 의존에만 쓰는 예외 도구입니다
- count는 인덱스 밀림 함정, for_each는 키 기반 안전이 구분점이고, lifecycle 세 인수는 순서 반전·삭제 차단·변경 무시로 효과가 다릅니다
다음 글(#9 HCP Terraform)에서는 004에서 출제 폭이 넓어진 관리형 플랫폼 영역을 다룹니다. workspace와 project, variable set, 정책과 드리프트 감지입니다.