CNPA模擬試験A

선언형(declarative) 자원 관리와 명령형(imperative) 자원 관리를 가르는 핵심 차이는?

• 선언형은 YAML 을 쓰고 명령형은 JSON 을 쓴다
• 선언형은 원하는 상태를 기술하고 시스템이 도달 경로를 정하며, 명령형은 사람이 도달 절차를 하나씩 지시한다
• 선언형은 쿠버네티스에서만 쓸 수 있고 명령형은 어디서나 쓸 수 있다
• 선언형은 항상 명령형보다 실행이 빠르다

선언형으로 관리되는 워크로드에서 누군가 클러스터에 직접 접속해 레플리카 수를 바꿔 놓았습니다. 이 상태를 무엇이라고 부르며 시스템은 어떻게 다루어야 합니까?

• 드리프트(drift)라고 부르며, 조정 루프가 선언된 상태로 되돌리고 그 사실을 관측 가능하게 남겨야 한다
• 핫픽스라고 부르며, 다음 배포까지 그대로 두는 것이 정상이다
• 롤백이라고 부르며, 선언된 상태를 클러스터 값으로 갱신해야 한다
• 장애라고 부르며, 컨트롤러를 중지해 변경을 보존해야 한다

선언형 매니페스트가 갖추어야 할 멱등성(idempotency)의 의미로 옳은 것은?

• 같은 매니페스트를 여러 번 적용해도 결과 상태가 한 번 적용한 것과 같다
• 매니페스트를 적용할 때마다 리소스가 새로 생성된다
• 매니페스트에 적힌 순서대로만 리소스가 만들어진다
• 한 번 적용한 매니페스트는 다시 적용할 수 없다

선언형 접근이 오히려 어울리지 않는 작업으로 가장 적절한 것은?

• 여러 환경에 같은 애플리케이션 구성을 배포하는 일
• 네임스페이스별 자원 한도를 관리하는 일
• 일회성 데이터 백필처럼 순서와 실행 시점이 중요한 절차적 작업
• 인그레스 라우팅 규칙을 관리하는 일

플랫폼이 사용자에게 제공하는 추상화를 선언형 API 로 만들 때 얻는 운영상 이점으로 가장 정확한 것은?

• 사용자가 작성해야 하는 필드 수가 반드시 줄어든다
• 원하는 상태가 기록으로 남아 검토·감사·복원이 같은 대상 위에서 이루어진다
• 플랫폼 팀이 컨트롤러를 직접 작성할 필요가 없어진다
• 런타임 오류가 발생하지 않는다

DevOps 의 이른바 세 가지 방법 가운데 '피드백' 이 플랫폼에서 구현된 예로 가장 적절한 것은?

• 배포 파이프라인의 단계를 더 잘게 나눈다
• 플랫폼 팀이 매주 회고 회의를 연다
• 빌드 아티팩트를 오래 보관한다
• 설정 오류를 배포 시점이 아니라 개발자의 커밋 시점에 알려 준다

'왼쪽으로 옮긴다(shift left)' 를 플랫폼에서 실천할 때 흔히 저지르는 실패는?

• 검사를 앞으로 옮기기만 하고 개발자가 로컬에서 같은 검사를 돌릴 방법을 주지 않는다
• 검사를 앞으로 옮기면서 배포 직전 검사도 함께 유지한다
• 검사 실패 메시지에 수정 방법을 함께 적는다
• 검사 규칙을 코드로 관리해 버전을 남긴다

비난 없는 사후 분석(blameless postmortem)의 목적으로 가장 정확한 것은?

• 책임자를 특정하되 징계는 하지 않는 것
• 장애 기록을 남겨 감사에 대비하는 것
• 사람이 합리적으로 판단했는데도 사고가 나게 만든 시스템의 조건을 찾는 것
• 장애 시간을 줄여 SLO 를 보호하는 것

SRE 가 말하는 토일(toil)의 정의에 가장 부합하는 작업은?

• 새 기능의 설계 문서를 작성하는 일
• 장애 원인을 처음으로 분석하는 일
• 플랫폼의 다음 분기 로드맵을 정하는 일
• 요청이 올 때마다 사람이 같은 절차로 네임스페이스를 만들어 주는 일

개발·스테이징·운영으로 승격할 때 같은 컨테이너 이미지 다이제스트를 그대로 옮겨야 하는 이유는?

• 환경마다 다시 빌드하면 스테이징에서 검증한 것과 운영에 뜬 것이 다른 산출물이 될 수 있다
• 환경마다 다시 빌드하면 레지스트리 저장 공간이 늘어난다
• 다이제스트를 고정해야 이미지 풀 속도가 빨라진다
• 쿠버네티스가 태그로는 이미지를 가져오지 못한다

환경 패리티(environment parity)가 무너졌을 때 나타나는 전형적 증상은?

• 환경마다 빌드 시간이 달라져 파이프라인 소요 시간을 예측하기 어려워진다
• 스테이징에서는 통과한 변경이 운영에서만 실패하고, 원인 추적이 애플리케이션이 아니라 환경 차이로 흘러간다
• 환경 수만큼 이미지가 쌓여 레지스트리 저장 용량이 빠르게 증가한다
• 개발자가 로컬에서 운영과 같은 컨테이너를 실행하지 못하게 된다

