[Golden Kubestronaut] CGOA 실전 연습 문제 80제 - Certified GitOps Associate

A) 운영팀만 접근할 수 있는 중앙 데이터베이스 B) Git 저장소에 저장된 선언적 설정이 시스템의 유일한 진실 원천 C) Kubernetes API 서버에 저장된 현재 클러스터 상태 D) CI/CD 파이프라인의 최종 빌드 아티팩트

정답: B

설명: GitOps에서 Single Source of Truth는 Git 저장소에 저장된 선언적 설정 파일을 의미합니다. 모든 인프라와 애플리케이션 상태는 Git에서 관리되며, 이것이 시스템이 도달해야 할 원하는 상태(Desired State)의 유일한 기준점입니다.

A) Deviation B) Drift C) Delta D) Divergence

정답: B

설명: Drift(드리프트)는 Git 저장소에 정의된 Desired State(원하는 상태)와 실제 실행 중인 클러스터의 Actual State(실제 상태) 간의 차이를 나타내는 GitOps 핵심 용어입니다.

A) 시스템이 도달해야 할 최종 상태를 기술한다 B) 상태에 도달하기 위한 단계별 명령을 기술한다 C) 수동으로 각 리소스를 순서대로 생성한다 D) 스크립트를 통해 절차적으로 인프라를 구성한다

정답: A

설명: 선언적 접근 방식은 "무엇(What)"을 원하는지 기술합니다. 반면 명령적(Imperative) 접근 방식은 "어떻게(How)" 도달할지를 단계별로 기술합니다. GitOps는 선언적 방식을 핵심 원칙으로 사용합니다.

A) Kubernetes YAML 매니페스트로 Deployment를 정의 B) kubectl create deployment nginx --image=nginx 명령 실행 C) Helm 차트로 애플리케이션 패키지를 정의 D) Kustomize 오버레이로 환경별 설정을 관리

정답: B

설명: kubectl create 명령은 리소스를 직접 생성하는 명령적 접근입니다. YAML 파일로 정의한 뒤 kubectl apply하는 것이 선언적 접근이며, Helm과 Kustomize도 선언적 도구입니다.

A) 선언적 (Declarative) B) 버전 관리 및 불변 (Versioned and Immutable) C) 수동 승인 후 적용 (Manual Approval Required) D) 지속적 조정 (Continuously Reconciled)

정답: C

설명: OpenGitOps의 4가지 원칙은 (1) Declarative, (2) Versioned and Immutable, (3) Pulled Automatically, (4) Continuously Reconciled입니다. 수동 승인은 워크플로우에 추가할 수 있지만 핵심 원칙은 아닙니다.

A) Git 저장소의 브랜치를 병합하는 과정 B) 원하는 상태와 실제 상태를 비교하여 일치시키는 과정 C) CI 파이프라인에서 테스트를 실행하는 과정 D) 컨테이너 이미지를 빌드하고 레지스트리에 푸시하는 과정

정답: B

설명: Reconciliation(조정)은 GitOps 에이전트가 Git에 정의된 원하는 상태와 클러스터의 실제 상태를 주기적으로 비교하고, 차이가 있으면 실제 상태를 원하는 상태로 수렴시키는 핵심 메커니즘입니다.

A) 새로운 애플리케이션을 처음 배포할 때 B) 누군가 kubectl edit으로 클러스터에서 직접 리소스를 수정했을 때 C) Git에 새로운 커밋이 푸시되었을 때 D) CI 파이프라인이 새 이미지를 빌드했을 때

정답: B

설명: Drift Detection은 Git에 정의된 상태와 클러스터의 실제 상태가 다를 때 이를 감지하는 기능입니다. 대표적으로 누군가 kubectl 등으로 클러스터에 직접 변경을 가한 경우 드리프트가 발생합니다.

A) 컨테이너 이미지를 저장하는 레지스트리 B) 인프라와 애플리케이션의 원하는 상태를 저장하는 선언적 저장소 C) CI/CD 파이프라인의 실행 로그를 저장하는 곳 D) 모니터링 메트릭을 수집하는 데이터 소스

정답: B

설명: GitOps에서 Git 저장소는 인프라와 애플리케이션의 원하는 상태를 선언적으로 저장하는 Single Source of Truth 역할을 합니다.

A) 애플리케이션의 런타임 데이터를 저장하는 데이터베이스 B) 원하는 상태의 선언을 저장하는 버전 관리 시스템 C) 클러스터 이벤트를 저장하는 로그 시스템 D) 시크릿을 암호화하여 저장하는 볼트 시스템

정답: B

설명: GitOps에서 State Store는 시스템의 원하는 상태(Desired State)를 선언적으로 저장하는 버전 관리 시스템입니다. Git이 가장 대표적인 State Store이며, 불변 이력과 감사 추적을 제공합니다.

A) 개발자에게 코드 리뷰 알림을 보내는 것 B) 실제 상태가 원하는 상태에서 벗어났을 때 감지하고 알리는 것 C) CI 파이프라인의 테스트 결과를 보고하는 것 D) Git 커밋에 대한 자동 코멘트를 추가하는 것

정답: B

설명: Feedback Loop은 GitOps 에이전트가 실제 클러스터 상태를 관찰하고 원하는 상태와의 차이를 감지하여 운영자에게 알리는 메커니즘입니다. 이를 통해 드리프트 발생 시 즉각 대응이 가능합니다.

