퀴즈: 관련 실천·패턴·도구 비교

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

1. Terraform 코드를 Git 에 두고 CI 파이프라인이 apply 하는 방식이 OpenGitOps 네 원칙 중 채우지 못하는 것은?

   1. 원칙 1 Declarative — Terraform 은 절차형 스크립트라 선언적이지 않다
   2. 원칙 2 Versioned and Immutable — CI 가 실행하면 Git 이력이 남지 않는다
   3. 원칙 3 Pulled Automatically 와 원칙 4 Continuously Reconciled — 에이전트가 스스로 당겨 어긋남마다 맞추지 않고 트리거로만 민다
   4. 네 원칙을 모두 채우므로 Git 에 둔 IaC 를 CI 가 apply 하는 것만으로 이미 GitOps 다

2. Argo CD 나 Flux 에 Git 웹훅을 붙여도 pull 원칙이 깨지지 않는 이유는?

   1. 웹훅 페이로드에 담긴 매니페스트를 그대로 적용하므로 Git 을 다시 읽을 필요가 없기 때문
   2. 웹훅은 '지금 당겨라' 는 신호일 뿐이며 페이로드는 신뢰하지 않고 어차피 주기적으로 일어나는 refresh 를 앞당기는 것이기 때문
   3. 웹훅을 받으면 조정기가 주기적 폴링을 영구히 끄고 이벤트만으로 동작하기 때문
   4. 웹훅은 CI 시스템이 클러스터 자격증명으로 직접 apply 한 뒤 결과를 통보하는 것이기 때문

3. external 조정기 패턴(한 Argo CD 가 여러 클러스터를 관리)에서 in-cluster 패턴과 달라지는 것은?

   1. 대상 클러스터의 자격증명이 argocd.argoproj.io/secret-type: cluster 시크릿으로 관리 클러스터에 모인다
   2. 각 클러스터마다 애플리케이션 컨트롤러가 따로 떠서 자기 클러스터만 조정한다
   3. destination.server 를 https://kubernetes.default.svc 로 두어 모든 클러스터를 같은 주소로 가리킨다
   4. Git 저장소를 클러스터마다 따로 두어야 하므로 상태 저장소가 여러 개가 된다

4. Argo CD 의 세 구성요소 중 Git 저장소의 로컬 캐시를 유지하며 리비전·경로·values 를 받아 매니페스트를 생성하는 것은?

   1. API 서버 — UI 와 CLI 요청을 받을 때마다 저장소를 직접 clone 해 렌더한다
   2. 애플리케이션 컨트롤러 — 비교 직전에 저장소를 읽어 helm template 을 실행한다
   3. 저장소 서버(repo-server) — 캐시를 유지하고 입력에 따라 매니페스트를 생성해 돌려준다
   4. notification 컨트롤러 — 저장소 변경 사건을 받아 매니페스트를 미리 만들어 둔다

5. Flux 에서 HelmRelease 를 보고 실제 Helm 설치·업그레이드·롤백을 수행하는 컨트롤러와 그 특징은?

   1. kustomize-controller — 차트를 kustomize build 로 렌더한 뒤 적용한다
   2. source-controller — HelmRepository 에서 차트를 받아 바로 설치한다
   3. notification-controller — Helm 저장소 웹훅을 받아 릴리스를 갱신한다
   4. helm-controller — HelmChart 아티팩트로 Helm 액션을 실행하고 실패 시 롤백·재시도 같은 자동 조치를 제공한다

6. 두 도구의 알림 구성 방식을 바르게 짝지은 것은?

   1. Argo CD 는 Provider·Alert CRD 로, Flux 는 Application 어노테이션으로 구독한다
   2. Argo CD 는 Application·Project 의 subscribe 어노테이션으로, Flux 는 Provider 와 Alert 리소스로 구성한다
   3. 둘 다 Prometheus Alertmanager 에만 의존하며 자체 알림 기능이 없다
   4. 둘 다 Slack 웹훅 URL 을 ConfigMap 에 적으면 모든 앱에 자동으로 알림이 간다