풀 리퀘스트마다 임시(ephemeral) 미리보기 환경을 띄우는 방식의 가장 큰 이점은?

• 공유 스테이징 환경을 완전히 없앨 수 있다
• 운영 환경의 자원 사용량이 줄어든다
• 변경마다 격리된 검증 자리가 생겨 공유 환경을 서로 기다리지 않아도 된다
• 테스트 코드를 작성하지 않아도 된다

불변 인프라(immutable infrastructure)의 원칙에 맞는 운영 방식은?

• 실행 중인 인스턴스에 패치를 적용하고 재시작한다
• 구성 관리 도구로 실행 중인 서버의 설정을 수렴시킨다
• 장애 노드에 접속해 원인을 고친 뒤 계속 사용한다
• 새 이미지를 만들어 인스턴스를 교체하고 기존 인스턴스는 폐기한다

플랫폼이 배포 매니페스트에서 이미지 태그 latest 사용을 막아야 하는 가장 큰 이유는?

• 어떤 코드가 실행 중인지 특정할 수 없어 롤백과 사고 분석의 기준점이 사라진다
• 레지스트리가 latest 태그를 자동으로 삭제한다
• latest 는 이미지 풀 정책을 항상 Never 로 만든다
• latest 태그가 붙은 이미지는 서명할 수 없다

내부 개발자 플랫폼의 통합·배포 평면(Integration and Delivery Plane)이 담당하는 일은?

• 개발자가 요청을 입력하는 표면을 제공한다
• 소스에서 실행 가능한 산출물까지의 빌드·검증·배포 경로를 잇는다
• 클러스터와 데이터베이스 같은 실제 자원을 제공한다
• 메트릭과 로그를 수집해 보여 준다

플랫폼 기능을 직접 만들 것인가 기성 제품을 쓸 것인가를 판단할 때 가장 적절한 기준은?

• 그 기능이 조직의 차별화 요소인가, 아니면 어디서나 같은 방식으로 풀리는 문제인가
• 그 기능을 제공하는 제품이 오픈 소스인가 상용인가
• 플랫폼 팀 안에 그 기술을 이미 알고 있는 사람이 있는가
• 기성 제품의 연간 라이선스 비용이 담당 인력의 인건비보다 싼가

네임스페이스로 테넌트를 나누는 소프트 멀티테넌시의 한계로 가장 정확한 것은?

• 네임스페이스마다 별도의 API 서버가 필요해 비용이 늘어난다
• 네임스페이스 안에서는 RBAC 를 적용할 수 없다
• 노드 커널과 컨트롤 플레인을 공유하므로 커널 수준 탈출이나 클러스터 범위 자원의 충돌을 막지 못한다
• 네임스페이스가 다르면 서비스 간 통신이 아예 불가능하다

플랫폼이 제공하던 기능의 하위 호환을 깨야 할 때 취할 방식으로 가장 적절한 것은?

• 새 버전을 함께 제공하며 폐기 예고 기간과 이전 안내를 두고, 사용 현황을 근거로 종료 시점을 정한다
• 다음 배포에서 곧바로 교체하고 장애가 나면 개별 대응한다
• 예전 버전을 영구히 유지하고 새 버전은 선택 사항으로만 둔다
• 변경 사실을 릴리스 노트에만 적고 사용자 통지는 하지 않는다

플랫폼의 기능 목록을 정할 때 '역량(capability)' 단위로 정의하라는 조언의 뜻은?

• 설치된 도구 이름으로 목록을 만들라는 뜻이다
• '데이터베이스를 안전하게 갖춘다' 처럼 사용자가 얻는 결과로 정의하고 구현 도구는 뒤에 두라는 뜻이다
• 기능마다 담당자를 지정하라는 뜻이다
• 기능을 쿠버네티스 리소스 종류에 맞추어 나누라는 뜻이다

가장 얇은 실행 가능 플랫폼(thinnest viable platform)이라는 개념이 권하는 출발점은?

• 필요한 최소한으로 시작하되, 잘 정리된 문서 한 장이라도 그것이 도움이 된다면 플랫폼으로 친다
• 핵심 기능을 모두 갖춘 뒤에 한 번에 공개한다
• 가장 인기 있는 오픈 소스 도구를 먼저 전부 설치한다
• 개발자 포털부터 구축한 다음 기능을 붙인다

플랫폼 팀이 다음에 무엇을 만들지 정할 때 가장 신뢰할 만한 근거는?

• 업계에서 화제가 되는 신기술 목록
• 경영진이 요청한 기능 목록
• 플랫폼 팀 내부에서 만들고 싶은 것의 우선순위
• 사용자 인터뷰와 지원 요청 기록에서 반복적으로 확인되는 마찰 지점

플랫폼 팀이 사실상 티켓 창구로 되돌아갔음을 보여 주는 신호로 가장 뚜렷한 것은?