A) 인프라가 한번 배포되면 절대 변경할 수 없다 B) 변경이 필요하면 기존 인프라를 수정하지 않고 새로 교체한다 C) 인프라의 모든 설정이 하드코딩되어 있다 D) 물리 서버에서만 가능한 배포 방식이다

정답: B

설명: Immutable Infrastructure는 기존 인프라를 수정(mutate)하지 않고, 새로운 버전을 배포하여 교체하는 패턴입니다. 이를 통해 구성 드리프트를 방지하고 롤백을 용이하게 합니다.

A) 컨테이너 이미지 빌드 속도 최적화 B) 인프라와 애플리케이션 배포의 일관성, 감사 가능성, 자동화 C) 소스 코드 컴파일 시간 단축 D) 네트워크 대역폭 최적화

정답: B

설명: GitOps는 인프라와 애플리케이션 배포를 Git 기반의 워크플로우로 통합하여 일관성(Consistency), 감사 가능성(Auditability), 자동화(Automation)를 보장하는 것을 목표로 합니다.

A) 코드를 컴파일하고 테스트를 실행 B) Git 저장소의 상태를 클러스터에 적용하고 드리프트를 교정 C) 개발자의 코드 리뷰를 자동화 D) 컨테이너 이미지를 빌드하고 푸시

정답: B

설명: GitOps의 Software Agent(ArgoCD, Flux 등)는 Git 저장소에 선언된 원하는 상태를 클러스터에 적용하고, 지속적으로 드리프트를 감지하여 교정하는 역할을 합니다.

A) GitOps는 모니터링 도구를 대체한다 B) 실제 상태를 관찰하여 원하는 상태와 비교하는 데 필수적이다 C) 로그 수집과 메트릭 분석만 의미한다 D) CI/CD 파이프라인 성능 측정에만 사용된다

정답: B

설명: GitOps에서 Observability는 클러스터의 실제 상태를 관찰하고, 원하는 상태와의 차이를 파악하는 데 핵심 역할을 합니다. 드리프트 감지와 자동 교정의 기반이 됩니다.

A) 현재 클러스터에서 실행 중인 모든 리소스의 상태 B) Git 저장소에 선언적으로 정의된 시스템이 도달해야 할 목표 상태 C) 운영팀이 수동으로 설정한 서버 구성 D) 모니터링 대시보드에 표시된 메트릭 값

정답: B

설명: Desired State는 Git 저장소에 선언적으로 정의된 시스템의 목표 상태입니다. GitOps 에이전트는 이 상태를 기준으로 클러스터를 지속 조정합니다.

A) 둘은 완전히 별개의 개념이다 B) Configuration as Code는 GitOps의 전제 조건이며, 모든 설정을 코드로 관리한다 C) GitOps는 Configuration as Code를 대체하는 새로운 방법론이다 D) Configuration as Code는 애플리케이션 코드에만 적용된다

정답: B

설명: Configuration as Code는 인프라와 애플리케이션 설정을 코드(YAML, JSON, HCL 등)로 관리하는 것으로, GitOps를 실현하기 위한 전제 조건입니다. 이를 통해 Git 버전 관리와 자동화가 가능해집니다.

A) CI 서버가 클러스터에 직접 배포 명령을 보낸다 B) 클러스터 내부의 에이전트가 Git 저장소에서 변경 사항을 가져와 적용한다 C) 개발자가 kubectl로 직접 리소스를 배포한다 D) 외부 스크립트가 SSH로 서버에 접속하여 배포한다

정답: B

설명: Pull 모델에서는 클러스터 내부에서 실행되는 에이전트(ArgoCD, Flux)가 주기적으로 Git 저장소를 확인하고 변경 사항을 클러스터에 적용합니다. 외부에서 클러스터에 직접 접근할 필요가 없어 보안상 유리합니다.

A) Git 저장소에 대한 읽기 권한이 필요하다 B) CI/CD 시스템이 클러스터에 대한 직접 접근 권한(credentials)을 보유해야 한다 C) 컨테이너 이미지 레지스트리 접근이 필요하다 D) 코드 리뷰 프로세스가 복잡해진다

정답: B

설명: Push 모델에서는 Jenkins, GitHub Actions 등 CI/CD 시스템이 클러스터에 직접 접근하기 위한 kubeconfig나 ServiceAccount 토큰 등의 자격 증명을 보유해야 합니다. 이는 보안상 공격 표면을 넓히는 단점입니다.

A) 클러스터에서 누군가 직접 수정한 Deployment의 replica 수 변경 B) Git 저장소에 새로 커밋된 ConfigMap 변경 C) 개발자 로컬 머신에서 테스트 중인 미커밋 코드 변경 D) Git 저장소에 푸시된 새로운 Helm 차트 버전

정답: C

설명: Reconciliation Loop은 Git 저장소에 커밋된 상태와 클러스터의 실제 상태를 비교합니다. 개발자 로컬 머신에서 아직 커밋되지 않은 변경 사항은 Git에 존재하지 않으므로 감지 대상이 아닙니다.

A) 서버가 물리적 장애에서 자동으로 복구되는 것 B) 실제 상태가 원하는 상태와 달라지면 자동으로 원하는 상태로 복원하는 것 C) 애플리케이션 코드의 버그를 자동으로 수정하는 것 D) 네트워크 장애를 자동으로 우회하는 것

정답: B

