#Terraform

48 편의 글

테라폼 의존성 에러 총정리: Cycle, depends_on 오용, known after apply
5 분 소요

테라폼 의존성 에러 총정리: Cycle, depends_on 오용, known after apply

테라폼 의존성 그래프에서 나오는 세 갈래 문제를 한 번에 정리합니다. Error: Cycle의 대표 사례인 보안 그룹 상호 참조를 분리 리소스로 끊는 법과 terraform graph 진단, 암묵 의존이 기본이고 depends_on은 숨은 의존에만 써야 하는 이유와 남용의 부작용, count와 for_each 키에 계산 전 값이 들어가 나오는 Invalid count argument의 해법까지 다루겠습니다.

tfstate에 시크릿이 평문으로 저장됐을 때: 키 회전과 재발 방지
5 분 소요

tfstate에 시크릿이 평문으로 저장됐을 때: 키 회전과 재발 방지

tfstate가 sensitive 표시와 무관하게 값을 평문으로 담는 구조부터 정리합니다. 노출 범위를 판단하는 순서, state 정리보다 키 회전이 먼저인 이유, git에 state가 커밋된 경우의 히스토리 정리, 그리고 재발 방지로서의 ephemeral 리소스와 write-only 인수, S3 백엔드 암호화와 접근 통제, 시크릿을 애초에 state에 남기지 않는 설계까지 다루겠습니다.

terraform plan이 느릴 때: refresh 부하, 병렬도, 스택 분할 신호
4 분 소요

terraform plan이 느릴 때: refresh 부하, 병렬도, 스택 분할 신호

plan 소요 시간의 본체가 diff 계산이 아니라 리소스마다 API를 읽는 refresh라는 사실부터 정리합니다. 리소스 수와 API 왕복이 시간을 결정하는 구조, -refresh=false를 써도 되는 국면과 안 되는 국면, parallelism 조정이 rate limit과 부딪히는 지점, -target이 성능 도구가 아닌 이유, 그리고 근본 대책인 스택 분할로 넘어가야 하는 신호까지 다루겠습니다.

AWS provider 6.x 업그레이드: breaking change 진단과 안전한 전환 순서
5 분 소요

AWS provider 6.x 업그레이드: breaking change 진단과 안전한 전환 순서

AWS provider 메이저 업그레이드를 안전하게 넘는 절차를 정리합니다. CLI 업그레이드보다 파급이 큰 이유, 최신 5.x를 경유해 deprecation 경고를 소진하는 표준 수순, 6.0의 주요 변경(리소스 단위 region 인수, OpsWorks·SimpleDB 제거, 불리언 엄격화, Redshift 기본값 반전), 스키마 변경이 만드는 가짜 diff와 진짜 교체를 구분하는 plan 판독, 공유 모듈의 버전 하한이 만드는 함정까지 다루겠습니다.

테라폼 버전 업그레이드 절차: 호환성 약속, no-op 검증, 롤백 대비
5 분 소요

테라폼 버전 업그레이드 절차: 호환성 약속, no-op 검증, 롤백 대비

테라폼 CLI 버전을 올리는 안전한 절차를 정리합니다. 1.x 안에서는 구성과 워크플로 호환이 유지된다는 호환성 약속, CLI 업그레이드와 provider 업그레이드를 분리해야 하는 이유, 업그레이드 전후로 변경 없음 plan을 확인하는 검증법, 새 버전이 쓴 state를 구버전이 못 읽을 수 있어 필요한 롤백 대비, tfenv와 mise를 이용한 팀·CI 버전 통일까지 다루겠습니다.

terraform destroy가 실패할 때: DependencyViolation과 지워지지 않는 리소스
5 분 소요

terraform destroy가 실패할 때: DependencyViolation과 지워지지 않는 리소스

destroy 실패의 세 갈래를 구분해 정리합니다. 테라폼 밖에서 만든 리소스가 물고 있어 나오는 DependencyViolation의 진단 순서, 비어 있지 않은 S3 버킷과 force_destroy를 켜고 apply부터 해야 하는 이유, prevent_destroy와 deletion_protection처럼 일부러 걸어 둔 안전장치의 올바른 해제 절차, 삭제가 느린 리소스의 타임아웃, 부분 destroy 후 잔존물 정리까지 다루겠습니다.