• 플랫폼 사용 팀의 수가 늘어나고 있다
• 새 기능 요청이 문서화된 절차로 접수되고 있다
• 플랫폼 팀의 업무 시간 대부분이 개별 팀의 요청을 대신 처리하는 데 쓰인다
• 플랫폼 팀이 온콜 순환 근무를 운영하고 있다

셀프서비스와 '무엇이든 할 수 있게 열어 두는 것' 의 차이로 가장 정확한 것은?

• 셀프서비스는 승인 절차를 반드시 포함한다
• 셀프서비스는 안전한 기본값과 가드레일 안에서 사용자가 스스로 끝까지 갈 수 있게 하는 것이다
• 셀프서비스는 읽기 권한만 개방하는 것이다
• 셀프서비스는 사용자가 직접 클러스터에 접속하게 하는 것이다

플랫폼을 처음 도입할 때 파일럿 팀을 고르는 기준으로 가장 적절한 것은?

• 조직에서 가장 규모가 큰 팀
• 가장 복잡한 레거시 시스템을 운영하는 팀
• 플랫폼 팀과 물리적으로 가까이 앉은 팀
• 겪는 마찰이 뚜렷하고 협력할 의지가 있으며 성공 사례가 다른 팀에 설득력을 갖는 팀

플랫폼의 사용자층이 신입 개발자와 숙련된 팀으로 나뉠 때 설계 방침으로 가장 적절한 것은?

• 숙련 팀의 요구에 맞추어 모든 설정 항목을 그대로 노출한다
• 신입 개발자에 맞추어 설정 항목을 최소한만 노출하고 나머지는 고정한다
• 안전한 기본값으로 바로 시작할 수 있게 하되, 필요한 팀은 더 낮은 계층으로 내려갈 경로를 열어 둔다
• 두 사용자층을 위해 서로 다른 플랫폼을 각각 구축하고 따로 운영한다

플랫폼 채택을 강제 규정으로 밀어붙였을 때 지표에서 벌어지는 일은?

• 사용률은 높게 나오지만 그 수치가 플랫폼의 유용성을 더 이상 설명하지 못한다
• 사용률과 만족도가 함께 높아진다
• 사용률이 낮게 유지되어 문제를 일찍 발견할 수 있다
• 사용률 지표를 더 이상 수집할 수 없게 된다

지속적 통합(Continuous Integration)의 정의에 가장 부합하는 실천은?

• CI 도구를 도입해 파이프라인을 구성해 두는 것
• 모든 개발자가 작업을 자주 공유 브랜치에 통합하고 그때마다 자동 빌드와 테스트로 검증하는 것
• 기능이 완성되면 코드 리뷰를 거쳐 병합하는 것
• 테스트 커버리지를 일정 수준 이상으로 유지하는 것

공유 브랜치의 빌드가 깨진 상태로 방치되면 생기는 가장 큰 문제는?

• 빌드 서버가 실패한 작업을 반복 실행하면서 자원 사용량이 늘어난다
• 실패한 실행이 집계에서 빠져 테스트 커버리지 수치가 떨어진다
• 이후 커밋의 검증 결과가 신뢰를 잃어, 팀 전체가 실패 신호를 무시하기 시작한다
• 실패한 빌드의 중간 산출물이 쌓여 아티팩트 저장소 용량이 부족해진다

빌드를 재현 가능하게(reproducible) 만들라는 요구가 플랫폼에서 갖는 의미는?

• 같은 커밋에서 언제 어디서 빌드해도 같은 산출물이 나와, 검증 결과를 산출물에 귀속시킬 수 있다
• 빌드 시간이 항상 일정하게 유지된다
• 빌드 캐시를 사용하지 않는다는 뜻이다
• 빌드를 항상 같은 빌드 서버에서 수행한다는 뜻이다

지속적 전달(Continuous Delivery)과 지속적 배포(Continuous Deployment)의 차이는?

• 전달은 카나리를 쓰고 배포는 블루 그린을 쓴다
• 전달은 스테이징까지만, 배포는 운영까지 자동화한다는 뜻이다
• 전달은 언제든 배포 가능한 상태로 유지하는 것이고, 배포는 그 릴리스를 사람의 승인 없이 자동으로 운영에 내보내는 것이다
• 둘은 같은 뜻이며 지역에 따라 다르게 부른다

GitOps 의 원칙 가운데 '지속적 조정(continuously reconciled)' 이 요구하는 것은?

• 선언된 상태가 실제 상태와 계속 대조되어 차이가 발견되면 자동으로 좁혀진다
• 커밋이 있을 때마다 파이프라인이 배포 명령을 실행한다
• 배포 이력이 Git 에 기록으로 남는다
• 모든 변경이 풀 리퀘스트를 거친다

요청 하나가 여러 서비스를 거치는 동안 어느 구간에서 지연이 생겼는지 알아내려 합니다. 가장 알맞은 신호는?

• 서비스별 CPU 사용률 메트릭
• 각 서비스의 애플리케이션 로그
• 쿠버네티스 이벤트 기록
• 요청 단위로 이어진 분산 트레이스

메트릭 라벨에 사용자 ID 나 요청 ID 같은 값을 넣으면 생기는 문제는?