설명: Self-Healing은 GitOps 에이전트가 드리프트를 감지했을 때 자동으로 Git에 정의된 원하는 상태로 복원하는 메커니즘입니다. 예를 들어 누군가 수동으로 replica 수를 변경하면 에이전트가 이를 감지하고 Git의 값으로 되돌립니다.

A) 모든 환경이 단일 브랜치에서 관리된다 B) 각 환경(dev, staging, prod)에 대응하는 별도의 브랜치가 존재한다 C) 브랜치 없이 태그만 사용한다 D) feature 브랜치에서 직접 프로덕션에 배포한다

정답: B

설명: Environment per Branch 패턴에서는 main, staging, production 등 각 환경에 대응하는 브랜치를 두고, 해당 브랜치에 머지하면 GitOps 에이전트가 자동으로 해당 환경에 배포합니다.

A) kubectl로 이전 버전의 이미지를 직접 설정 B) Git에서 이전 커밋으로 revert하여 새 커밋을 생성 C) 클러스터의 etcd 백업을 복원 D) CI/CD 파이프라인을 수동으로 재실행

정답: B

설명: GitOps에서 롤백은 Git에서 이전 커밋으로 revert하는 것이 권장됩니다. 이렇게 하면 변경 이력이 보존되고, GitOps 에이전트가 자동으로 이전 상태로 클러스터를 조정합니다.

A) 장기 실행 브랜치가 많아져 병합 충돌이 줄어든다 B) 짧은 수명의 브랜치와 빈번한 통합으로 빠른 피드백과 배포가 가능하다 C) 코드 리뷰 없이 직접 main 브랜치에 커밋할 수 있다 D) 여러 환경을 하나의 브랜치로만 관리할 수 있다

정답: B

설명: Trunk-Based Development는 짧은 수명의 feature 브랜치를 사용하고 자주 main에 통합하는 방식입니다. GitOps와 결합하면 빈번한 배포와 빠른 피드백 루프를 실현할 수 있습니다.

A) 자동으로 컨테이너 이미지를 빌드한다 B) 변경 사항에 대한 리뷰, 승인, 감사 추적을 제공한다 C) 클러스터에 직접 배포를 실행한다 D) 테스트 환경을 자동으로 프로비저닝한다

정답: B

설명: Pull Request는 GitOps 워크플로우에서 변경 사항에 대한 코드 리뷰, 팀 승인, 자동화된 검증(CI), 그리고 변경 이력의 감사 추적을 제공하는 핵심 게이트입니다.

A) Git 저장소의 용량 제한 때문에 B) 애플리케이션 소스 코드와 배포 설정의 변경 주기와 권한이 다르기 때문에 C) Git이 바이너리 파일을 잘 처리하지 못하기 때문에 D) CI/CD 파이프라인의 속도를 높이기 위해

정답: B

설명: 애플리케이션 소스 코드와 배포 설정(manifest)은 변경 주기, 접근 권한, 리뷰 프로세스가 다릅니다. 이를 분리하면 각각 독립적으로 관리하고 RBAC을 적용할 수 있습니다.

A) 배포 속도를 높이기 위해 B) 동일한 선언적 상태를 여러 번 적용해도 결과가 동일함을 보장하기 위해 C) Git 커밋 메시지의 일관성을 유지하기 위해 D) 컨테이너 이미지의 크기를 줄이기 위해

정답: B

설명: 멱등성은 동일한 작업을 여러 번 수행해도 결과가 동일한 속성입니다. GitOps에서 reconciliation loop이 반복적으로 상태를 적용하므로, 매번 동일한 결과를 보장하는 멱등성이 필수적입니다.

A) 차이가 없으며 동일한 개념이다 B) CI/CD는 이벤트 기반으로 트리거되고, Continuous Reconciliation은 지속적으로 상태를 비교 조정한다 C) CI/CD만이 자동화를 제공한다 D) Continuous Reconciliation은 빌드 단계만 포함한다

정답: B

설명: CI/CD는 커밋이나 머지 같은 이벤트에 트리거되어 빌드-테스트-배포를 수행합니다. Continuous Reconciliation은 이벤트와 관계없이 지속적으로 원하는 상태와 실제 상태를 비교하고 조정합니다.

A) 별도의 감사 로그 시스템을 구축했기 때문에 B) 모든 변경이 Git 커밋으로 기록되어 누가, 언제, 무엇을 변경했는지 추적 가능하기 때문에 C) Kubernetes 이벤트가 영구 저장되기 때문에 D) CI/CD 파이프라인 로그가 보관되기 때문에

정답: B

설명: GitOps에서 모든 인프라 변경은 Git 커밋으로 이루어지므로, 커밋 이력이 자연스럽게 감사 추적 역할을 합니다. 커밋자, 시간, 변경 내용, PR 리뷰 기록이 모두 보존됩니다.

A) 모든 팀이 하나의 저장소와 네임스페이스를 공유 B) 팀별 저장소와 네임스페이스를 분리하고, RBAC으로 접근을 제한 C) 각 팀이 독립적인 Kubernetes 클러스터를 운영 D) GitOps를 사용하지 않고 수동 배포

정답: B

설명: Multi-tenancy 환경에서는 팀별 Git 저장소와 네임스페이스를 분리하고, ArgoCD의 AppProject나 Flux의 Tenant 기능으로 RBAC을 적용하여 격리를 보장합니다.

