Infrastructure as Code · 상태 관리 · 퀴즈
퀴즈: 상태 관리
문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
상태 파일이 존재하는 이유로 보기 어려운 것은?
- 코드와 실제 리소스의 매핑
- 비밀 값을 안전하게 암호화해 보관
- 리소스 간 의존성 추적
- API 호출을 줄여 성능 확보
출력에 `sensitive = true` 를 붙이면 무엇이 보장되나?
- 상태 파일에서도 값이 암호화된다
- 값이 아예 저장되지 않는다
- 권한 없는 사용자는 plan 을 실행할 수 없게 된다
- 출력에서 마스킹될 뿐 상태 파일에는 값이 그대로 남는다
다른 사람이 apply 중일 때 내 apply 의 기본 동작은?
- 무한정 기다린다
- 대기 시간 기본값이 0초라 즉시 실패한다
- 잠금을 무시하고 진행한다
- 자동으로 강제 해제한다
CI 러너가 타임아웃으로 죽어 잠금이 남았다. 강제 해제에 대한 설명으로 옳은 것은?
- 부작용이 없으니 먼저 시도한다
- 잠금은 스스로 만료되므로 아무것도 할 필요가 없다
- 다른 사용자가 실제로 작업 중이면 상태가 깨질 수 있으므로 최후의 수단이다
- 상태 파일을 지우면 함께 풀린다
`state rm` 을 실행하면 어떻게 되나?
- 관리 대상에서만 빠지고 실제 리소스는 그대로 남는다
- 실제 리소스가 삭제된다
- 상태 파일 전체가 초기화된다
- 리소스가 다른 상태 파일로 자동 이동한다
모든 리소스를 상태 파일 하나에 몰았더니 plan 이 10분 넘게 걸리고 API rate limiting 이 발생한다. 가장 적절한 대응은?
- plan 을 여러 개로 나눠 병렬로 돌린다
- 항상 새로고침을 꺼서 원격 조회를 아예 없앤다
- 네트워킹/컴퓨트/DB/모니터링처럼 컴포넌트별로 상태를 쪼개 폭발 반경을 줄인다
- 상태 파일을 원격에서 로컬 디스크로 옮긴다
프로덕션 환경 격리 방식으로 권장되는 것은?
- 워크스페이스 — 코드 중복이 없어 항상 우월하다
- 디렉터리 분리 — 일부 중복은 있지만 환경별 백엔드·IAM 을 나눌 수 있고 폭발 반경이 좁다
- 둘은 동일하므로 아무거나 쓴다
- 환경 구분 없이 하나의 상태로 관리한다
드리프트 감지에서 오토스케일러가 바꾼 `desired_capacity` 가 매일 잡힌다. 가장 적절한 대응은?
- 감지 주기를 주 1회로 늘린다
- 오토스케일링을 끈다
- 모든 드리프트를 CRITICAL 등급으로 올려 잡는다
- 시스템이 관리하는 필드는 `ignore_changes` 로 빼서 false positive 를 줄인다