• 메트릭 이름이 중복되어 수집이 실패한다
• 시계열 수가 값의 가짓수만큼 늘어나 저장과 질의 비용이 급격히 커진다
• 라벨 값이 로그로 전달되지 않는다
• 메트릭의 정밀도가 떨어진다

플랫폼이 OpenTelemetry 를 계측 표준으로 채택할 때 얻는 가장 큰 이점은?

• 관측 데이터의 저장 비용이 줄어든다
• 애플리케이션 코드를 수정하지 않고도 모든 신호가 수집된다
• 계측 방식을 백엔드와 분리해, 저장·분석 도구를 바꿔도 애플리케이션의 계측을 다시 하지 않아도 된다
• 메트릭과 로그와 트레이스가 자동으로 하나의 화면에 통합된다

플랫폼이 관측성을 골든 패스에 기본으로 끼워 넣어야 하는 이유로 가장 적절한 것은?

• 관측 도구 라이선스 비용을 아낄 수 있다
• 개발자가 관측성 개념을 배우지 않아도 되게 하기 위해서다
• 장애가 발생하지 않도록 예방하기 위해서다
• 팀마다 다르게 계측하면 서비스를 가로지르는 상관 분석이 불가능해지기 때문이다

에러 버짓을 거의 다 소진한 서비스에 대해 취할 조치로 가장 적절한 것은?

• SLO 목표치를 낮춰 버짓을 회복시킨다
• 신규 기능 배포 속도를 늦추고 신뢰성 개선 작업을 우선한다
• 알림 임계값을 완화해 경보 소음을 줄인다
• 해당 서비스의 SLI 수집을 잠시 중단한다

서비스 간 통신에 mTLS 를 적용할 때 단방향 TLS 에 비해 추가로 얻는 것은?

• 전송 구간 암호화
• 인증서 자동 갱신
• 요청 경로 단위의 접근 제어
• 호출하는 쪽의 신원까지 인증서로 검증하는 능력

네트워크 정책을 제로 트러스트 원칙에 맞게 도입하는 방식은?

• 네임스페이스마다 기본 거부를 두고 필요한 통신만 명시적으로 허용한다
• 모든 통신을 허용하고 위험한 대상만 차단 목록에 넣는다
• 인그레스만 제한하고 이그레스는 열어 둔다
• 운영 네임스페이스에만 정책을 적용한다

서비스 메시 도입을 검토할 때 가장 정직하게 따져야 할 비용은?

• 애플리케이션 코드를 메시 전용 SDK 로 재작성해야 한다는 점
• 메시를 쓰면 네트워크 정책을 더 이상 쓸 수 없다는 점
• 사이드카나 노드 단위 프록시가 지연·자원·운영 대상으로 추가되고, 장애 시 조사 범위가 한 겹 늘어난다는 점
• 메시가 트래픽을 암호화하면 관측 데이터를 수집할 수 없다는 점

같은 정책을 CI 단계와 어드미션 단계 양쪽에 두는 이유로 가장 정확한 것은?

• 정책 엔진의 부하를 두 곳으로 분산하기 위해서다
• CI 는 빠른 피드백을 주고 어드미션은 CI 를 우회한 경로까지 실제로 막기 때문이다
• CI 검사는 강제력이 있고 어드미션은 참고용이기 때문이다
• 어드미션 웹훅이 실패했을 때 CI 가 대신 차단하기 때문이다

검증(validating) 어드미션 정책과 변형(mutating) 어드미션 정책의 차이는?

• 검증은 네임스페이스 단위로, 변형은 클러스터 단위로만 적용된다
• 검증은 생성 요청에만, 변형은 갱신 요청에만 적용된다
• 검증은 동기적으로, 변형은 비동기적으로 실행된다
• 검증은 요청을 통과시키거나 거절하고, 변형은 저장 전에 요청 내용을 고쳐 넣는다

새로운 정책을 기존 클러스터에 도입할 때 권장되는 순서는?

• 먼저 감사 모드로 위반 현황을 파악하고, 경고 단계를 거친 뒤 차단으로 올린다
• 처음부터 차단으로 적용해 위반을 즉시 없앤다
• 운영 네임스페이스부터 차단을 적용하고 나중에 하위 환경으로 넓힌다
• 정책을 적용하지 않고 문서로만 안내한 뒤 위반 팀을 개별 지도한다

정책을 코드로 관리(policy as code)할 때 얻는 이점으로 가장 정확한 것은?

• 규칙이 코드로 고정되므로 정책 위반 자체가 발생하지 않게 된다
• 규칙이 저장소에 있으므로 별도의 정책 엔진 없이도 강제된다
• 정책 자체를 리뷰하고 테스트하고 버전으로 되돌릴 수 있어, 규칙의 변경이 코드 변경과 같은 절차를 밟는다
• 감사 담당자가 클러스터에 직접 접근하지 않고도 준수 여부를 확인할 수 있게 된다

테넌트 팀에 부여할 롤을 설계할 때 가장 위험한 선택은?

