퀴즈: 멱등성과 핸들러

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

1. 플레이북의 멱등성을 판정하는 가장 실용적인 기준은?

   1. 두 번 연속 실행했을 때 걸린 시간이 거의 같게 나오는 것
   2. 연속 두 번째 실행의 changed 와 failed 가 모두 0 인 것
   3. 모든 태스크에 이름이 있고 전용 모듈만 써서 작성된 것
   4. 첫 실행이 failed 하나 없이 끝까지 완주해 목표 상태에 도달하는 것

2. 핸들러가 실행되는 시점으로 옳은 것은?

   1. notify 한 태스크가 changed 로 끝난 직후
   2. 플레이북의 모든 플레이가 끝난 뒤 마지막에 한 번
   3. 다음 플레이가 시작되기 직전에 몰아서
   4. 기본적으로 플레이의 모든 태스크가 끝난 뒤

3. 같은 핸들러를 세 개의 태스크가 각각 notify 했고 셋 다 changed 였습니다. 핸들러는 몇 번 실행되나요?

   1. 태스크 수만큼 비동기로 실행
   2. 중복 통지를 합쳐 마지막에 1번
   3. 통지만 모이고 실행은 0번
   4. 통지한 태스크마다 각각 3번

4. `shell` 로 파일에 한 줄을 추가하는 태스크를 멱등하게 만드는 방법으로 가장 적절한 것은?

   1. `creates` 로 이미 만들어졌는지 알려 주거나 lineinfile 같은 전용 모듈을 쓴다
   2. `ignore_errors: true` 를 붙여 줄이 중복될 때 나는 오류를 무시하게 한다
   3. 태스크에 태그를 달아 평소 실행에서는 건너뛰고 필요할 때만 지정해 돌린다
   4. `changed_when: false` 를 붙여 매번 changed 로 보고되지 않게 만든다

5. 매 실행마다 서비스가 재시작되는 플레이북에서 가장 먼저 의심할 것은?

   1. 템플릿 렌더링 결과가 매번 달라져 설정 파일이 계속 changed 로 잡히는 것
   2. 핸들러 이름에 공백이 있어 notify 가 매번 새 핸들러를 만들어 내는 것
   3. 인벤토리에 같은 호스트가 두 번 적혀 플레이가 두 번씩 도는 것
   4. SSH 연결이 매번 새로 열려 서비스 상태 조회가 changed 로 잡히는 것

6. 멱등한 플레이북이 드리프트 감지기로도 쓰일 수 있는 이유는?

   1. 실행할 때마다 로그를 자동으로 저장해 두어 이전 상태와 비교할 수 있기 때문
   2. 손으로 고쳐진 서버에서는 changed 가 나오고 그 수가 코드와 어긋난 정도이기 때문
   3. 팩트 수집이 대상 서버의 파일 변경 이력까지 읽어 와 차이를 알려 주기 때문
   4. 핸들러가 발화할 때마다 어떤 설정이 바뀌었는지 기록으로 남기기 때문