terraform plan은 성공했는데 apply가 실패할 때: 원인과 부분 적용 복구
5 분 소요

terraform plan은 성공했는데 apply가 실패할 때: 원인과 부분 적용 복구

plan이 통과했는데 apply가 실패하는 이유를 구조부터 정리합니다. plan은 스키마와 참조만 검증하고 실제 API 검증은 apply에서 처음 일어난다는 비대칭, 권한 부족과 IAM 전파 지연, 서비스 쿼터, 전역 이름 충돌 같은 전형 원인 5가지, apply가 트랜잭션이 아니라서 생기는 부분 적용 상태를 안전하게 복구하는 절차, 이미 존재한다는 에러가 났을 때의 import 판단까지 다루겠습니다.

Terraform Associate 004 #10 모의고사: 전 범위 50문항 + 해설
18 분 소요

Terraform Associate 004 #10 모의고사: 전 범위 50문항 + 해설

시리즈 아홉 편의 범위 전체에서 뽑은 객관식 50문항 모의고사입니다. IaC 개념부터 워크플로, state, 모듈, 설정 작성, 004 신규 범위인 ephemeral과 write-only, HCP Terraform까지 영역별로 배치했고, 문항마다 정답 근거와 오답의 함정을 해설로 달았습니다. 채점 후 약한 영역을 해당 편으로 돌아가 정리하는 마무리 점검용입니다.

Terraform Associate 004 #9 HCP Terraform: workspace, variable set, 정책, 드리프트 감지
5 분 소요

Terraform Associate 004 #9 HCP Terraform: workspace, variable set, 정책, 드리프트 감지

HCP Terraform의 workspace가 CLI 워크스페이스와 이름만 같고 다른 개념이라는 것부터, project로 workspace를 묶는 구조, 실행 방식 세 가지(VCS·CLI·API 연동)를 정리합니다. variable set으로 여러 workspace에 값을 공급하는 방법, Sentinel·OPA 정책의 적용 지점과 하드·소프트 실패 구분, 상시 드리프트 감지, 그리고 Terraform Enterprise와의 관계까지 004에서 넓어진 출제 범위를 다지겠습니다.

Terraform Associate 004 #8 신규 범위 집중: ephemeral, write-only, 메타 인수
4 분 소요

Terraform Associate 004 #8 신규 범위 집중: ephemeral, write-only, 메타 인수

004의 대표 신규 범위를 한 편에 모읍니다. plan과 state에 남지 않는 ephemeral 값의 성질과 쓸 수 있는 자리, write-only 인수가 시크릿 문제를 푸는 방식과 _wo_version으로 교체를 트리거하는 이유를 정리하고, depends_on의 정당한 용도, count와 for_each의 선택, lifecycle 세 인수(create_before_destroy·prevent_destroy·ignore_changes)의 효과 구분까지 메타 인수 전반을 시험 관점으로 다지겠습니다.

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

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

변수 타입과 값 입력 경로의 우선순위, sensitive의 효력 범위, output과 locals의 역할을 시험 관점으로 압축하고, 자주 출제되는 내장 함수와 표현식을 정리합니다. 004에서 강화된 커스텀 조건인 변수 validation, 리소스 precondition·postcondition, check 블록의 구분과 평가 시점까지, 트랙에서 얕게 다룬 부분을 보강하겠습니다.

Terraform Associate 004 #6 모듈: 소스 지정, 버전 고정, 입출력 문법
4 분 소요

Terraform Associate 004 #6 모듈: 소스 지정, 버전 고정, 입출력 문법

모듈의 정의와 루트·자식 모듈 구분부터, 레지스트리·Git·로컬 경로라는 소스 지정 방식별 문법과 version 인수가 동작하는 조건을 시험 관점으로 정리합니다. 모듈에 값을 넣는 입력과 module.이름.출력으로 받는 출력 문법, 모듈 안 리소스에 직접 접근할 수 없다는 캡슐화 원칙, 퍼블릭 레지스트리의 검증 표시까지 출제 포인트를 다지겠습니다.