• 네임스페이스 안의 디플로이먼트와 서비스에 대한 편집 권한을 준다
• 파드 로그 조회 권한을 준다
• 네임스페이스 안의 컨피그맵 생성 권한을 준다
• 편의를 위해 리소스와 동사를 와일드카드로 열어 둔 클러스터롤을 바인딩한다

쿠버네티스 시크릿에 대한 설명으로 옳은 것은?

• 시크릿 값은 저장 시 자동으로 암호화되므로 별도 조치가 필요 없다
• 값이 base64 로 인코딩될 뿐이므로, 저장 시 암호화와 접근 권한 제한을 따로 갖추어야 한다
• 시크릿은 파드에 마운트할 수 없고 환경 변수로만 전달된다
• 시크릿은 네임스페이스 경계를 넘어 자동으로 공유된다

서비스 어카운트 토큰의 자동 마운트를 기본적으로 꺼 두라고 권하는 이유는?

• API 서버에 접근할 필요가 없는 파드까지 토큰을 갖게 되어, 침해 시 공격자가 곧바로 API 자격 증명을 얻기 때문이다
• 토큰 마운트가 파드 시작 시간을 크게 늘리기 때문이다
• 토큰이 마운트되면 네트워크 정책이 적용되지 않기 때문이다
• 토큰 파일이 컨테이너 이미지 크기를 키우기 때문이다

소프트웨어 공급망 보안에서 SBOM 이 하는 역할로 가장 정확한 것은?

• 빌드 결과물이 만들어진 뒤 변조되지 않았음을 서명으로 증명한다
• 빌드가 어떤 소스와 어떤 환경에서 수행되었는지를 증명한다
• 산출물에 어떤 구성 요소와 버전이 들어 있는지 목록으로 남겨, 새 취약점이 공개됐을 때 영향 범위를 즉시 찾게 해 준다
• 실행 중인 컨테이너의 이상 행위를 탐지해 침해 시도를 알린다

CI 파이프라인이 클라우드 자원에 접근할 때 장기 정적 액세스 키 대신 권장되는 방식은?

• 키를 암호화해 저장소에 커밋한다
• 키를 파이프라인 변수로 저장하고 분기마다 다른 값을 쓴다
• 키를 90일마다 사람이 수동으로 교체한다
• 워크로드 아이덴티티로 신원을 증명하고 실행마다 수명이 짧은 자격 증명을 발급받는다

파이프라인의 단계 순서를 정할 때 지켜야 할 원칙은?

• 가장 중요한 검사를 마지막에 배치해 최종 판단으로 삼는다
• 빠르고 실패 가능성이 높은 검사를 앞에 두어 잘못된 변경이 일찍 멈추게 한다
• 느린 검사를 앞에 두어 뒤 단계의 대기를 줄인다
• 단계를 나누지 않고 하나의 작업으로 묶어 실행 시간을 줄인다

파이프라인 실행 시간이 길어져 개발자들이 결과를 기다리지 않게 되었습니다. 가장 먼저 검토할 조치는?

• 실행 빈도를 줄여 하루 한 번만 파이프라인을 돌린다
• 느린 테스트를 삭제해 실행 시간을 줄인다
• 단계 병렬화와 의존성 캐시를 적용하고, 오래 걸리는 검사는 커밋 이후 단계로 옮긴다
• 빌드 서버를 늘리고 개발자에게 기다리도록 안내한다

플랫폼이 각 팀에 파이프라인 템플릿을 제공할 때 얻는 가장 큰 효과는?

• 팀별 파이프라인 실행 시간이 균일해진다
• 팀이 파이프라인 문법을 배우지 않아도 되므로 CI 도구를 자주 교체할 수 있다
• 파이프라인 관련 장애가 발생하지 않는다
• 보안 스캔과 서명 같은 필수 단계가 팀마다 다시 만들어지지 않고 한곳에서 갱신된다

사고 대응에서 사고 지휘자(incident commander)의 역할로 가장 정확한 것은?

• 기술적 조사를 직접 수행하지 않고, 역할을 배분하고 상황을 정리하며 의사 결정 지점을 관리한다
• 가장 숙련된 엔지니어로서 원인 분석을 직접 주도한다
• 고객 공지문을 작성하고 배포한다
• 사고 종료 후 책임 소재를 판단한다

공용 플랫폼이 만들어 내는 위험 가운데 사고 대응 설계에 가장 크게 반영해야 할 것은?

• 플랫폼 팀의 온콜 인원이 적다는 점
• 플랫폼 구성 요소 하나의 장애가 그 위에 올라탄 모든 팀의 장애가 된다는 점
• 플랫폼 사용자가 사고 대응 훈련을 받지 않았다는 점
• 플랫폼이 여러 클라우드에 걸쳐 있다는 점

운영 사고가 진행 중이고 직전 배포가 의심될 때 우선순위로 옳은 것은?

• 원인을 정확히 규명한 뒤 정확한 수정본을 배포한다
• 사용자 영향이 큰 기능부터 차례로 비활성화한다
• 다음 정기 배포 창까지 기다렸다가 함께 처리한다
• 먼저 직전 배포를 되돌려 영향을 멈추고, 원인 규명은 그다음에 한다

