LabHub

Infrastructure as Code · 상태 관리 · 퀴즈

퀴즈: 상태 관리

LabHub 에서 이어서 보기

문항 8개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

    1. 코드와 실제 리소스의 매핑
    2. 비밀 값을 안전하게 암호화해 보관
    3. 리소스 간 의존성 추적
    4. API 호출을 줄여 성능 확보
  2. 출력에 `sensitive = true` 를 붙이면 무엇이 보장되나?

    1. 상태 파일에서도 값이 암호화된다
    2. 값이 아예 저장되지 않는다
    3. 권한 없는 사용자는 plan 을 실행할 수 없게 된다
    4. 출력에서 마스킹될 뿐 상태 파일에는 값이 그대로 남는다
  3. 다른 사람이 apply 중일 때 내 apply 의 기본 동작은?

    1. 무한정 기다린다
    2. 대기 시간 기본값이 0초라 즉시 실패한다
    3. 잠금을 무시하고 진행한다
    4. 자동으로 강제 해제한다
  4. CI 러너가 타임아웃으로 죽어 잠금이 남았다. 강제 해제에 대한 설명으로 옳은 것은?

    1. 부작용이 없으니 먼저 시도한다
    2. 잠금은 스스로 만료되므로 아무것도 할 필요가 없다
    3. 다른 사용자가 실제로 작업 중이면 상태가 깨질 수 있으므로 최후의 수단이다
    4. 상태 파일을 지우면 함께 풀린다
  5. `state rm` 을 실행하면 어떻게 되나?

    1. 관리 대상에서만 빠지고 실제 리소스는 그대로 남는다
    2. 실제 리소스가 삭제된다
    3. 상태 파일 전체가 초기화된다
    4. 리소스가 다른 상태 파일로 자동 이동한다
  6. 모든 리소스를 상태 파일 하나에 몰았더니 plan 이 10분 넘게 걸리고 API rate limiting 이 발생한다. 가장 적절한 대응은?

    1. plan 을 여러 개로 나눠 병렬로 돌린다
    2. 항상 새로고침을 꺼서 원격 조회를 아예 없앤다
    3. 네트워킹/컴퓨트/DB/모니터링처럼 컴포넌트별로 상태를 쪼개 폭발 반경을 줄인다
    4. 상태 파일을 원격에서 로컬 디스크로 옮긴다
  7. 프로덕션 환경 격리 방식으로 권장되는 것은?

    1. 워크스페이스 — 코드 중복이 없어 항상 우월하다
    2. 디렉터리 분리 — 일부 중복은 있지만 환경별 백엔드·IAM 을 나눌 수 있고 폭발 반경이 좁다
    3. 둘은 동일하므로 아무거나 쓴다
    4. 환경 구분 없이 하나의 상태로 관리한다
  8. 드리프트 감지에서 오토스케일러가 바꾼 `desired_capacity` 가 매일 잡힌다. 가장 적절한 대응은?

    1. 감지 주기를 주 1회로 늘린다
    2. 오토스케일링을 끈다
    3. 모든 드리프트를 CRITICAL 등급으로 올려 잡는다
    4. 시스템이 관리하는 필드는 `ignore_changes` 로 빼서 false positive 를 줄인다