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

2026년 10월 9일 금요일

18 분 소요

시리즈의 마지막, 전 범위 모의고사입니다. 풀이 요령은 GitHub Foundations 모의고사와 같습니다.

60분 안에 풀어 봅니다(실제 시험과 같은 시간, 비슷한 문항 밀도입니다)
한 문항씩 즉시 해설을 보지 말고, 끝까지 푼 뒤 채점합니다
35문항(70%) 이상이면 응시를 준비할 수 있는 수준으로 봅니다(실제 합격선은 공개되지 않으며 보수적 기준입니다)
약한 영역이 보이면 해당 편(#2〜#9)으로 돌아가 정리합니다

영역 분포 #

영역	문항	범위
IaC 개념·테라폼의 목적 (#2)	6	Q1〜Q6
기본기: 버전·provider (#3)	6	Q7〜Q12
핵심 워크플로 (#4)	8	Q13〜Q20
state 관리 (#5)	8	Q21〜Q28
모듈 (#6)	6	Q29〜Q34
설정 작성·커스텀 조건 (#7)	7	Q35〜Q41
신규 범위: ephemeral·메타 인수 (#8)	5	Q42〜Q46
HCP Terraform (#9)	4	Q47〜Q50

IaC 개념·테라폼의 목적 (Q1〜Q6) #

Q1. IaC(Infrastructure as Code)의 이점으로 보기 어려운 것은 무엇인가?

A 같은 코드로 동일한 환경을 반복 생성할 수 있다 B 인프라 변경이 버전 관리와 코드 리뷰의 대상이 된다 C 클라우드 요금 단가가 자동으로 낮아진다 D 환경 간 설정 어긋남(드리프트)이 줄어든다

Q2. 테라폼의 설정 방식을 가장 정확히 설명한 것은 무엇인가?

A 원하는 상태에 도달하는 절차를 순서대로 기술하는 명령형이다 B 원하는 최종 상태를 기술하면 도구가 도달 방법을 계산하는 선언형이다 C 상태를 갖지 않는 순수 함수형이다 D 각 클라우드의 콘솔 조작을 녹화해 재생하는 방식이다

Q3. 테라폼 apply를 같은 설정으로 여러 번 실행해도 결과가 같은 성질을 무엇이라 하는가?

A 원자성 B 멱등성 C 가환성 D 불변성

Q4. 테라폼이 수많은 클라우드와 SaaS를 지원할 수 있는 구조적 이유는 무엇인가?

A 코어 바이너리에 모든 클라우드 API가 내장되어 있다 B 클라우드마다 별도의 테라폼 배포판이 존재한다 C 코어와 분리된 provider 플러그인이 각 서비스의 API 호출을 담당한다 D 각 클라우드가 테라폼 문법을 자체 구현한다

Q5. 테라폼 state의 근본 목적으로 가장 알맞은 것은 무엇인가?

A 설정 파일의 문법 오류를 기록한다 B 클라우드 요금을 집계한다 C 실행 로그를 영구 보관한다 D 설정의 리소스와 실제 인프라 객체의 매핑을 유지해 변경 계산을 가능하게 한다

Q6. provisioner에 대한 HashiCorp의 공식 입장으로 알맞은 것은 무엇인가?

A 구성 관리의 권장 표준 방법이다 B 다른 방법이 없을 때의 최후 수단(last resort)이다 C 004에서 폐지되어 사용할 수 없다 D provider의 다른 이름이다

기본기: 버전·provider (Q7〜Q12) #

Q7. 버전 제약 ~> 6.2가 허용하는 범위는 무엇인가?

A 6.2.0만 B 6.2 이상 전부(7.x 포함) C 6.2 이상 7.0 미만 D 6.2 이하 전부

Q8. .terraform.lock.hcl 파일에 대한 설명으로 옳은 것은 무엇인가?

A 민감 정보가 있어 버전 관리에 커밋하면 안 된다 B init이 실제로 고른 provider 버전과 체크섬을 기록하며 커밋해야 한다 C state의 잠금 상태를 기록한다 D 사람이 직접 작성하는 버전 정책 파일이다

Q9. 잠금 파일이 기록한 provider 버전을 허용 범위 안의 최신으로 올리는 명령은 무엇인가?

A terraform init -upgrade B terraform apply -refresh-only C terraform providers update D terraform version -latest

Q10. 같은 AWS provider를 서로 다른 리전 설정으로 두 개 쓰려면 어떻게 하는가?

A 불가능하며 디렉터리를 나눠야 한다 B required_providers에 두 번 선언한다 C 두 번째 provider 블록에 alias를 붙이고 리소스에서 provider 인수로 지정한다 D 리소스의 region 인수로 개별 지정한다

Q11. provider 자격 증명 관리로 권장되는 방식은 무엇인가?

A provider 블록에 액세스 키를 직접 적는다 B tfvars 파일에 평문으로 적어 커밋한다 C state 파일에 미리 넣어 둔다 D 환경 변수나 IAM 역할 같은 외부 주입을 쓴다

Q12. .terraform 디렉터리에 대한 설명으로 옳은 것은 무엇인가?

A state 파일이 저장되므로 백업해야 한다 B provider 플러그인과 모듈 캐시가 담기며 init으로 재생성 가능해 커밋하지 않는다 C 삭제하면 인프라도 함께 삭제된다 D 잠금 파일이 들어 있어 커밋해야 한다

핵심 워크플로 (Q13〜Q20) #

Q13. HashiCorp가 정의하는 테라폼 핵심 워크플로 3단계는 무엇인가?

A Init, Validate, Deploy B Write, Plan, Apply C Code, Build, Release D Plan, Approve, Destroy

Q14. terraform init을 다시 실행해야 하는 상황이 아닌 것은 무엇인가?

A 백엔드 설정을 바꿨을 때 B required_providers에 provider를 추가했을 때 C module 블록의 source를 바꿨을 때 D 리소스의 태그 값을 수정했을 때

Q15. plan에서 확인한 내용을 그 사이의 변경 없이 정확히 그대로 적용하는 방법은 무엇인가?

A plan -out으로 계획을 저장하고 apply에 그 파일을 넘긴다 B plan 직후 빠르게 apply를 실행한다 C apply -auto-approve를 쓴다 D plan 출력을 복사해 apply에 붙여 넣는다

Q16. 손상된 것으로 의심되는 리소스 하나를 다음 apply에서 강제로 다시 만들게 하는 현행 방법은 무엇인가?

A terraform taint 명령을 쓴다 B state에서 rm 한 뒤 apply 한다 C plan·apply에 -replace=주소 플래그를 쓴다 D 리소스 블록을 지웠다가 다시 추가한다

Q17. -target 플래그에 대한 설명으로 가장 알맞은 것은 무엇인가?

A 일상 워크플로에서 적용 범위를 좁히는 권장 방법이다 B 의존성 그래프의 일부만 적용하므로 예외 상황의 임시 수단으로만 쓴다 C 지정한 리소스를 삭제하는 플래그다 D plan에서만 쓸 수 있다

Q18. terraform validate에 대한 설명으로 옳은 것은 무엇인가?

A 클라우드에 연결해 실제 값의 유효성을 검사한다 B 코드를 표준 스타일로 재포맷한다 C 자격 증명 없이 문법과 내부 일관성을 검사하며 init 이후에 동작한다 D state와 실제 인프라의 어긋남을 찾아낸다

Q19. 가장 상세한 테라폼 디버그 로그를 파일로 남기는 설정은 무엇인가?

A 환경 변수 TF_LOG=TRACE와 TF_LOG_PATH를 지정한다 B terraform apply –debug 플래그를 쓴다 C terraform log enable 명령을 실행한다 D 설정 파일에 logging 블록을 추가한다

Q20. terraform destroy와 같은 일을 하는 명령은 무엇인가?

A terraform rm -all B terraform state rm C terraform plan -destroy D terraform apply -destroy

state 관리 (Q21〜Q28) #

Q21. 기본(로컬 백엔드) 동작에서 state가 저장되는 위치는 어디인가?

A .terraform 디렉터리 안 B 작업 디렉터리의 terraform.tfstate 파일 C 홈 디렉터리의 .terraformrc D provider가 지정한 클라우드 버킷

Q22. 원격 백엔드가 로컬 state 대비 제공하는 이점이 아닌 것은 무엇인가?

A 팀원 모두가 같은 state를 공유한다 B 동시 실행을 막는 잠금을 지원할 수 있다 C plan 계산이 더 정확해진다 D 노트북 분실 같은 유실 위험에서 벗어난다

Q23. apply를 실행하자 “Error acquiring the state lock"이 나왔다. 가장 먼저 할 일은 무엇인가?

A Lock Info의 실행 주체를 확인하고 진행 중인 작업이면 끝나기를 기다린다 B 즉시 force-unlock으로 잠금을 푼다 C state 파일을 삭제하고 다시 시도한다 D 백엔드 설정을 로컬로 되돌린다

Q24. terraform force-unlock에 대한 설명으로 옳은 것은 무엇인가?

A state 내용을 마지막 정상 버전으로 되돌린다 B 잠금만 해제할 뿐 state 내용은 바꾸지 않는다 C 진행 중인 apply를 안전하게 중단시킨다 D 백엔드의 잠금 기능을 영구히 끈다

Q25. terraform state rm을 실행하면 어떻게 되는가?

A 실제 리소스가 삭제된다 B 리소스가 다음 apply에서 교체된다 C 리소스는 남고 테라폼의 관리 대상에서만 빠진다 D state 파일 전체가 삭제된다

Q26. 리소스 블록의 이름을 바꾸면서 재생성을 피하는 선언형 방법은 무엇인가?

A moved 블록으로 옛 주소와 새 주소를 선언한다 B removed 블록을 쓴다 C -replace 플래그를 쓴다 D 아무것도 안 해도 테라폼이 이름 변경을 자동 인식한다

Q27. 콘솔에서 먼저 만들어진 기존 리소스를 테라폼 관리로 가져오는 현행 표준은 무엇인가?

A 리소스 블록만 쓰고 apply 한다 B state 파일에 JSON을 직접 추가한다 C refresh를 실행한다 D import 블록을 선언하고 plan으로 확인 후 apply 한다

Q28. sensitive = true로 표시한 변수 값에 대한 설명으로 옳은 것은 무엇인가?

A state에도 암호화되어 저장된다 B plan 출력에서 가려질 뿐 state에는 평문으로 남는다 C 로그와 state 모두에서 완전히 제거된다 D 그 변수는 워크플로에서 사용할 수 없게 된다

모듈 (Q29〜Q34) #

Q29. 테라폼에서 루트 모듈이란 무엇인가?

A 레지스트리에서 verified 표시를 받은 모듈 B 다른 모듈을 하나도 부르지 않는 모듈 C 테라폼을 실행하는 작업 디렉터리의 설정 D HashiCorp가 배포하는 표준 모듈

Q30. module 블록의 version 인수가 유효한 source는 무엇인가?

A ../modules/network 같은 로컬 경로 B terraform-aws-modules/vpc/aws 같은 레지스트리 주소 C git:: 접두사의 Git 주소 D 모든 source에서 유효하다

Q31. 자식 모듈이 만든 값을 호출하는 쪽에서 읽는 방법은 무엇인가?

A 모듈이 output으로 내보낸 값을 module.이름.출력이름으로 참조한다 B module.이름.리소스주소로 안의 리소스에 직접 접근한다 C 자식 모듈의 state 파일을 직접 읽는다 D 전역 변수로 자동 노출된다

Q32. module 블록을 새로 추가한 뒤 plan이 “Module not installed” 에러를 낸다. 해결은 무엇인가?

A terraform apply -auto-approve B terraform refresh C 모듈 디렉터리를 .terraform에 수동 복사 D terraform init

Q33. 퍼블릭 레지스트리의 verified 표시에 대한 설명으로 옳은 것은 무엇인가?

A verified가 아닌 모듈은 다운로드할 수 없다 B HashiCorp가 검증한 파트너의 모듈임을 나타내는 신뢰 참고 정보다 C 보안 취약점이 없음을 보증한다 D 자동 업데이트가 적용된다는 표시다

Q34. 레지스트리 모듈에 version을 지정하지 않으면 어떻게 되는가?

A init이 에러로 거부한다 B 1.0.0으로 고정된다 C 최신 버전을 받아 실행 시점마다 달라질 수 있다 D 잠금 파일이 버전을 대신 고정한다

설정 작성·커스텀 조건 (Q35〜Q41) #

Q35. 같은 변수에 값이 여러 경로로 들어올 때 최종 적용되는 것은 무엇인가?

A 환경 변수 TF_VAR_ B terraform.tfvars C *.auto.tfvars D 명령줄의 -var

Q36. locals에 대한 설명으로 옳은 것은 무엇인가?

A 선언과 참조 모두 locals 키워드를 쓴다 B locals 블록으로 선언하고 local.이름으로 참조한다 C 외부에서 값을 주입받는 입구다 D output의 다른 이름이다

Q37. 사용자 데이터 스크립트 파일을 읽으면서 변수를 치환해 넣고 싶다. 알맞은 함수는 무엇인가?

A templatefile B file C jsonencode D format

Q38. 표현식의 결과를 apply 없이 대화형으로 실험하는 명령은 무엇인가?

A terraform test B terraform eval C terraform console D terraform expression

Q39. 리소스의 lifecycle 블록 안에서 “이 리소스를 평가하기 전에 성립해야 할 가정"을 검증하는 것은 무엇인가?

A postcondition B precondition C validation D check

Q40. postcondition 안에서 자기 자신의 속성을 참조하는 키워드는 무엇인가?

A this B each C resource D self

Q41. 커스텀 조건 중 실패해도 apply를 차단하지 않고 경고만 남기는 것은 무엇인가?

A check 블록 B precondition C postcondition D 변수 validation

신규 범위: ephemeral·메타 인수 (Q42〜Q46) #

Q42. ephemeral 값의 성질로 옳은 것은 무엇인가?

A state에 암호화되어 저장된다 B 첫 apply 때 한 번만 생성되어 재사용된다 C plan과 state에 저장되지 않고 실행 중에만 존재한다 D 문자열 타입만 가능하다

Q43. aws_db_instance의 password_wo 같은 write-only 인수의 값을 나중에 교체하는 방법은 무엇인가?

A 새 값을 넣으면 테라폼이 차이를 감지해 적용한다 B 짝이 되는 _wo_version 값을 올려 변경을 알린다 C state를 삭제하고 다시 apply 한다 D write-only 값은 교체할 수 없다

Q44. depends_on을 쓰는 것이 정당한 경우는 무엇인가?

A 리소스 간 참조가 없지만 실제로는 순서 의존이 있는 경우 B 모든 리소스의 생성 순서를 명시하고 싶은 경우 C apply 속도를 높이고 싶은 경우 D 참조가 이미 있는 리소스의 순서를 한 번 더 보장하고 싶은 경우

Q45. 리스트 기반 count로 만든 리소스들에서 리스트 중간 요소를 제거하면 무슨 일이 일어나는가?

A 해당 요소만 정확히 삭제된다 B 아무 변화도 없다 C 전체가 재생성된다 D 뒤 요소들의 인덱스가 밀려 의도하지 않은 교체·삭제가 계획된다

Q46. 운영 데이터베이스가 실수로 삭제 계획에 포함되는 것을 테라폼 차원에서 막는 설정은 무엇인가?

A ignore_changes = all B lifecycle의 prevent_destroy = true C create_before_destroy = true D depends_on 추가

HCP Terraform (Q47〜Q50) #

Q47. HCP Terraform의 workspace에 대한 설명으로 옳은 것은 무엇인가?

A CLI의 terraform workspace 명령과 같은 기능이다 B 하나의 조직에는 workspace를 하나만 둘 수 있다 C 설정 하나에 대한 state, 변수, 실행 이력을 담는 관리 단위다 D state를 저장하지 않는다

Q48. 여러 workspace에 공통 클라우드 자격 증명을 공급하는 표준 방법은 무엇인가?

A variable set을 만들어 대상 workspace들에 적용한다 B 각 workspace에 수동으로 복사해 등록한다 C 설정 파일에 하드코딩한다 D state 파일에 넣어 공유한다

Q49. Sentinel 정책 중 위반 시 차단되지만 권한자가 오버라이드하고 진행할 수 있는 수준은 무엇인가?

A hard-mandatory B soft-mandatory C advisory D optional

Q50. Terraform Enterprise는 무엇인가?

A HCP Terraform의 무료 티어 이름 B 테라폼 CLI의 유료 버전 C HCP Terraform 기능을 조직 인프라에 직접 설치하는 자체 호스팅판 D AWS 전용 테라폼 배포판

채점과 다음 단계 #

35문항(70%) 이상이면 응시를 준비할 수 있는 수준입니다. 틀린 문항은 영역 분포 표에서 해당 편을 찾아 돌아가고, 특히 #7의 커스텀 조건과 #8의 신규 범위는 004에서 새로 들어온 만큼 오답이 몰렸다면 우선 보강 대상입니다. 응시 전에는 공식 study guide와 샘플 문항으로 시험의 영어 표현에 한 번 익숙해지는 것을 권합니다.

시리즈와 함께한 학습이 여기서 끝납니다. 이 자격증 라인의 기반이 된 테라폼 기초·실전·운영 트랙 26편이 실무의 깊이를 담당하니, 시험 준비 중 손이 기억하지 못하는 개념을 만나면 언제든 트랙으로 내려가 실습을 곁들이기를 권합니다. 합격을 빕니다.