A) 동일한 YAML을 모든 환경에 복사-붙여넣기 B) Pull Request를 통해 변경 사항을 dev에서 staging, staging에서 prod로 순차 승격 C) kubectl로 각 환경에 수동 배포 D) 환경별로 완전히 다른 매니페스트를 작성

정답: B

설명: Environment Promotion은 Pull Request 워크플로우를 통해 변경 사항을 dev에서 staging, staging에서 production으로 순차적으로 승격하는 패턴입니다. 각 단계에서 리뷰와 자동 테스트를 수행합니다.

A) Git 저장소 접근 제한 시간 B) 동기화 작업이 완료되기까지의 최대 허용 시간 C) PR 리뷰 대기 시간 제한 D) 이미지 빌드 타임아웃

정답: B

설명: Reconciliation Timeout은 동기화 작업이 완료되기까지 허용되는 최대 시간입니다. 이 시간 내에 리소스가 정상 상태에 도달하지 못하면 동기화 실패로 처리됩니다.

A) IaC는 GitOps와 무관한 개념이다 B) IaC는 GitOps의 기반이 되며, 인프라를 코드로 정의하여 Git에서 관리한다 C) GitOps는 IaC를 완전히 대체한다 D) IaC는 클라우드 환경에서만 사용 가능하다

정답: B

설명: Infrastructure as Code는 인프라를 코드로 정의하는 방법론으로, GitOps의 기반입니다. IaC로 정의된 인프라를 Git에 저장하고, GitOps 에이전트가 이를 자동으로 적용합니다.

A) 클러스터에 직접 배포를 실행한다 B) Git 저장소의 변경을 에이전트에 즉시 알려 빠른 동기화를 트리거한다 C) 컨테이너 이미지를 빌드한다 D) 보안 스캔을 실행한다

정답: B

설명: Webhook은 Git 저장소에 변경이 발생하면 GitOps 에이전트(ArgoCD, Flux)에 즉시 알림을 보내 폴링 간격을 기다리지 않고 빠르게 동기화를 시작할 수 있게 합니다.

A) 여러 Git 브랜치를 하나로 합치는 것 B) 실제 상태가 원하는 상태로 수렴하여 일치하는 것 C) 여러 마이크로서비스가 하나의 모놀리스로 통합되는 것 D) 분산 시스템이 하나의 데이터센터로 집중되는 것

정답: B

설명: Convergence는 GitOps 에이전트의 reconciliation을 통해 클러스터의 실제 상태가 Git에 정의된 원하는 상태로 점진적으로 수렴하여 최종적으로 일치하는 것을 의미합니다.

A) Pull 모델이 더 빠르기 때문에 B) 클러스터 자격 증명을 외부 CI/CD 시스템에 노출할 필요가 없기 때문에 C) Pull 모델은 암호화를 사용하기 때문에 D) Push 모델은 Git을 사용하지 않기 때문에

정답: B

설명: Pull 모델에서는 클러스터 내부의 에이전트가 Git을 읽어와 적용하므로, 클러스터의 자격 증명(kubeconfig, token)을 외부 시스템(Jenkins, GitHub Actions 등)에 공유할 필요가 없습니다. 이는 공격 표면을 줄입니다.

A) 사용하는 프로그래밍 언어가 다르다 B) Declarative는 최종 상태를 정의하고, Procedural은 도달 단계를 정의한다 C) Declarative가 항상 더 빠르다 D) Procedural이 항상 더 안전하다

정답: B

설명: Declarative Configuration은 "시스템이 어떤 상태여야 하는가"를 정의하고, Procedural Configuration은 "어떤 단계를 실행해야 하는가"를 정의합니다. GitOps는 선언적 방식을 사용합니다.

A) 관련이 없다 B) Observability를 통해 실제 상태를 파악하여 Reconciliation의 기반 데이터를 제공한다 C) Observability가 Reconciliation을 대체한다 D) 둘 다 로그 분석에만 사용된다

정답: B

설명: Observability는 클러스터의 실제 상태를 파악하는 기능을 제공합니다. GitOps 에이전트는 이 정보를 기반으로 원하는 상태와의 차이를 감지하고 Reconciliation을 수행합니다.

A) 모든 변경이 즉시 적용된다 B) 시간이 지나면 클러스터 상태가 Git에 정의된 상태와 최종적으로 일치하게 된다 C) 데이터베이스의 트랜잭션 일관성 D) 네트워크 지연이 없는 상태

정답: B

설명: GitOps에서 Eventual Consistency는 Git에 변경이 커밋된 후 즉시 적용되지 않을 수 있지만, reconciliation loop을 통해 최종적으로 클러스터가 원하는 상태에 도달한다는 것을 의미합니다.

A) 환경별 Git 저장소 분리 B) 환경별 브랜치 분리 C) 환경별 디렉토리 분리 (Kustomize overlays) D) 모든 환경의 시크릿을 하나의 파일에 평문으로 저장

정답: D

설명: 모든 환경의 시크릿을 하나의 파일에 평문으로 저장하는 것은 보안상 매우 위험하며, GitOps의 환경 분리 원칙에도 위배됩니다. 환경 분리는 저장소, 브랜치, 또는 디렉토리 수준에서 구현합니다.

A) 드리프트 발생 시 관리자에게 이메일만 보낸다 B) 드리프트를 감지하면 자동으로 Git에 정의된 상태로 클러스터를 복원한다 C) 드리프트가 발생하면 클러스터를 완전히 재생성한다 D) 드리프트 발생 시 Git 저장소를 클러스터 상태로 업데이트한다

