Terraform Associate 004 #7 설정 작성: 변수 우선순위, 함수, 커스텀 조건

인프라 Terraform IaC 자격증
4 분 소요

설정 작성 영역은 기초 #3·#4에서 손에 익힌 문법이 대부분이지만, 두 가지가 다릅니다. 시험은 우선순위의 정확한 순서를 묻고, 004는 트랙에서 얕게 지나간 커스텀 조건을 정면으로 묻습니다. 아는 부분은 빠르게 압축하고 보강 부분에 지면을 쓰겠습니다.

변수: 타입과 우선순위 #

타입은 string, number, bool과 컬렉션(list, set, map), 구조형(object, tuple)이 있고, 타입 위반은 plan 전에 거부됩니다. 시험의 단골은 값 입력 경로의 우선순위입니다. 늦게 평가되는 쪽이 이깁니다.

변수 우선순위 
(약함) 환경 변수 TF_VAR_이름
     → terraform.tfvars
     → terraform.tfvars.json
     → *.auto.tfvars (파일명 알파벳 순)
     → -var, -var-file (명령줄, 지정 순서대로)  (강함)

트랙에서 안 쓴 항목이 둘 끼어 있습니다. *.auto.tfvars는 이름과 무관하게 자동 로드되는 파일이고, tfvars의 JSON 표기도 존재합니다. “같은 변수가 여러 곳에 정의되면?” 문항은 이 사다리에서 더 아래(명령줄 쪽)가 이긴다로 답합니다. sensitive = true는 plan 출력을 가릴 뿐 state에는 평문이라는 것(#5)을 여기서도 되새깁니다.

output과 locals: 압축 복습 #

output은 값의 출구이며 terraform output 명령으로 재조회할 수 있고, output에도 sensitive 표시가 가능하며 모듈 간 통로가 됩니다(#6). locals는 내부 계산에 이름을 붙이는 것으로, 선언은 locals 블록·참조는 local.이름이라는 단복수 차이가 자잘한 함정입니다. “사용자가 바꿀 값은 variable, 내부 조합은 locals"라는 기초 #3의 기준이 설계 문항의 답입니다.

함수와 표현식: 출제 단골만 #

함수는 직접 정의할 수 없고 내장 함수만 쓴다는 대전제가 첫 출제 포인트입니다. 문항에 자주 등장하는 것만 추리면 다음과 같습니다.

  • 컬렉션: length, merge(맵 병합, 뒤가 이김), lookup(맵에서 키 조회, 기본값 지정), toset(for_each용 변환)
  • 문자열·인코딩: format, join/split, jsonencode(IAM 정책 단골), base64encode
  • 파일: file(내용 읽기), templatefile(변수 치환하며 읽기, user_data 단골)
  • 타입 판단·조건: can(표현식 성공 여부), try(실패 시 대체값)

표현식 쪽은 조건식 a ? b : c, for 표현식(대괄호=리스트, 중괄호=맵), 스플랫 [*]이 전부이며 기초 #4 그대로입니다. terraform console이 표현식 실험 도구라는 것도 명령 문항으로 나옵니다.

보강: 커스텀 조건 세 종류 #

004가 강화한 영역입니다. 조건을 어디에 거는지에 따라 세 가지가 있고, 무엇을 검증하는가로 구분합니다.

  1. 변수 validation: 입력값 검증. 기초 #3에서 실습한 그것으로, 값이 들어오는 시점에 평가됩니다.

  2. precondition·postcondition: 리소스·데이터 소스·output의 lifecycle 블록 안에 거는 가정의 검증입니다.

main.tf 
data "aws_ami" "al2023" {
  # ... 조회 조건 ...

  lifecycle {
    postcondition {
      condition     = self.architecture == "x86_64"
      error_message = "조회된 AMI는 x86_64 아키텍처여야 합니다."
    }
  }
}

resource "aws_instance" "web" {
  ami = data.aws_ami.al2023.id

  lifecycle {
    precondition {
      condition     = data.aws_ami.al2023.state == "available"
      error_message = "AMI가 available 상태여야 인스턴스를 만들 수 있습니다."
    }
  }
}

precondition은 그 객체를 평가하기 전에 성립해야 할 가정(주로 의존 대상에 대한 확인), postcondition은 평가된 결과가 만족해야 할 보증이며, postcondition 안에서는 self로 자기 속성을 참조합니다. 실패하면 plan·apply가 에러로 멈추므로, “잘못된 전제로 인프라가 만들어지는 것"을 코드가 스스로 막는 장치입니다.

  1. check 블록: 인프라의 지속적 검증입니다. 최상위 check 블록에 assert를 담으며, 결정적 차이는 실패해도 apply를 막지 않고 경고만 남긴다는 것입니다. “배포는 막지 않되 상태를 감시하고 싶다”(인증서 만료 임박 확인 등)가 용도입니다.

구분 문항의 축은 두 개입니다. 검증 대상(입력값 / 가정·결과 / 지속 상태)과 실패의 효과(차단 / 차단 / 경고). 이 두 축만 잡으면 세 장치의 어떤 조합 문항도 풀립니다.

정리 #

이번 글에서 다룬 내용입니다.

  • 변수 우선순위는 환경 변수 → tfvars → auto.tfvars → 명령줄 순으로 뒤가 이깁니다. auto.tfvars의 자동 로드가 낯선 항목입니다
  • 함수는 내장만 가능하며 merge, lookup, templatefile, jsonencode, try·can이 출제 단골입니다
  • validation은 입력값 검증이고 실패 시 차단합니다
  • precondition은 평가 전 가정, postcondition은 평가 후 보증이며 self 참조가 가능하고 둘 다 실패 시 차단합니다
  • check 블록은 지속 검증이며 유일하게 실패해도 apply를 막지 않고 경고만 남깁니다

다음 글(#8 신규 범위 집중)에서는 004의 대표 신규 범위인 ephemeral 값과 write-only 인수, 그리고 depends_on·lifecycle 메타 인수를 묶어 정리합니다.

X