CI 와 CD 사이의 경계에서 '계약' 역할을 하는 것은?

• 파이프라인의 단계를 기술한 정의 파일
• 소스 저장소에 붙인 릴리스 태그
• 검증을 마치고 불변 식별자로 고정된 아티팩트
• 배포를 승인한 변경 관리 티켓

CI 작업이 클러스터 자격 증명을 들고 직접 배포까지 수행하는 방식(푸시 모델)의 약점은?

• 조정 방식에 비해 배포가 반영되는 속도가 눈에 띄게 느려진다
• CI 시스템이 여러 클러스터에 대한 강한 권한을 상시 보유하게 되고, 배포 후의 상태 유지는 아무도 책임지지 않는다
• CI 도구 안에서는 환경별 매니페스트를 생성할 수 없다
• 푸시 모델에서는 어떤 버전이 언제 배포되었는지 이력을 남길 수 없다

GitOps 의 풀(pull) 모델이 보안 측면에서 갖는 장점은?

• 저장소에 커밋할 수 있는 사람의 수를 줄일 수 있게 된다
• 클러스터와 저장소 사이의 네트워크 통신이 필요 없어진다
• 매니페스트에 시크릿을 평문으로 담아도 저장소가 안전해진다
• 클러스터 안의 에이전트가 저장소를 읽어 가므로, 외부 시스템에 클러스터 자격 증명을 넘기지 않아도 된다

애플리케이션 소스 저장소와 배포 매니페스트 저장소를 나누는 이유로 가장 적절한 것은?

• 매니페스트 저장소는 접근 권한을 아예 열어 둘 수 있기 때문이다
• 쿠버네티스가 소스 코드가 섞인 저장소를 동기화하지 못하기 때문이다
• 배포를 유발하는 커밋과 코드 변경 커밋이 섞이지 않아, 배포 이력과 승인 흐름을 따로 다룰 수 있기 때문이다
• 매니페스트를 별도 저장소에 두면 동기화 속도가 빨라지기 때문이다

GitOps 로 관리되는 클러스터에서 긴급하다는 이유로 클러스터를 직접 수정하면 벌어지는 일은?

• 조정 루프가 자동으로 그 변경을 저장소에 반영한다
• 다음 조정 주기에 변경이 되돌려지므로, 저장소에 반영하지 않으면 조치가 사라진다
• 해당 애플리케이션의 동기화가 영구히 중단된다
• 변경이 유지되고 저장소가 자동으로 잠긴다

환경별 차이를 환경마다 별도 브랜치를 두어 관리하는 방식의 문제는?

• 브랜치가 늘어날수록 저장소 크기와 클론 시간이 함께 커진다
• 브랜치에 놓인 매니페스트는 배포 전에 검증할 수 없다
• 조정 도구가 기본 브랜치 외의 브랜치를 추적하지 못한다
• 환경 간 병합 충돌이 반복되고, 어느 환경에 무엇이 반영되었는지가 커밋 그래프에 흩어져 알기 어려워진다

GitOps 환경에서 스테이징에서 운영으로 승격하는 동작으로 가장 적절한 것은?

• 스테이징에서 검증된 이미지 다이제스트를 운영 환경 매니페스트에 반영하는 커밋을 올린다
• 운영 클러스터에서 이미지 태그를 갱신하는 명령을 실행한다
• 운영 환경의 조정을 잠시 끄고 새 버전을 배포한 뒤 다시 켠다
• 스테이징 네임스페이스의 리소스를 운영 네임스페이스로 복사한다

쿠버네티스 컨트롤러가 '수준 기반(level-triggered)' 으로 동작한다는 말의 뜻은?

• 컨트롤러가 우선순위 수준에 따라 리소스를 처리한다는 뜻이다
• 변경 알림을 하나도 놓치지 않도록 이벤트를 큐에 저장한다는 뜻이다
• 변경 이벤트가 아니라 현재 상태 자체를 보고 원하는 상태와의 차이를 좁힌다는 뜻이다
• 일정 수준 이상의 차이가 났을 때만 조정을 수행한다는 뜻이다

커스텀 리소스에서 spec 과 status 의 역할 분리로 옳은 것은?

• spec 은 컨트롤러가 쓰고 status 는 사용자가 쓴다
• spec 은 사용자가 선언한 원하는 상태이고, status 는 컨트롤러가 기록하는 관측된 실제 상태다
• 둘 다 사용자가 작성하며 컨트롤러는 읽기만 한다
• status 는 사용자에게 보이지 않는 내부 필드다

조정 중 외부 API 호출이 실패했을 때 컨트롤러가 취해야 할 동작으로 가장 적절한 것은?

• 해당 리소스를 오류 상태로 표시하고 더 이상 처리하지 않는다
• 실패할 때까지 같은 호출을 즉시 반복한다
• 컨트롤러를 종료해 재시작 시 처음부터 다시 시도하게 한다
• 오류를 status 에 남기고 지수 백오프로 다시 큐에 넣어 재시도한다

플랫폼이 제공하는 커스텀 리소스에 OpenAPI 스키마 검증을 촘촘히 넣어야 하는 이유는?