정답: B

설명: Automated Drift Remediation은 GitOps 에이전트가 드리프트를 감지했을 때 자동으로 Git에 정의된 원하는 상태로 클러스터를 복원하는 기능입니다. Git이 항상 진실의 원천이므로 클러스터를 Git에 맞추는 것이 올바른 방향입니다.

A) Git 저장소를 클론하고 매니페스트를 생성한다 B) 실행 중인 애플리케이션의 상태를 모니터링하고 원하는 상태와 비교한다 C) 사용자 인증을 처리한다 D) 웹 UI를 제공한다

정답: B

설명: Application Controller는 ArgoCD의 핵심 컴포넌트로, Kubernetes 클러스터에서 실행 중인 애플리케이션의 상태를 지속적으로 모니터링하고 Git에 정의된 원하는 상태와 비교합니다.

A) 클러스터의 리소스 상태를 캐싱한다 B) Git 저장소를 클론하고 Helm, Kustomize 등으로 Kubernetes 매니페스트를 생성한다 C) RBAC 정책을 관리한다 D) 알림을 외부 시스템에 전달한다

정답: B

설명: Repository Server(repo-server)는 Git 저장소를 클론하고, 경로에 있는 매니페스트를 Helm, Kustomize, plain YAML, 또는 Config Management Plugin 등을 사용하여 최종 Kubernetes 리소스로 렌더링합니다.

A) 사용자 세션과 매니페스트 캐시를 저장한다 B) Git 저장소의 백업을 유지한다 C) 컨테이너 이미지를 캐싱한다 D) SSL 인증서를 관리한다

정답: A

설명: ArgoCD에서 Redis는 매니페스트 생성 결과의 캐싱과 사용자 세션 데이터를 저장합니다. 이를 통해 Repository Server의 부하를 줄이고 응답 속도를 향상시킵니다.

A) Git 저장소에 대한 접근 권한을 관리한다 B) SSO(Single Sign-On)를 위한 OIDC/SAML/LDAP 인증을 제공한다 C) Kubernetes 리소스의 상태를 확인한다 D) 매니페스트를 렌더링한다

정답: B

설명: Dex는 ArgoCD에 통합된 OIDC(OpenID Connect) Identity Provider로, SAML, LDAP, GitHub, Google 등 다양한 외부 인증 시스템과의 SSO를 지원합니다.

A) GitRepository B) HelmRepository C) OCIRepository D) DockerRepository

정답: D

설명: Flux의 source-controller는 GitRepository, HelmRepository, OCIRepository, Bucket 등의 소스 유형을 지원합니다. DockerRepository는 Flux에서 사용하는 리소스 타입이 아닙니다.

A) Helm 차트를 배포한다 B) Kustomize 오버레이를 적용하고 Kubernetes 리소스를 클러스터에 배포한다 C) Git 저장소에서 소스를 가져온다 D) 외부 시스템에 알림을 보낸다

정답: B

설명: kustomize-controller는 source-controller가 가져온 소스에 Kustomize 오버레이를 적용하여 최종 매니페스트를 생성하고 클러스터에 배포합니다. plain YAML도 처리할 수 있습니다.

A) HelmChart B) HelmRelease C) HelmDeployment D) HelmApplication

정답: B

설명: Flux의 helm-controller는 HelmRelease CRD를 사용하여 Helm 차트의 릴리스를 선언적으로 관리합니다. HelmRelease에서 차트 소스, 값(values), 의존성 등을 정의합니다.

A) 클러스터 내부의 Pod 간 통신을 관리한다 B) 외부 시스템(Slack, Teams, Webhook 등)에 이벤트 알림을 전달한다 C) DNS 기록을 업데이트한다 D) 인증서를 자동 갱신한다

정답: B

설명: notification-controller는 Flux 이벤트(동기화 성공/실패, 드리프트 감지 등)를 Slack, Microsoft Teams, Webhook 등 외부 시스템에 알림으로 전달합니다.

A) ArgoCD 서버에 오류가 발생했다 B) Git에 정의된 상태와 클러스터의 실제 상태가 다르다 C) 네트워크 연결이 끊겼다 D) 인증 토큰이 만료되었다

정답: B

설명: OutOfSync는 Git 저장소에 정의된 원하는 상태와 클러스터에서 실행 중인 실제 상태 간에 차이가 있음을 나타냅니다. 수동 또는 자동 Sync를 통해 일치시킬 수 있습니다.

A) 모든 Pod가 정상 실행 중 B) 일부 리소스가 정상이 아닌 상태(예: Pod CrashLoopBackOff) C) Git 저장소에 접근할 수 없음 D) ArgoCD UI에 로그인 오류 발생

정답: B

설명: Health Status가 Degraded인 경우 애플리케이션의 일부 리소스가 비정상 상태임을 나타냅니다. 예를 들어 Pod가 CrashLoopBackOff이거나 Deployment의 replica가 부족한 경우 해당됩니다.

A) 컨테이너 런타임을 관리한다 B) Kubernetes 애플리케이션을 패키지로 템플릿화하고 배포한다 C) 네트워크 정책을 관리한다 D) 클러스터 인증을 처리한다

정답: B

설명: Helm은 Kubernetes의 패키지 매니저로, 차트(Chart)라는 패키지 형태로 Kubernetes 리소스를 템플릿화하고 values를 통해 커스터마이징하여 배포합니다.

