CGOA — GitOps 인증 어소시에이트 · 모의고사 · 퀴즈

CGOA 모의고사 A

LabHub 에서 이어서 보기

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

GitOps 용어에서 feedback loop 가 가리키는 것은?
1. 개발자가 코드 리뷰에서 남긴 의견이 다음 커밋에 반영되는 과정입니다
2. CI 파이프라인이 테스트 결과를 채팅 도구로 알려 주는 통합입니다
3. 실제 상태를 관측해 원하는 상태와 비교하고 그 차이를 다시 조정의 입력으로 넣는 순환입니다
4. 사용자 설문으로 포털 만족도를 모아 로드맵에 반영하는 절차입니다
선언적 기술(declarative description)에 해당하는 것은?
1. Deployment 매니페스트에 replicas 를 3 으로 적어 원하는 최종 상태를 기술합니다
2. `kubectl scale deploy web --replicas=3` 명령을 순서대로 실행합니다
3. 파드가 두 개면 하나를 더 만들라는 조건문을 셸 스크립트에 적습니다
4. Ansible 플레이북에 셸 태스크로 apply 명령을 나열합니다
조정 루프가 드리프트를 감지하려면 반드시 갖춰야 하는 조건은?
1. Git 저장소에 웹훅이 설정되어 있어야 합니다
2. 모든 매니페스트가 하나의 저장소 안에 모여 있어야 합니다
3. 배포 파이프라인이 마지막으로 성공한 시각을 기록해 두어야 합니다
4. 원하는 상태와 실제 상태를 이벤트와 무관하게 주기적으로 읽어 비교할 수 있어야 합니다
GitOps 용어에서 rollback 이 뜻하는 것은?
1. 장애가 난 파드를 삭제해 컨트롤러가 새 파드를 만들게 하는 것입니다
2. 상태 저장소를 이전에 검증된 리비전으로 되돌려 시스템이 그 상태로 수렴하게 하는 것입니다
3. 조정 에이전트를 잠시 멈춰 더 이상 변경이 적용되지 않게 하는 것입니다
4. 레지스트리에서 문제가 된 이미지 태그를 삭제하는 것입니다
OpenGitOps 가 쓰는 continuous 라는 말의 의미로 옳은 것은?
1. 변경이 커밋될 때마다 빠짐없이 동기화가 일어난다는 뜻입니다
2. 변경 이벤트가 없어도 조정이 계속 반복된다는 뜻이며, 배포 빈도와는 다른 개념입니다
3. 무중단 배포를 보장한다는 뜻으로 continuous deployment 와 같은 말입니다
4. 파이프라인이 항상 실행 중이어야 한다는 뜻입니다
상태 저장소(state store)가 갖춰야 할 성질로 보기 어려운 것은?
1. 변경 이력이 남고 특정 리비전을 다시 지목할 수 있어야 합니다
2. 누가 무엇을 승인했는지 나중에 감사할 수 있어야 합니다
3. 이미 만들어진 리비전이 나중에 조용히 바뀌지 않아야 합니다
4. 반드시 Git 이어야 하며 다른 저장 방식은 GitOps 로 인정되지 않습니다
'GitOps managed software system' 을 가장 정확히 설명한 것은?
1. 원하는 상태가 상태 저장소에 선언되어 있고 조정 루프가 그 상태를 계속 유지하는 대상 시스템 전체입니다
2. Argo CD 나 Flux 같은 조정 엔진 자체를 가리키는 말입니다
3. 매니페스트를 담고 있는 Git 저장소를 가리키는 말입니다
4. 쿠버네티스 클러스터만을 좁게 가리키는 말입니다
Helm 차트로 관리하는 애플리케이션에서 '원하는 상태' 에 해당하는 것은?
1. 차트 저장소에 올라간 패키지 파일 자체입니다
2. values 파일에 적힌 파라미터 값들만을 가리킵니다
3. 차트와 values 를 렌더한 결과로 나오는 최종 매니페스트입니다
4. 클러스터의 Helm 릴리스 기록에 저장된 내용입니다
state reconciliation 을 수행하는 주체와 방향을 옳게 짝지은 것은?
1. 소프트웨어 에이전트가 실제 상태를 원하는 상태 쪽으로 움직입니다
2. CI 러너가 원하는 상태를 실제 상태에 맞춰 갱신합니다
3. 운영자가 대시보드를 보고 손으로 두 상태를 맞춥니다
4. API 서버가 커밋을 직접 읽어 스스로 오브젝트를 만듭니다
조정 루프가 같은 리비전에 대해 몇 번을 돌아도 결과가 같아야 하는 성질을 부르는 이름은?
1. 원자성(atomicity)
2. 가역성(reversibility)
3. 멱등성(idempotency)
4. 지역성(locality)
조정 결과를 사람에게 되돌려 주는 피드백 경로가 끊겼을 때 가장 먼저 나타나는 문제는?
1. 원하는 상태가 저장소에 반영되지 않습니다
2. 동기화가 실패해도 아무도 모른 채 오래된 상태가 계속 서비스됩니다
3. 에이전트가 조정 루프를 멈추고 대기 상태로 들어갑니다
4. 저장소의 커밋 이력이 손상됩니다
OpenGitOps 문서가 제품명 대신 'software agent' 라는 말을 쓰는 이유는?
1. 두 제품이 아직 CNCF 졸업 프로젝트가 아니기 때문입니다
2. 에이전트가 반드시 클러스터 밖에서 동작해야 함을 강조하기 위해서입니다
3. 상표권 문제로 제품명을 문서에 적을 수 없기 때문입니다
4. GitOps 가 특정 제품이 아니라 원칙으로 정의되는 운영 모델임을 분명히 하기 위해서입니다
targetRevision 을 브랜치 이름 대신 커밋 해시로 바꾸면 가장 직접적으로 강화되는 원칙은?
1. Declarative
2. Pulled Automatically
3. Continuously Reconciled
4. Versioned and Immutable
데이터베이스 스키마 마이그레이션처럼 순서가 본질인 작업을 GitOps 흐름에 넣는 방법으로 가장 적절한 것은?
1. 마이그레이션만 CI 러너가 클러스터에 직접 실행하게 예외를 둡니다
2. Job 매니페스트를 선언해 두고 훅이나 단계 지정으로 실행 순서를 명시합니다
3. 선언형으로 표현할 수 없으므로 GitOps 관리 대상에서 제외합니다
4. 운영자가 배포 직전에 손으로 실행하고 결과를 문서에 남깁니다
자동 동기화는 켜고 자가 치유는 꺼 두었을 때 실제로 벌어지는 일은?
1. 새 커밋이 들어와도 동기화되지 않습니다
2. 드리프트는 즉시 되돌려지지만 새 커밋은 무시됩니다
3. 새 커밋은 자동으로 적용되지만 손으로 고친 드리프트는 그대로 남습니다
4. 동기화가 아예 동작하지 않고 항상 차이 있음으로 표시됩니다
조정 엔진을 대상 클러스터 밖의 관리 클러스터에 두는 구성도 'Pulled Automatically' 를 만족한다고 보는 근거는?
1. 관리 클러스터가 대상 클러스터와 같은 네트워크 안에 있기 때문입니다
2. 외부 조정기는 읽기 전용 자격증명만 사용하기 때문입니다
3. 원칙이 요구하는 것은 에이전트가 승인된 상태를 스스로 당겨 온다는 방향이지 에이전트의 위치가 아니기 때문입니다
4. 원칙에 위치 요건이 명시돼 있으나 실무에서는 예외로 인정하기 때문입니다
'Continuously Reconciled' 원칙이 만족되려면 필요한 것은?
1. 커밋마다 파이프라인이 실행되어야 합니다
2. 커밋 여부와 무관하게 실제 상태를 계속 관측하고 차이를 되돌려야 합니다
3. 배포 승인 절차가 자동화되어 있어야 합니다
4. 롤백이 한 번의 명령으로 가능해야 합니다
설정 저장소에서 이력을 강제로 다시 쓰는 관행이 훼손하는 것은?
1. 이미 배포된 리비전을 다시 지목할 수 없게 되어 불변성과 감사 추적이 함께 무너집니다
2. 에이전트의 폴링 주기가 길어져 수렴이 느려집니다
3. 매니페스트가 선언형에서 명령형으로 바뀝니다
4. 조정 루프가 실제 상태를 읽지 못하게 됩니다
저장소에서 매니페스트를 지웠는데 클러스터의 오브젝트가 그대로 남아 있습니다. 실질적으로 깨진 원칙은?
1. Declarative — 매니페스트가 선언형이 아니었습니다
2. Versioned and Immutable — 삭제 커밋이 이력에 남지 않았습니다
3. Pulled Automatically — 에이전트가 커밋을 가져오지 못했습니다
4. Continuously Reconciled — 실제 상태가 원하는 상태로 수렴하지 못했습니다
오토스케일러가 replicas 를 관리하는 Deployment 를 GitOps 로도 관리할 때 권장되는 처리는?
1. 오토스케일러를 제거하고 replicas 를 저장소에 고정합니다
2. 자가 치유를 꺼서 모든 종류의 드리프트를 무시합니다
3. 매니페스트에서 replicas 를 빼거나 그 필드를 비교 대상에서 제외한다고 선언합니다
4. 동기화 주기를 오토스케일러의 안정화 창보다 길게 늘립니다
GitOps 에서 '승인된 변경' 이라는 표현이 실무적으로 가리키는 것은?
1. 운영자가 배포 버튼을 눌러 승인한 작업입니다
2. 보안팀이 별도 시스템에서 결재한 요청입니다
3. 정해진 검토를 거쳐 기본 브랜치에 병합된 커밋입니다
4. 에이전트가 상태 점검을 통과시킨 배포입니다
평문 시크릿을 저장소에 넣지 않으면서도 네 원칙을 유지하려면 필요한 것은?
1. 시크릿만 CI 러너가 클러스터에 직접 생성하도록 예외를 둡니다
2. 시크릿을 담은 별도 저장소를 만들어 접근 권한만 제한합니다
3. 운영자가 클러스터에 손으로 만들고 문서에 기록해 둡니다
4. 암호화된 형태나 참조만 커밋하고 복호화 또는 조회는 클러스터 안에서 일어나게 합니다
폴링 주기를 3 분에서 30 분으로 늘렸을 때 원칙 관점에서 달라지는 것은?
1. 원칙 위반은 아니지만 드리프트가 방치되는 시간이 길어집니다
2. Continuously Reconciled 원칙을 명백히 위반하게 됩니다
3. Pulled Automatically 원칙이 push 모델로 바뀝니다
4. 이력이 남지 않게 되어 불변성 원칙이 깨집니다
운영자가 급하게 클러스터를 고쳤고 그 변경 자체는 옳았습니다. 원칙에 맞는 후속 조치는?
1. 에이전트의 비교 제외 목록에 해당 필드를 추가해 그대로 둡니다
2. 같은 내용을 설정 저장소에 커밋해 원하는 상태를 갱신합니다
3. 클러스터 상태를 덤프해 저장소에 자동으로 밀어 넣는 잡을 만듭니다
4. 해당 앱의 자동 동기화를 영구히 꺼 둡니다
'저장소에 없는 것은 클러스터에도 없어야 한다' 를 실제로 구현하는 기능은?
1. 삭제된 매니페스트에 해당하는 오브젝트를 정리하는 prune
2. 실패한 동기화를 다시 시도하는 retry
3. 적용 순서를 나누어 지정하는 sync wave
4. 차이를 계산해 보여 주는 diff
조정 엔진에 부여할 클러스터 권한을 정할 때 원칙과 보안을 함께 지키는 방법은?
1. 모든 네임스페이스에 최고 관리자 권한을 주어 동기화 실패를 없앱니다
2. 사람 운영자의 kubeconfig 를 그대로 재사용합니다
3. CI 러너의 토큰을 에이전트와 공유해 권한을 한곳으로 모읍니다
4. 앱이 실제로 다루는 네임스페이스와 리소스 종류로 권한을 좁힙니다
다음 중 네 원칙을 모두 만족하는 구성은?
1. 저장소에 매니페스트를 두고 야간 크론잡이 클러스터에 적용 명령을 실행합니다
2. 운영자가 관리 화면에서 매번 동기화 버튼을 눌러 배포합니다
3. 클러스터 안 컨트롤러가 저장소를 주기적으로 읽어 적용하고 드리프트를 되돌립니다
4. CI 가 패키지 도구로 릴리스를 올리고 그 결과를 저장소에 기록합니다
이미지를 다이제스트로 고정해 배포하는 것이 원칙 관점에서 주는 이득은?
1. 레지스트리 조회가 빨라져 조정 지연이 줄어듭니다
2. 같은 커밋이 언제 적용되어도 동일한 아티팩트를 가리켜 불변성이 아티팩트까지 확장됩니다
3. 이미지 서명 검증이 자동으로 활성화됩니다
4. 롤백할 때 저장소 이력을 되돌리지 않아도 됩니다
설정 저장소의 기본 브랜치에 직접 푸시를 허용하면 GitOps 관점에서 잃는 것은?
1. 에이전트가 변경을 감지하는 속도가 느려집니다
2. 매니페스트가 더 이상 선언형이 아니게 됩니다
3. 롤백에 필요한 커밋 이력이 사라집니다
4. 변경이 배포되기 전에 검토되는 지점이 사라져 승인 경계가 없어집니다
GitOps 를 도입해도 그대로 남는 위험으로 옳은 것은?
1. 손으로 고친 변경이 영구히 살아남습니다
2. 누가 언제 무엇을 바꿨는지 알 수 없습니다
3. 잘못된 선언이 병합되면 그 잘못이 정확하고 빠르게 전파됩니다
4. 배포 자격증명이 CI 러너에 그대로 남습니다
Infrastructure as Code 와 Configuration as Code 의 관계로 옳은 것은?
1. IaC 는 선언형이고 CaC 는 명령형이라는 점에서 갈립니다
2. IaC 는 인프라 자원의 생성을, CaC 는 그 위 시스템의 설정을 코드로 다루며 GitOps 는 둘 다에 적용될 수 있습니다
3. CaC 는 IaC 의 옛 이름이며 지금은 같은 뜻으로 씁니다
4. IaC 는 클라우드 전용이고 CaC 는 온프레미스 전용입니다
GitOps 가 DevOps 문화와 맺는 관계를 가장 정확히 말한 것은?
1. DevOps 가 지향하는 협업과 자동화를 배포와 운영 영역에서 구체적으로 구현하는 운영 모델입니다
2. DevOps 를 대체해 그 자리를 차지하는 새로운 조직 운영 모델입니다
3. DevOps 문화와는 무관하게 정의된 순수한 기술 규격입니다
4. 개발 조직과 운영 조직을 하나로 합치는 조직 개편 방법론입니다
GitOps 파이프라인에 DevSecOps 를 접목할 때 효과가 가장 큰 지점은?
1. 배포가 끝난 뒤 런타임 스캐너로 취약점을 찾아 티켓을 만듭니다
2. 병합 전 단계에서 매니페스트 정책 검사와 이미지 취약점 검사를 병합 조건으로 겁니다
3. 분기마다 감사팀이 클러스터를 직접 점검합니다
4. 운영자가 배포 직전에 보안 체크리스트를 확인합니다
GitOps 를 도입한 팀에서 CI 파이프라인의 최종 산출물로 알맞은 것은?
1. 대상 클러스터에 이미 적용된 릴리스입니다
2. 테스트 결과를 정리한 리포트입니다
3. 레지스트리에 올라간 이미지와 설정 저장소에 올린 참조 갱신 커밋입니다
4. 운영자에게 보내는 배포 승인 요청입니다
코드로 만든 클라우드 자원을 GitOps 원칙에 맞게 다루려면 필요한 것은?
1. 계획과 적용을 자동화된 조정 주체가 수행하고 상태 차이를 계속 확인하게 합니다
2. 운영자가 로컬에서 적용하고 결과를 나중에 커밋합니다
3. 상태 파일을 저장소에 함께 커밋해 이력으로 삼습니다
4. 인프라는 GitOps 대상이 아니므로 별도 절차로 분리합니다
GitOps 저장소에 코드 소유자 규칙과 브랜치 보호를 두는 목적은?
1. 조정 주기를 단축해 드리프트를 더 빨리 잡기 위해서입니다
2. 저장소 용량을 줄여 클론 속도를 높이기 위해서입니다
3. 에이전트가 읽을 디렉터리 범위를 제한하기 위해서입니다
4. 배포 권한을 저장소 권한으로 옮겨 변경마다 필요한 검토자를 강제하기 위해서입니다
GitOps 도입 후에도 관측 체계가 필요한 이유로 가장 정확한 것은?
1. 저장소와 클러스터가 일치해도 그 선언이 사용자에게 좋은 결과를 주는지는 따로 확인해야 하기 때문입니다
2. 에이전트가 조정 실패를 어디에도 기록하지 않기 때문입니다
3. 저장소 이력만으로는 누가 배포했는지 알 수 없기 때문입니다
4. 폴링 주기가 길면 커밋이 유실될 수 있기 때문입니다
Continuous Delivery 와 Continuous Deployment 의 차이로 옳은 것은?
1. Delivery 는 컨테이너 환경에서, Deployment 는 가상 머신 환경에서 쓰는 말입니다
2. Delivery 는 언제든 배포 가능한 상태를 유지하는 것이고, Deployment 는 그 배포까지 자동으로 이어지는 것입니다
3. Delivery 는 자동 배포를 포함하고 Deployment 는 수동 승인을 포함합니다
4. 두 용어는 같은 뜻이며 지역에 따라 표현만 다릅니다
정책을 코드로 관리해 GitOps 흐름에 넣었을 때 얻는 가장 큰 이점은?
1. 정책 위반을 런타임에서만 탐지할 수 있게 됩니다
2. 정책 문서를 별도 위키로 관리할 수 있게 됩니다
3. 클러스터 관리자 권한 없이도 정책을 우회할 수 있게 됩니다
4. 정책 자체가 검토와 버전 관리를 거치고 병합 전 검사로 실행될 수 있습니다
GitOps 를 플랫폼 엔지니어링 관점에서 볼 때 개발자에게 제공되는 인터페이스는?
1. 클러스터 접근용 kubeconfig 파일입니다
2. 배포 담당자에게 보내는 요청 티켓입니다
3. 설정 저장소에 올리는 풀 리퀘스트입니다
4. 조정 엔진의 관리자 콘솔입니다
블루/그린 배포의 특징으로 옳은 것은?
1. 트래픽을 비율로 조금씩 옮기며 지표를 관찰합니다
2. 새 버전을 기존 파드에 순차적으로 교체해 넣습니다
3. 일부 사용자에게만 기능 플래그로 노출합니다
4. 같은 규모의 새 환경을 준비해 두고 트래픽을 한 번에 전환합니다
카나리 배포에서 자동 롤백 판단의 근거로 가장 적절한 것은?
1. 카나리로 향한 트래픽의 오류율과 지연 지표를 기준선과 비교합니다
2. 새 파드가 실행 상태에 도달했는지 확인합니다
3. 배포 후 경과 시간이 정해진 값을 넘었는지 확인합니다
4. 이미지 태그가 정상적으로 갱신되었는지 확인합니다
점진적 전달이 단순한 롤링 업데이트와 구분되는 핵심은?
1. 파드를 한 번에 하나씩만 교체한다는 점입니다
2. 배포 도구가 아니라 CI 가 전환을 수행한다는 점입니다
3. 전환 단계마다 관측 지표를 판정에 사용해 진행이나 중단을 결정한다는 점입니다
4. 이전 버전 파드를 즉시 삭제하지 않는다는 점입니다
이벤트 기반 동기화와 폴링 기반 동기화를 함께 쓰는 구성의 성격으로 옳은 것은?
1. 웹훅이 들어오면 폴링이 중단되므로 두 방식은 배타적입니다
2. 웹훅은 지연을 줄이고 폴링은 웹훅 유실에 대한 안전망이 되어 서로 보완합니다
3. 두 방식을 함께 쓰면 중복 적용이 일어나 상태가 깨집니다
4. 폴링은 pull 이고 웹훅은 push 라서 원칙상 함께 쓸 수 없습니다
여러 클러스터를 한 곳에서 관리하는 외부 조정기 구조의 대표적 단점은?
1. 관리 클러스터가 모든 대상 클러스터의 자격증명을 모아 갖게 되어 침해 시 영향 범위가 커집니다
2. 대상 클러스터마다 에이전트를 따로 설치하고 각각 업그레이드해야 합니다
3. 클러스터별로 서로 다른 매니페스트를 사용할 수 없습니다
4. 폴링 주기를 클러스터마다 다르게 설정할 수 없습니다
여러 팀이 하나의 설정 저장소를 함께 쓸 때 가장 먼저 마련해야 하는 것은?
1. 팀마다 별도의 조정 엔진 인스턴스를 띄우는 것입니다
2. 디렉터리 단위 소유권과 그에 맞춘 검토 규칙입니다
3. 커밋 메시지 형식을 통일하는 규약입니다
4. 저장소 크기를 줄이기 위한 얕은 클론 설정입니다
여러 클러스터에 같은 애플리케이션을 배포하면서 클러스터마다 값만 다르게 하려 합니다. 가장 적절한 구조는?
1. 클러스터 수만큼 저장소를 복제해 각각 수정합니다
2. 매니페스트를 하나만 두고 배포한 뒤 값을 손으로 고칩니다
3. 클러스터마다 다른 브랜치를 만들어 값을 나눕니다
4. 공통 베이스를 두고 클러스터별 오버레이나 값 파일로 차이만 표현합니다
인터넷 인바운드가 막힌 사설 클러스터에 GitOps 를 적용할 때 pull 모델이 유리한 이유는?
1. 에이전트가 안에서 밖으로 나가 저장소를 읽으므로 인바운드 통로를 열 필요가 없습니다
2. 에이전트가 상태 저장소 없이도 동작할 수 있기 때문입니다
3. pull 모델은 암호화를 쓰지 않아 방화벽 예외가 필요 없기 때문입니다
4. pull 모델에서는 어떤 자격증명도 필요하지 않기 때문입니다
카나리 도중 자동 롤백이 일어났는데 설정 저장소는 여전히 새 버전을 가리키고 있습니다. 이때 벌어질 일은?
1. 조정 엔진이 롤백 결과를 저장소에 자동으로 커밋합니다
2. 다음 조정에서 다시 새 버전으로 밀려 배포가 되풀이될 수 있으므로 저장소도 되돌려야 합니다
3. 배포 컨트롤러가 해당 앱의 동기화를 영구히 차단합니다
4. 새 버전이 이미 실패했으므로 조정 엔진은 더 이상 시도하지 않습니다
기능 플래그와 배포 전략의 관계로 옳은 것은?
1. 기능 플래그를 쓰면 배포 전략이 필요 없어집니다
2. 기능 플래그는 배포 도구가 트래픽을 나누는 방식의 다른 이름입니다
3. 기능 플래그는 롤백을 불가능하게 만들어 GitOps 와 맞지 않습니다
4. 배포와 기능 공개를 분리해 이미 배포된 코드의 노출 여부를 따로 제어합니다
여러 앱이 같은 사용자 정의 리소스 정의에 의존할 때 배포 순서를 안전하게 다루는 방법은?
1. 모든 앱을 하나의 매니페스트 파일로 합칩니다
2. 앱마다 조정 주기를 다르게 설정해 시차를 만듭니다
3. 정의를 먼저 적용하는 단계로 분리하고 나머지를 그 뒤 단계에 둡니다
4. 실패한 앱을 사람이 다시 동기화할 때까지 기다립니다
한 클러스터를 여러 팀이 나눠 쓸 때 GitOps 관점의 테넌시 경계를 만드는 방법은?
1. 팀별로 대상 네임스페이스와 허용 리소스, 소스 저장소를 제한하는 프로젝트 경계를 둡니다
2. 팀마다 조정 주기와 재시도 횟수를 다르게 설정합니다
3. 팀별로 커밋 서명 키를 다르게 발급합니다
4. 팀마다 별도의 이미지 레지스트리를 사용합니다
Kustomize 와 Helm 의 차이로 옳은 것은?
1. Kustomize 는 기존 YAML 에 패치를 겹쳐 렌더하고, Helm 은 템플릿과 값으로 매니페스트를 생성합니다
2. Kustomize 는 템플릿 언어를 쓰고 Helm 은 패치 병합을 사용합니다
3. Kustomize 는 클러스터 안에서만, Helm 은 클러스터 밖에서만 동작합니다
4. 둘은 같은 도구의 다른 배포판이며 기능 차이가 없습니다
Flux 에서 저장소를 읽어 오는 일과 매니페스트를 적용하는 일을 서로 다른 컨트롤러가 맡는 이유는?
1. 컨트롤러마다 요구하는 쿠버네티스 버전이 다르기 때문입니다
2. 적용 컨트롤러가 Git 프로토콜을 해석하지 못하기 때문입니다
3. 소스 획득과 조정을 나누어 한 소스를 여러 대상이 공유하고 실패도 따로 다루기 위해서입니다
4. 컨트롤러마다 라이선스가 달라 함께 배포할 수 없기 때문입니다
조정 엔진의 알림 기능을 붙이는 목적으로 가장 적절한 것은?
1. 알림이 도착해야 조정 루프가 다음 주기를 시작합니다
2. 알림 채널이 원하는 상태를 보관하는 두 번째 저장소가 됩니다
3. 알림을 통해 운영자가 클러스터를 직접 고칠 수 있게 됩니다
4. 동기화 실패나 상태 저하를 사람이 아는 경로를 만들어 피드백 루프를 닫습니다
레지스트리에 새 이미지가 올라왔을 때 설정 저장소를 갱신하는 자동화 도구가 원칙을 지키려면?
1. 클러스터의 Deployment 이미지 필드를 직접 수정해야 합니다
2. 새 태그나 다이제스트를 설정 저장소에 커밋해 조정 엔진이 그것을 읽게 해야 합니다
3. 조정 엔진의 캐시를 지워 강제로 다시 받게 해야 합니다
4. 레지스트리를 원하는 상태의 출처로 삼아야 합니다
Git 이 아닌 OCI 아티팩트 저장소를 상태 저장소로 쓰는 구성에 대한 설명으로 옳은 것은?
1. 원칙이 Git 만을 허용하므로 이 구성은 GitOps 가 아닙니다
2. OCI 저장소는 이력이 없어 롤백이 불가능합니다
3. 버전이 매겨지고 불변이며 에이전트가 당겨 갈 수 있으면 원칙상 문제가 없습니다
4. OCI 저장소를 쓰면 조정 루프가 필요 없어집니다
조정 엔진이 내보내는 지표 중 배포 건전성을 보는 데 가장 직접적인 것은?
1. 앱별 동기화 상태와 마지막 성공 동기화 이후 경과 시간입니다
2. 설정 저장소의 총 커밋 수입니다
3. 컨트롤러 파드가 사용하는 이미지 태그입니다
4. 클러스터 노드의 디스크 사용량과 남은 용량입니다
템플릿을 렌더한 결과 매니페스트까지 저장소에 커밋해 두는 방식의 이점은?
1. 조정 엔진이 템플릿 도구를 지원하지 않아도 되므로 도구 선택 문제가 사라집니다
2. 풀 리퀘스트에서 실제로 적용될 YAML 의 차이를 그대로 검토할 수 있습니다
3. 저장소 용량이 줄어 클론이 빨라집니다
4. 값 파일을 더 이상 관리하지 않아도 됩니다
조정 엔진과 CI 도구를 연동할 때 권장되지 않는 구성은?
1. CI 가 이미지를 빌드하고 설정 저장소에 참조 갱신 커밋을 올립니다
2. CI 가 풀 리퀘스트에서 렌더 결과를 미리 보여 주는 검사를 실행합니다
3. CI 가 정책 검사와 스키마 검증을 병합 조건으로 실행합니다
4. CI 가 클러스터 자격증명을 들고 배포한 뒤 조정 엔진에 결과를 통보합니다