• 잘못된 값이 저장되기 전에 API 서버가 거절해, 오류가 배포 이후가 아니라 제출 시점에 드러나기 때문이다
• 스키마가 있으면 컨트롤러를 작성하지 않아도 리소스가 동작하기 때문이다
• 스키마 검증이 있어야 커스텀 리소스를 네임스페이스 범위로 만들 수 있기 때문이다
• 스키마가 있으면 RBAC 규칙을 따로 작성하지 않아도 되기 때문이다

플랫폼이 제공하던 커스텀 리소스를 v1alpha1 에서 v1 로 올릴 때 사용자 영향을 줄이는 방식은?

• 새 버전만 남기고 기존 객체는 사용자가 다시 만들게 한다
• 두 버전을 서로 다른 CRD 이름으로 각각 등록한다
• 한 CRD 안에 두 버전을 함께 제공하고 저장 버전을 지정한 뒤, 필요하면 변환 웹훅으로 두 표현을 오가게 한다
• 새 버전 도입 전까지 조정 컨트롤러를 중지해 둔다

플랫폼 API 를 설계할 때 파드 스펙의 모든 필드를 그대로 노출하면 생기는 문제는?

• API 서버의 검증 비용이 지나치게 커진다
• 추상화가 사라져 사용자가 지던 인지 부하가 그대로 남고, 플랫폼이 내부 구현을 바꿀 여지도 없어진다
• 커스텀 리소스의 크기 제한을 초과한다
• 쿠버네티스가 중복된 필드 정의를 허용하지 않는다

데이터베이스나 버킷 같은 클라우드 자원을 쿠버네티스 커스텀 리소스로 프로비저닝할 때의 이점은?

• 클라우드 제공자의 요금이 낮아진다
• 인프라 자원에 대해서도 상태 드리프트가 발생하지 않는다
• 인프라 프로비저닝 속도가 전용 도구보다 빨라진다
• 애플리케이션과 인프라가 같은 선언 모델과 같은 조정·권한 체계 안에서 관리된다

커스텀 리소스로 관리하는 클라우드 자원을 다룰 때 반드시 정해 두어야 할 것은?

• 자원마다 별도의 클러스터를 둘 것인지 여부
• 커스텀 리소스를 삭제했을 때 실제 자원까지 삭제할 것인지, 남겨 둘 것인지에 대한 정책
• 자원 이름에 사용할 접두사 규칙
• 프로비저닝을 어느 시간대에 수행할 것인지

오퍼레이터 패턴을 한 문장으로 설명한 것으로 가장 정확한 것은?

• 애플리케이션 설치를 템플릿으로 묶어 배포하는 방식이다
• 클러스터 운영자에게 관리 권한을 위임하는 RBAC 설계 방식이다
• 특정 애플리케이션의 운영 지식을 컨트롤러 코드로 옮겨, 백업이나 장애 조치 같은 작업을 조정 루프가 수행하게 하는 방식이다
• 여러 클러스터를 하나의 컨트롤 플레인에서 다루는 연합 방식이다

어떤 미들웨어를 도입할 때 패키지 차트로 충분한지 오퍼레이터가 필요한지 판단하는 기준으로 가장 적절한 것은?

• 그 미들웨어가 디스크에 상태를 저장하는 종류인가
• 커뮤니티가 이미 오퍼레이터를 만들어 제공하고 있는가
• 설치해야 할 쿠버네티스 리소스의 개수가 많은가
• 설치 이후에도 백업·확장·버전 업그레이드 같은 지속적인 운영 판단이 필요한가

새 서비스를 만드는 화면에서 점진적 공개(progressive disclosure)를 적용한 예로 가장 적절한 것은?

• 기본 화면에는 이름과 팀과 언어만 묻고, 자원 크기나 스케일링 설정은 고급 항목으로 접어 둔다
• 모든 설정 항목을 한 화면에 펼쳐 두고 검색 기능을 제공한다
• 설정 항목을 여러 단계로 나누어 모두 순서대로 입력하게 한다
• 설정 항목을 없애고 플랫폼 팀이 대신 값을 정해 준다

서비스 스캐폴딩 템플릿이 개발자 경험에 기여하는 가장 큰 지점은?

• 코드 작성량이 줄어 개발 속도가 빨라진다
• 팀마다 다른 프레임워크를 쓰지 못하게 막을 수 있다
• 저장소 생성 시간이 단축된다
• 저장소·파이프라인·관측·소유자 정보가 처음부터 표준대로 연결된 상태로 시작한다

소프트웨어 카탈로그의 정보가 오래되지 않게 유지하는 방법으로 가장 효과적인 것은?

• 분기마다 팀에 카탈로그 갱신을 요청한다
• 카탈로그 메타데이터를 서비스 저장소 안에 두고 코드와 함께 변경·리뷰되게 한다
• 카탈로그 편집 권한을 플랫폼 팀으로 한정한다
• 카탈로그에 최종 수정일을 표시해 오래된 항목을 알아보게 한다

서비스 카탈로그를 화면뿐 아니라 API 로도 제공해야 하는 이유는?