A) 템플릿 엔진을 사용하여 YAML을 생성한다 B) 베이스 매니페스트에 패치와 오버레이를 적용하여 환경별 설정을 생성한다 C) 바이너리 패키지로 애플리케이션을 배포한다 D) 컨테이너 이미지를 빌드한다

정답: B

설명: Kustomize는 템플릿 없이(template-free) 베이스 매니페스트에 패치(patches)와 오버레이(overlays)를 적용하여 환경별 커스터마이징을 수행합니다. kustomization.yaml 파일에서 변형을 정의합니다.

A) 매니페스트 렌더링을 자동화한다 B) Git 저장소에 변경이 감지되면 자동으로 클러스터에 동기화한다 C) 이미지 태그를 자동으로 업데이트한다 D) PR을 자동으로 병합한다

정답: B

설명: Auto-Sync를 활성화하면 ArgoCD가 Git 저장소에서 변경을 감지했을 때 수동 개입 없이 자동으로 클러스터에 동기화합니다. 비활성화 시 수동으로 Sync 버튼을 클릭하거나 CLI를 사용해야 합니다.

A) 오래된 Git 브랜치를 삭제한다 B) Git에서 제거된 리소스를 클러스터에서도 자동으로 삭제한다 C) 사용하지 않는 컨테이너 이미지를 정리한다 D) 만료된 인증서를 제거한다

정답: B

설명: Prune은 Git 저장소에서 리소스 정의가 제거되었을 때, 클러스터에 남아있는 해당 리소스를 자동으로 삭제하는 옵션입니다. Auto-Sync와 함께 사용하면 Git의 상태와 클러스터를 완전히 일치시킬 수 있습니다.

A) 프로젝트의 소스 코드를 관리한다 B) 애플리케이션이 배포할 수 있는 소스 저장소, 대상 클러스터, 네임스페이스를 제한한다 C) CI/CD 파이프라인을 정의한다 D) 모니터링 대시보드를 구성한다

정답: B

설명: AppProject는 ArgoCD의 RBAC 단위로, 해당 프로젝트에 속한 Application이 접근할 수 있는 Git 저장소, 대상 클러스터, 네임스페이스, 생성 가능한 리소스 종류 등을 제한합니다.

A) Flux CLI 플래그로 전역 설정 B) 각 리소스(GitRepository, Kustomization 등)의 spec.interval 필드로 개별 설정 C) Kubernetes ConfigMap으로 설정 D) 환경 변수로 설정

정답: B

설명: Flux에서는 각 리소스(GitRepository, Kustomization, HelmRelease 등)의 spec.interval 필드에서 개별적으로 reconciliation 주기를 설정합니다. 이를 통해 리소스별로 다른 주기를 적용할 수 있습니다.

A) argocd app deploy APP_NAME B) argocd app sync APP_NAME C) argocd app apply APP_NAME D) argocd app push APP_NAME

정답: B

설명: argocd app sync APP_NAME 명령으로 특정 애플리케이션을 Git 저장소의 최신 상태와 동기화할 수 있습니다.

A) ArgoCD 자체가 장애에서 자동 복구한다 B) 클러스터에서 수동 변경이 발생하면 자동으로 Git의 상태로 되돌린다 C) Git 저장소의 충돌을 자동으로 해결한다 D) 만료된 시크릿을 자동으로 갱신한다

정답: B

설명: Self-Heal은 Auto-Sync의 하위 옵션으로, 클러스터에서 수동 변경(kubectl edit 등)이 감지되면 자동으로 Git에 정의된 상태로 되돌리는 기능입니다. 드리프트를 즉시 교정합니다.

A) Kubernetes 클러스터를 처음부터 설치한다 B) Flux 컴포넌트를 클러스터에 설치하고, Git 저장소에 Flux 설정을 커밋한다 C) Helm 차트 저장소를 초기화한다 D) 컨테이너 레지스트리를 설정한다

정답: B

설명: Flux Bootstrap은 Flux 컨트롤러들을 클러스터에 설치하고, Git 저장소에 Flux 설정 파일(gotk-components.yaml 등)을 커밋합니다. 이후 Flux는 이 저장소를 통해 스스로를 관리합니다.

A) 동일한 프로그래밍 언어로 작성되었다 B) 둘 다 CNCF 프로젝트이며, Pull 기반 GitOps 에이전트이다 C) 동일한 CRD를 사용한다 D) 동일한 웹 UI를 제공한다

정답: B

설명: ArgoCD와 Flux 모두 CNCF Graduated 프로젝트이며, Pull 기반 GitOps 모델을 구현한 에이전트입니다. 둘 다 Go 언어로 작성되었지만 아키텍처와 CRD, UI 등은 다릅니다.

A) RBAC 정책을 관리한다 B) 기본 지원되지 않는 도구(jsonnet, cue 등)로 매니페스트를 생성한다 C) 클러스터 네트워크를 구성한다 D) 사용자 계정을 관리한다

정답: B

설명: Config Management Plugin(CMP)은 ArgoCD가 기본적으로 지원하지 않는 매니페스트 생성 도구(Jsonnet, CUE, KCL 등)를 플러그인 형태로 추가하여 사용할 수 있게 합니다.

A) Sync 완료 후 정리 작업을 실행한다 B) 실제 동기화 작업 이전에 데이터베이스 마이그레이션 등의 사전 작업을 실행한다 C) Sync 실패 시 알림을 보낸다 D) Git 저장소를 사전 검증한다

