クイズ: 状態の管理

상태 파일이 존재하는 이유로 보기 어려운 것은?

• 코드와 실제 리소스의 매핑
• 비밀 값을 안전하게 암호화해 보관
• 리소스 간 의존성 추적
• 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 를 줄인다