• 화면보다 API 의 응답 속도가 빠르기 때문이다
• 카탈로그 데이터의 저장 비용이 줄어들기 때문이다
• 파이프라인·정책 검사·온콜 도구가 소유자와 의존성 정보를 자동으로 조회해 쓸 수 있기 때문이다
• API 가 있어야 카탈로그에 접근 권한을 걸 수 있기 때문이다

개발자 포털이 링크 모음집으로 전락하지 않으려면 무엇이 필요합니까?

• 포털에서 실제로 작업을 끝낼 수 있도록 아래 계층의 기능이 실행 가능한 형태로 연결되어 있어야 한다
• 포털의 디자인과 검색 기능을 개선해야 한다
• 모든 내부 도구의 링크를 빠짐없이 등록해야 한다
• 포털 접속을 전사 표준 시작 페이지로 지정해야 한다

개발자 경험을 포털 방문 수로만 측정할 때의 한계는?

• 방문 수는 수집이 어렵고 정확도가 낮다
• 방문 수는 팀 규모에 따라 달라져 비교가 어렵다
• 방문 수는 개인 정보 보호 문제를 일으킨다
• 무언가를 찾지 못해 반복해서 들어온 경우와 잘 쓰고 있는 경우가 같은 수치로 나타난다

AI 기반 도우미를 플랫폼에 붙일 때 가장 중요한 설계 원칙은?

• 가능한 한 많은 운영 작업을 사람 승인 없이 자동 실행하게 한다
• 생성한 매니페스트나 조치를 기존 정책 검사와 승인 흐름을 그대로 통과시켜, 자동화가 가드레일을 우회하지 않게 한다
• 모델의 출력을 신뢰할 수 있도록 검사 단계를 줄여 지연을 없앤다
• 운영 데이터에 대한 접근 권한을 넓게 부여해 답변 품질을 높인다

새로 합류한 개발자가 첫 커밋을 운영에 배포하기까지 걸린 시간을 재는 이유는?

• 플랫폼이 약속한 '빠르게 시작할 수 있음' 이 실제로 지켜지는지를 한 번의 경로로 확인할 수 있기 때문이다
• 신규 입사자의 역량을 객관적으로 평가할 근거가 되기 때문이다
• 다음 분기의 채용 인원 계획을 세우는 데 필요한 값이기 때문이다
• 신입 교육 과정을 몇 주로 편성할지 정할 수 있기 때문이다

플랫폼 채택률을 셀 때 '활성 사용' 의 정의로 가장 적절한 것은?

• 플랫폼 계정이 발급된 팀의 수
• 최근 기간 동안 플랫폼의 경로를 통해 실제로 변경을 배포한 팀의 수
• 포털에 한 번 이상 접속한 사용자의 수
• 플랫폼 문서를 열람한 팀의 수

플랫폼 지표를 팀 간 순위 비교와 성과 평가에 사용할 때 벌어지는 일은?

• 팀 간 건전한 경쟁이 생겨 지표가 전반적으로 개선된다
• 지표 수집 비용이 늘어난다
• 측정 주기를 더 짧게 가져가야 한다
• 지표가 목표가 되어 수치를 올리는 행동이 생기고, 지표는 더 이상 실제 상태를 알려 주지 못한다

SPACE 프레임워크가 DORA 지표를 보완하는 지점으로 가장 정확한 것은?

• 배포 파이프라인의 성능을 더 정밀하게 측정한다
• DORA 네 지표를 더 짧은 주기로 계산할 수 있게 한다
• 만족도, 협업, 업무 효율 같은 시스템 전달 속도만으로는 보이지 않는 차원을 함께 본다
• 장애 지표를 서비스 단위로 나누어 준다

DORA 의 변경 실패율(change failure rate)의 정의로 옳은 것은?

• 운영에 반영된 변경 가운데 서비스 저하를 일으켜 즉각적인 조치가 필요했던 비율
• 파이프라인에서 실패한 빌드의 비율
• 코드 리뷰에서 반려된 풀 리퀘스트의 비율
• 롤백이 수행된 배포 중 성공한 롤백의 비율

DORA 의 변경 리드 타임은 어느 구간을 재는 지표입니까?

• 요구사항이 접수된 시점부터 운영 배포까지
• 빌드가 시작된 시점부터 빌드가 끝날 때까지
• 배포가 시작된 시점부터 트래픽 전환이 끝날 때까지
• 코드가 커밋된 시점부터 그 변경이 운영에서 동작할 때까지

배포 빈도는 높은데 변경 리드 타임이 길게 나오는 조직에 대한 해석으로 가장 타당한 것은?

• 두 지표가 동시에 성립할 수 없으므로 계산에 오류가 있으며 다시 측정해야 한다
• 커밋이 배포되기까지 승인 대기나 통합 병목에서 시간이 갇히고, 쌓인 변경이 한꺼번에 나가고 있을 가능성이 크다
• 배포 자동화가 이미 잘 되어 있다는 뜻이므로 더 개선할 지점이 없다
• 테스트 커버리지가 낮아 검증을 배포로 대신하고 있다는 뜻이다