정답: B

설명: PreSync Hook은 실제 동기화(Sync) 이전에 실행되는 리소스(Job, Pod 등)입니다. 데이터베이스 스키마 마이그레이션, 설정 검증 등 동기화 전에 필요한 사전 작업에 사용됩니다.

A) 차이가 없으며 동일하다 B) Strategic merge patch는 부분 덮어쓰기, JSON 6902는 명시적인 add/remove/replace 연산을 지정한다 C) JSON 6902가 항상 더 빠르다 D) Strategic merge patch는 Helm에서만 사용한다

정답: B

설명: Strategic merge patch는 기존 리소스에 부분적으로 필드를 덮어쓰는 방식이고, JSON 6902 patch는 add, remove, replace, move, copy 등의 명시적 연산을 경로로 지정합니다.

A) Label과 Finalizer B) Annotation과 Label C) ConfigMap과 Secret D) CRD와 Webhook

정답: B

설명: ArgoCD는 Annotation 방식(기본값)과 Label 방식으로 자신이 관리하는 리소스를 추적합니다. Annotation 방식은 argocd.argoproj.io/tracking-id를, Label 방식은 app.kubernetes.io/instance를 사용합니다.

A) 하나의 애플리케이션을 여러 클러스터에 배포 B) 루트 Application이 하위 Application들을 선언적으로 관리하여 대규모 배포를 구조화 C) 단일 Git 저장소에서 모든 애플리케이션을 관리 D) 애플리케이션 간의 네트워크 통신을 설정

정답: B

설명: App-of-Apps 패턴에서는 루트(부모) Application이 하위(자식) Application 리소스들을 포함하고, ArgoCD가 이를 재귀적으로 동기화합니다. 이를 통해 대규모 마이크로서비스 배포를 체계적으로 관리합니다.

A) 새로운 Kubernetes 클러스터를 생성한다 B) ArgoCD에 등록된 클러스터 목록을 기반으로 각 클러스터에 Application을 자동 생성한다 C) 클러스터의 리소스 사용량을 모니터링한다 D) 클러스터 인증서를 관리한다

정답: B

설명: Cluster Generator는 ArgoCD에 등록된 클러스터 목록을 순회하며, 각 클러스터에 대해 Application을 자동으로 생성합니다. 새 클러스터가 등록되면 자동으로 애플리케이션이 생성됩니다.

A) Git 커밋 이력을 기반으로 Application을 생성한다 B) Git 저장소의 디렉토리 구조를 스캔하여 각 디렉토리에 대응하는 Application을 자동 생성한다 C) Git 브랜치별로 Application을 생성한다 D) Git 태그를 기반으로 Application 버전을 관리한다

정답: B

설명: Git Generator - Directory는 Git 저장소의 지정 경로 아래 디렉토리를 스캔하여, 각 디렉토리에 대응하는 Application을 자동 생성합니다. 새 디렉토리가 추가되면 자동으로 Application이 생성됩니다.

A) 행렬 연산으로 리소스를 최적화한다 B) 두 개의 Generator를 결합하여 조합(카테시안 곱)으로 Application을 생성한다 C) 매니페스트의 문법을 검증한다 D) 클러스터 간 로드 밸런싱을 수행한다

정답: B

설명: Matrix Generator는 두 개의 하위 Generator를 조합하여 카테시안 곱(Cartesian product)으로 Application을 생성합니다. 예를 들어 Cluster Generator와 Git Generator를 결합하면 (클러스터 x 디렉토리)의 모든 조합에 대해 Application을 만듭니다.

A) 각 클러스터에 독립적인 ArgoCD를 설치 B) 허브(Hub) 클러스터의 ArgoCD가 여러 스포크(Spoke) 클러스터를 관리 C) 모든 클러스터가 하나의 Git 브랜치를 공유 D) 클러스터 간 직접 API 통신으로 동기화

정답: B

설명: Hub-Spoke 모델에서 중앙 허브 클러스터의 ArgoCD가 여러 스포크 클러스터를 관리합니다. ArgoCD에 원격 클러스터를 등록하면 해당 클러스터로 Application을 배포할 수 있습니다.

A) Git에서 직접 트래픽 비율을 수정 B) Argo Rollouts 또는 Flagger를 사용하여 단계적으로 트래픽을 전환 C) 모든 Pod를 동시에 새 버전으로 교체 D) Blue-Green 배포만 지원

정답: B

설명: Canary Deployment를 GitOps로 구현할 때는 Argo Rollouts이나 Flagger 같은 Progressive Delivery 도구를 사용합니다. 이들은 트래픽 비율을 단계적으로 조절하며 메트릭을 분석하여 자동 승격/롤백을 수행합니다.

A) Kubernetes Secret을 Base64로만 인코딩한다 B) 공개키로 시크릿을 암호화하여 Git에 안전하게 저장하고, 클러스터 내 컨트롤러가 비밀키로 복호화한다 C) 시크릿을 외부 볼트에 저장하고 참조만 Git에 보관한다 D) 시크릿 파일을 압축하여 Git에 저장한다

정답: B

설명: Sealed Secrets는 비대칭 암호화를 사용합니다. 공개키(public key)로 시크릿을 암호화하여 SealedSecret 리소스를 만들어 Git에 안전하게 저장하고, 클러스터의 Sealed Secrets Controller가 비밀키(private key)로 복호화하여 일반 Secret으로 변환합니다.

A) 시크릿을 Git 저장소에 암호화하여 저장한다 B) 외부 시크릿 관리 시스템(Vault, AWS SM 등)에서 시크릿을 가져와 Kubernetes Secret으로 동기화한다 C) Kubernetes Secret을 외부 시스템으로 내보낸다 D) 시크릿 값을 환경 변수로 주입한다

정답: B

설명: External Secrets Operator는 ExternalSecret CRD를 통해 외부 시크릿 관리 시스템(HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager 등)에서 시크릿을 가져와 Kubernetes Secret으로 자동 동기화합니다.

A) SOPS가 클러스터에서 시크릿을 직접 관리한다 B) SOPS로 YAML/JSON의 value를 암호화하여 Git에 저장하고, CI/CD 또는 GitOps 도구에서 복호화한다 C) SOPS가 Kubernetes API를 대체한다 D) SOPS로 컨테이너 이미지를 암호화한다

정답: B

설명: SOPS는 YAML이나 JSON 파일의 값(value)만 선택적으로 암호화하여 Git에 안전하게 저장합니다. 키(key)는 평문으로 유지되어 리뷰가 가능하며, Flux의 Kustomize Controller는 SOPS 복호화를 네이티브로 지원합니다.

A) 장점: 단일 저장소에서 모든 앱을 관리하여 일관성 확보 / 단점: 대규모 시 권한 관리 복잡 B) 장점: 팀별 완전한 격리 / 단점: 저장소 간 의존성 관리 어려움 C) Monorepo는 GitOps에 적합하지 않다 D) 장단점이 없으며 모든 상황에서 최적이다

정답: A

설명: Monorepo는 모든 애플리케이션 배포 설정을 단일 저장소에서 관리합니다. 장점은 일관성과 단순한 의존성 관리이고, 단점은 대규모 조직에서 세밀한 RBAC 적용과 CI/CD 파이프라인 관리가 복잡해지는 것입니다.

A) PR을 자동으로 병합한다 B) 열려있는 Pull Request마다 임시 프리뷰 환경을 자동 생성한다 C) PR의 코드 리뷰를 자동화한다 D) PR에 보안 스캔 결과를 추가한다

정답: B

설명: PullRequest Generator는 GitHub, GitLab 등의 열려있는 PR을 감지하여 각 PR에 대응하는 임시 Application(프리뷰 환경)을 자동 생성합니다. PR이 닫히면 해당 환경도 자동 삭제됩니다.

A) ArgoCD Notifications 또는 Flux notification-controller B) Kubernetes Event만으로 충분하다 C) 별도의 cron job으로 구현해야 한다 D) 모니터링 도구(Prometheus)만 사용한다

정답: A

설명: ArgoCD Notifications(또는 argocd-notifications-controller)와 Flux의 notification-controller를 사용하여 드리프트 감지, 동기화 상태 변경 등의 이벤트를 Slack, Teams, PagerDuty 등으로 알림을 보낼 수 있습니다.

A) 단일 환경만 필요하다 B) 두 환경(Blue, Green)의 리소스가 필요하며, 트래픽 전환 메커니즘이 필수적이다 C) 롤백이 불가능하다 D) 데이터베이스 마이그레이션이 자동으로 처리된다

정답: B

설명: Blue-Green 배포에서는 현재 버전(Blue)과 새 버전(Green) 두 환경을 동시에 운영하므로 두 배의 리소스가 필요합니다. Service나 Ingress를 통한 트래픽 전환 메커니즘이 필수적이며, Git에서 이를 선언적으로 관리합니다.

A) Git 브랜치를 병합할 때 B) 여러 Generator의 결과를 공통 키로 합쳐 특정 조합에만 오버라이드를 적용할 때 C) 여러 Helm 차트를 합칠 때 D) 매니페스트를 하나의 파일로 합칠 때

정답: B

설명: Merge Generator는 여러 Generator의 결과를 공통 키 필드를 기준으로 병합합니다. 기본 Generator로 전체 목록을 생성한 후, 보조 Generator로 특정 항목에만 추가 파라미터를 오버라이드할 때 유용합니다.

A) 시크릿을 Git에 평문으로 저장해도 된다 B) 시크릿은 암호화하거나 외부 참조만 Git에 저장하여, 평문 시크릿이 Git에 노출되지 않도록 한다 C) 시크릿은 항상 환경 변수로만 관리한다 D) 시크릿 관리는 GitOps의 범위 밖이다

정답: B

설명: GitOps에서 시크릿은 절대 평문으로 Git에 저장하면 안 됩니다. Sealed Secrets으로 암호화하거나, External Secrets Operator로 외부 시크릿 저장소의 참조만 Git에 저장하는 것이 핵심 원칙입니다.

A) 즉시 ArgoCD를 프로덕션에 설치한다 B) 기존 인프라와 애플리케이션 설정을 선언적 코드로 전환하고, Git 저장소 전략을 수립한다 C) 모든 개발자에게 kubectl 접근 권한을 부여한다 D) 모니터링 시스템을 먼저 완전히 구축한다

정답: B

설명: GitOps를 도입하려면 먼저 기존 인프라와 애플리케이션 설정을 선언적 코드(IaC, Kubernetes manifests)로 전환하고, Git 저장소 구조(monorepo vs polyrepo), 브랜치 전략, 환경 관리 방안을 수립해야 합니다.