CNPA — 클라우드 네이티브 플랫폼 엔지니어링 어소시에이트 · 모의고사 · 퀴즈

CNPA 모의고사 A

LabHub 에서 이어서 보기

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

선언형(declarative) 자원 관리와 명령형(imperative) 자원 관리를 가르는 핵심 차이는?
1. 선언형은 YAML 을 쓰고 명령형은 JSON 을 쓴다
2. 선언형은 원하는 상태를 기술하고 시스템이 도달 경로를 정하며, 명령형은 사람이 도달 절차를 하나씩 지시한다
3. 선언형은 쿠버네티스에서만 쓸 수 있고 명령형은 어디서나 쓸 수 있다
4. 선언형은 항상 명령형보다 실행이 빠르다
선언형으로 관리되는 워크로드에서 누군가 클러스터에 직접 접속해 레플리카 수를 바꿔 놓았습니다. 이 상태를 무엇이라고 부르며 시스템은 어떻게 다루어야 합니까?
1. 드리프트(drift)라고 부르며, 조정 루프가 선언된 상태로 되돌리고 그 사실을 관측 가능하게 남겨야 한다
2. 핫픽스라고 부르며, 다음 배포까지 그대로 두는 것이 정상이다
3. 롤백이라고 부르며, 선언된 상태를 클러스터 값으로 갱신해야 한다
4. 장애라고 부르며, 컨트롤러를 중지해 변경을 보존해야 한다
선언형 매니페스트가 갖추어야 할 멱등성(idempotency)의 의미로 옳은 것은?
1. 같은 매니페스트를 여러 번 적용해도 결과 상태가 한 번 적용한 것과 같다
2. 매니페스트를 적용할 때마다 리소스가 새로 생성된다
3. 매니페스트에 적힌 순서대로만 리소스가 만들어진다
4. 한 번 적용한 매니페스트는 다시 적용할 수 없다
선언형 접근이 오히려 어울리지 않는 작업으로 가장 적절한 것은?
1. 여러 환경에 같은 애플리케이션 구성을 배포하는 일
2. 네임스페이스별 자원 한도를 관리하는 일
3. 일회성 데이터 백필처럼 순서와 실행 시점이 중요한 절차적 작업
4. 인그레스 라우팅 규칙을 관리하는 일
플랫폼이 사용자에게 제공하는 추상화를 선언형 API 로 만들 때 얻는 운영상 이점으로 가장 정확한 것은?
1. 사용자가 작성해야 하는 필드 수가 반드시 줄어든다
2. 원하는 상태가 기록으로 남아 검토·감사·복원이 같은 대상 위에서 이루어진다
3. 플랫폼 팀이 컨트롤러를 직접 작성할 필요가 없어진다
4. 런타임 오류가 발생하지 않는다
DevOps 의 이른바 세 가지 방법 가운데 '피드백' 이 플랫폼에서 구현된 예로 가장 적절한 것은?
1. 배포 파이프라인의 단계를 더 잘게 나눈다
2. 플랫폼 팀이 매주 회고 회의를 연다
3. 빌드 아티팩트를 오래 보관한다
4. 설정 오류를 배포 시점이 아니라 개발자의 커밋 시점에 알려 준다
'왼쪽으로 옮긴다(shift left)' 를 플랫폼에서 실천할 때 흔히 저지르는 실패는?
1. 검사를 앞으로 옮기기만 하고 개발자가 로컬에서 같은 검사를 돌릴 방법을 주지 않는다
2. 검사를 앞으로 옮기면서 배포 직전 검사도 함께 유지한다
3. 검사 실패 메시지에 수정 방법을 함께 적는다
4. 검사 규칙을 코드로 관리해 버전을 남긴다
비난 없는 사후 분석(blameless postmortem)의 목적으로 가장 정확한 것은?
1. 책임자를 특정하되 징계는 하지 않는 것
2. 장애 기록을 남겨 감사에 대비하는 것
3. 사람이 합리적으로 판단했는데도 사고가 나게 만든 시스템의 조건을 찾는 것
4. 장애 시간을 줄여 SLO 를 보호하는 것
SRE 가 말하는 토일(toil)의 정의에 가장 부합하는 작업은?
1. 새 기능의 설계 문서를 작성하는 일
2. 장애 원인을 처음으로 분석하는 일
3. 플랫폼의 다음 분기 로드맵을 정하는 일
4. 요청이 올 때마다 사람이 같은 절차로 네임스페이스를 만들어 주는 일
개발·스테이징·운영으로 승격할 때 같은 컨테이너 이미지 다이제스트를 그대로 옮겨야 하는 이유는?
1. 환경마다 다시 빌드하면 스테이징에서 검증한 것과 운영에 뜬 것이 다른 산출물이 될 수 있다
2. 환경마다 다시 빌드하면 레지스트리 저장 공간이 늘어난다
3. 다이제스트를 고정해야 이미지 풀 속도가 빨라진다
4. 쿠버네티스가 태그로는 이미지를 가져오지 못한다
환경 패리티(environment parity)가 무너졌을 때 나타나는 전형적 증상은?
1. 환경마다 빌드 시간이 달라져 파이프라인 소요 시간을 예측하기 어려워진다
2. 스테이징에서는 통과한 변경이 운영에서만 실패하고, 원인 추적이 애플리케이션이 아니라 환경 차이로 흘러간다
3. 환경 수만큼 이미지가 쌓여 레지스트리 저장 용량이 빠르게 증가한다
4. 개발자가 로컬에서 운영과 같은 컨테이너를 실행하지 못하게 된다
풀 리퀘스트마다 임시(ephemeral) 미리보기 환경을 띄우는 방식의 가장 큰 이점은?
1. 공유 스테이징 환경을 완전히 없앨 수 있다
2. 운영 환경의 자원 사용량이 줄어든다
3. 변경마다 격리된 검증 자리가 생겨 공유 환경을 서로 기다리지 않아도 된다
4. 테스트 코드를 작성하지 않아도 된다
불변 인프라(immutable infrastructure)의 원칙에 맞는 운영 방식은?
1. 실행 중인 인스턴스에 패치를 적용하고 재시작한다
2. 구성 관리 도구로 실행 중인 서버의 설정을 수렴시킨다
3. 장애 노드에 접속해 원인을 고친 뒤 계속 사용한다
4. 새 이미지를 만들어 인스턴스를 교체하고 기존 인스턴스는 폐기한다
플랫폼이 배포 매니페스트에서 이미지 태그 `latest` 사용을 막아야 하는 가장 큰 이유는?
1. 어떤 코드가 실행 중인지 특정할 수 없어 롤백과 사고 분석의 기준점이 사라진다
2. 레지스트리가 `latest` 태그를 자동으로 삭제한다
3. `latest` 는 이미지 풀 정책을 항상 Never 로 만든다
4. `latest` 태그가 붙은 이미지는 서명할 수 없다
내부 개발자 플랫폼의 통합·배포 평면(Integration and Delivery Plane)이 담당하는 일은?
1. 개발자가 요청을 입력하는 표면을 제공한다
2. 소스에서 실행 가능한 산출물까지의 빌드·검증·배포 경로를 잇는다
3. 클러스터와 데이터베이스 같은 실제 자원을 제공한다
4. 메트릭과 로그를 수집해 보여 준다
플랫폼 기능을 직접 만들 것인가 기성 제품을 쓸 것인가를 판단할 때 가장 적절한 기준은?
1. 그 기능이 조직의 차별화 요소인가, 아니면 어디서나 같은 방식으로 풀리는 문제인가
2. 그 기능을 제공하는 제품이 오픈 소스인가 상용인가
3. 플랫폼 팀 안에 그 기술을 이미 알고 있는 사람이 있는가
4. 기성 제품의 연간 라이선스 비용이 담당 인력의 인건비보다 싼가
네임스페이스로 테넌트를 나누는 소프트 멀티테넌시의 한계로 가장 정확한 것은?
1. 네임스페이스마다 별도의 API 서버가 필요해 비용이 늘어난다
2. 네임스페이스 안에서는 RBAC 를 적용할 수 없다
3. 노드 커널과 컨트롤 플레인을 공유하므로 커널 수준 탈출이나 클러스터 범위 자원의 충돌을 막지 못한다
4. 네임스페이스가 다르면 서비스 간 통신이 아예 불가능하다
플랫폼이 제공하던 기능의 하위 호환을 깨야 할 때 취할 방식으로 가장 적절한 것은?
1. 새 버전을 함께 제공하며 폐기 예고 기간과 이전 안내를 두고, 사용 현황을 근거로 종료 시점을 정한다
2. 다음 배포에서 곧바로 교체하고 장애가 나면 개별 대응한다
3. 예전 버전을 영구히 유지하고 새 버전은 선택 사항으로만 둔다
4. 변경 사실을 릴리스 노트에만 적고 사용자 통지는 하지 않는다
플랫폼의 기능 목록을 정할 때 '역량(capability)' 단위로 정의하라는 조언의 뜻은?
1. 설치된 도구 이름으로 목록을 만들라는 뜻이다
2. '데이터베이스를 안전하게 갖춘다' 처럼 사용자가 얻는 결과로 정의하고 구현 도구는 뒤에 두라는 뜻이다
3. 기능마다 담당자를 지정하라는 뜻이다
4. 기능을 쿠버네티스 리소스 종류에 맞추어 나누라는 뜻이다
가장 얇은 실행 가능 플랫폼(thinnest viable platform)이라는 개념이 권하는 출발점은?
1. 필요한 최소한으로 시작하되, 잘 정리된 문서 한 장이라도 그것이 도움이 된다면 플랫폼으로 친다
2. 핵심 기능을 모두 갖춘 뒤에 한 번에 공개한다
3. 가장 인기 있는 오픈 소스 도구를 먼저 전부 설치한다
4. 개발자 포털부터 구축한 다음 기능을 붙인다
플랫폼 팀이 다음에 무엇을 만들지 정할 때 가장 신뢰할 만한 근거는?
1. 업계에서 화제가 되는 신기술 목록
2. 경영진이 요청한 기능 목록
3. 플랫폼 팀 내부에서 만들고 싶은 것의 우선순위
4. 사용자 인터뷰와 지원 요청 기록에서 반복적으로 확인되는 마찰 지점
플랫폼 팀이 사실상 티켓 창구로 되돌아갔음을 보여 주는 신호로 가장 뚜렷한 것은?
1. 플랫폼 사용 팀의 수가 늘어나고 있다
2. 새 기능 요청이 문서화된 절차로 접수되고 있다
3. 플랫폼 팀의 업무 시간 대부분이 개별 팀의 요청을 대신 처리하는 데 쓰인다
4. 플랫폼 팀이 온콜 순환 근무를 운영하고 있다
셀프서비스와 '무엇이든 할 수 있게 열어 두는 것' 의 차이로 가장 정확한 것은?
1. 셀프서비스는 승인 절차를 반드시 포함한다
2. 셀프서비스는 안전한 기본값과 가드레일 안에서 사용자가 스스로 끝까지 갈 수 있게 하는 것이다
3. 셀프서비스는 읽기 권한만 개방하는 것이다
4. 셀프서비스는 사용자가 직접 클러스터에 접속하게 하는 것이다
플랫폼을 처음 도입할 때 파일럿 팀을 고르는 기준으로 가장 적절한 것은?
1. 조직에서 가장 규모가 큰 팀
2. 가장 복잡한 레거시 시스템을 운영하는 팀
3. 플랫폼 팀과 물리적으로 가까이 앉은 팀
4. 겪는 마찰이 뚜렷하고 협력할 의지가 있으며 성공 사례가 다른 팀에 설득력을 갖는 팀
플랫폼의 사용자층이 신입 개발자와 숙련된 팀으로 나뉠 때 설계 방침으로 가장 적절한 것은?
1. 숙련 팀의 요구에 맞추어 모든 설정 항목을 그대로 노출한다
2. 신입 개발자에 맞추어 설정 항목을 최소한만 노출하고 나머지는 고정한다
3. 안전한 기본값으로 바로 시작할 수 있게 하되, 필요한 팀은 더 낮은 계층으로 내려갈 경로를 열어 둔다
4. 두 사용자층을 위해 서로 다른 플랫폼을 각각 구축하고 따로 운영한다
플랫폼 채택을 강제 규정으로 밀어붙였을 때 지표에서 벌어지는 일은?
1. 사용률은 높게 나오지만 그 수치가 플랫폼의 유용성을 더 이상 설명하지 못한다
2. 사용률과 만족도가 함께 높아진다
3. 사용률이 낮게 유지되어 문제를 일찍 발견할 수 있다
4. 사용률 지표를 더 이상 수집할 수 없게 된다
지속적 통합(Continuous Integration)의 정의에 가장 부합하는 실천은?
1. CI 도구를 도입해 파이프라인을 구성해 두는 것
2. 모든 개발자가 작업을 자주 공유 브랜치에 통합하고 그때마다 자동 빌드와 테스트로 검증하는 것
3. 기능이 완성되면 코드 리뷰를 거쳐 병합하는 것
4. 테스트 커버리지를 일정 수준 이상으로 유지하는 것
공유 브랜치의 빌드가 깨진 상태로 방치되면 생기는 가장 큰 문제는?
1. 빌드 서버가 실패한 작업을 반복 실행하면서 자원 사용량이 늘어난다
2. 실패한 실행이 집계에서 빠져 테스트 커버리지 수치가 떨어진다
3. 이후 커밋의 검증 결과가 신뢰를 잃어, 팀 전체가 실패 신호를 무시하기 시작한다
4. 실패한 빌드의 중간 산출물이 쌓여 아티팩트 저장소 용량이 부족해진다
빌드를 재현 가능하게(reproducible) 만들라는 요구가 플랫폼에서 갖는 의미는?
1. 같은 커밋에서 언제 어디서 빌드해도 같은 산출물이 나와, 검증 결과를 산출물에 귀속시킬 수 있다
2. 빌드 시간이 항상 일정하게 유지된다
3. 빌드 캐시를 사용하지 않는다는 뜻이다
4. 빌드를 항상 같은 빌드 서버에서 수행한다는 뜻이다
지속적 전달(Continuous Delivery)과 지속적 배포(Continuous Deployment)의 차이는?
1. 전달은 카나리를 쓰고 배포는 블루 그린을 쓴다
2. 전달은 스테이징까지만, 배포는 운영까지 자동화한다는 뜻이다
3. 전달은 언제든 배포 가능한 상태로 유지하는 것이고, 배포는 그 릴리스를 사람의 승인 없이 자동으로 운영에 내보내는 것이다
4. 둘은 같은 뜻이며 지역에 따라 다르게 부른다
GitOps 의 원칙 가운데 '지속적 조정(continuously reconciled)' 이 요구하는 것은?
1. 선언된 상태가 실제 상태와 계속 대조되어 차이가 발견되면 자동으로 좁혀진다
2. 커밋이 있을 때마다 파이프라인이 배포 명령을 실행한다
3. 배포 이력이 Git 에 기록으로 남는다
4. 모든 변경이 풀 리퀘스트를 거친다
요청 하나가 여러 서비스를 거치는 동안 어느 구간에서 지연이 생겼는지 알아내려 합니다. 가장 알맞은 신호는?
1. 서비스별 CPU 사용률 메트릭
2. 각 서비스의 애플리케이션 로그
3. 쿠버네티스 이벤트 기록
4. 요청 단위로 이어진 분산 트레이스
메트릭 라벨에 사용자 ID 나 요청 ID 같은 값을 넣으면 생기는 문제는?
1. 메트릭 이름이 중복되어 수집이 실패한다
2. 시계열 수가 값의 가짓수만큼 늘어나 저장과 질의 비용이 급격히 커진다
3. 라벨 값이 로그로 전달되지 않는다
4. 메트릭의 정밀도가 떨어진다
플랫폼이 OpenTelemetry 를 계측 표준으로 채택할 때 얻는 가장 큰 이점은?
1. 관측 데이터의 저장 비용이 줄어든다
2. 애플리케이션 코드를 수정하지 않고도 모든 신호가 수집된다
3. 계측 방식을 백엔드와 분리해, 저장·분석 도구를 바꿔도 애플리케이션의 계측을 다시 하지 않아도 된다
4. 메트릭과 로그와 트레이스가 자동으로 하나의 화면에 통합된다
플랫폼이 관측성을 골든 패스에 기본으로 끼워 넣어야 하는 이유로 가장 적절한 것은?
1. 관측 도구 라이선스 비용을 아낄 수 있다
2. 개발자가 관측성 개념을 배우지 않아도 되게 하기 위해서다
3. 장애가 발생하지 않도록 예방하기 위해서다
4. 팀마다 다르게 계측하면 서비스를 가로지르는 상관 분석이 불가능해지기 때문이다
에러 버짓을 거의 다 소진한 서비스에 대해 취할 조치로 가장 적절한 것은?
1. SLO 목표치를 낮춰 버짓을 회복시킨다
2. 신규 기능 배포 속도를 늦추고 신뢰성 개선 작업을 우선한다
3. 알림 임계값을 완화해 경보 소음을 줄인다
4. 해당 서비스의 SLI 수집을 잠시 중단한다
서비스 간 통신에 mTLS 를 적용할 때 단방향 TLS 에 비해 추가로 얻는 것은?
1. 전송 구간 암호화
2. 인증서 자동 갱신
3. 요청 경로 단위의 접근 제어
4. 호출하는 쪽의 신원까지 인증서로 검증하는 능력
네트워크 정책을 제로 트러스트 원칙에 맞게 도입하는 방식은?
1. 네임스페이스마다 기본 거부를 두고 필요한 통신만 명시적으로 허용한다
2. 모든 통신을 허용하고 위험한 대상만 차단 목록에 넣는다
3. 인그레스만 제한하고 이그레스는 열어 둔다
4. 운영 네임스페이스에만 정책을 적용한다
서비스 메시 도입을 검토할 때 가장 정직하게 따져야 할 비용은?
1. 애플리케이션 코드를 메시 전용 SDK 로 재작성해야 한다는 점
2. 메시를 쓰면 네트워크 정책을 더 이상 쓸 수 없다는 점
3. 사이드카나 노드 단위 프록시가 지연·자원·운영 대상으로 추가되고, 장애 시 조사 범위가 한 겹 늘어난다는 점
4. 메시가 트래픽을 암호화하면 관측 데이터를 수집할 수 없다는 점
같은 정책을 CI 단계와 어드미션 단계 양쪽에 두는 이유로 가장 정확한 것은?
1. 정책 엔진의 부하를 두 곳으로 분산하기 위해서다
2. CI 는 빠른 피드백을 주고 어드미션은 CI 를 우회한 경로까지 실제로 막기 때문이다
3. CI 검사는 강제력이 있고 어드미션은 참고용이기 때문이다
4. 어드미션 웹훅이 실패했을 때 CI 가 대신 차단하기 때문이다
검증(validating) 어드미션 정책과 변형(mutating) 어드미션 정책의 차이는?
1. 검증은 네임스페이스 단위로, 변형은 클러스터 단위로만 적용된다
2. 검증은 생성 요청에만, 변형은 갱신 요청에만 적용된다
3. 검증은 동기적으로, 변형은 비동기적으로 실행된다
4. 검증은 요청을 통과시키거나 거절하고, 변형은 저장 전에 요청 내용을 고쳐 넣는다
새로운 정책을 기존 클러스터에 도입할 때 권장되는 순서는?
1. 먼저 감사 모드로 위반 현황을 파악하고, 경고 단계를 거친 뒤 차단으로 올린다
2. 처음부터 차단으로 적용해 위반을 즉시 없앤다
3. 운영 네임스페이스부터 차단을 적용하고 나중에 하위 환경으로 넓힌다
4. 정책을 적용하지 않고 문서로만 안내한 뒤 위반 팀을 개별 지도한다
정책을 코드로 관리(policy as code)할 때 얻는 이점으로 가장 정확한 것은?
1. 규칙이 코드로 고정되므로 정책 위반 자체가 발생하지 않게 된다
2. 규칙이 저장소에 있으므로 별도의 정책 엔진 없이도 강제된다
3. 정책 자체를 리뷰하고 테스트하고 버전으로 되돌릴 수 있어, 규칙의 변경이 코드 변경과 같은 절차를 밟는다
4. 감사 담당자가 클러스터에 직접 접근하지 않고도 준수 여부를 확인할 수 있게 된다
테넌트 팀에 부여할 롤을 설계할 때 가장 위험한 선택은?
1. 네임스페이스 안의 디플로이먼트와 서비스에 대한 편집 권한을 준다
2. 파드 로그 조회 권한을 준다
3. 네임스페이스 안의 컨피그맵 생성 권한을 준다
4. 편의를 위해 리소스와 동사를 와일드카드로 열어 둔 클러스터롤을 바인딩한다
쿠버네티스 시크릿에 대한 설명으로 옳은 것은?
1. 시크릿 값은 저장 시 자동으로 암호화되므로 별도 조치가 필요 없다
2. 값이 base64 로 인코딩될 뿐이므로, 저장 시 암호화와 접근 권한 제한을 따로 갖추어야 한다
3. 시크릿은 파드에 마운트할 수 없고 환경 변수로만 전달된다
4. 시크릿은 네임스페이스 경계를 넘어 자동으로 공유된다
서비스 어카운트 토큰의 자동 마운트를 기본적으로 꺼 두라고 권하는 이유는?
1. API 서버에 접근할 필요가 없는 파드까지 토큰을 갖게 되어, 침해 시 공격자가 곧바로 API 자격 증명을 얻기 때문이다
2. 토큰 마운트가 파드 시작 시간을 크게 늘리기 때문이다
3. 토큰이 마운트되면 네트워크 정책이 적용되지 않기 때문이다
4. 토큰 파일이 컨테이너 이미지 크기를 키우기 때문이다
소프트웨어 공급망 보안에서 SBOM 이 하는 역할로 가장 정확한 것은?
1. 빌드 결과물이 만들어진 뒤 변조되지 않았음을 서명으로 증명한다
2. 빌드가 어떤 소스와 어떤 환경에서 수행되었는지를 증명한다
3. 산출물에 어떤 구성 요소와 버전이 들어 있는지 목록으로 남겨, 새 취약점이 공개됐을 때 영향 범위를 즉시 찾게 해 준다
4. 실행 중인 컨테이너의 이상 행위를 탐지해 침해 시도를 알린다
CI 파이프라인이 클라우드 자원에 접근할 때 장기 정적 액세스 키 대신 권장되는 방식은?
1. 키를 암호화해 저장소에 커밋한다
2. 키를 파이프라인 변수로 저장하고 분기마다 다른 값을 쓴다
3. 키를 90일마다 사람이 수동으로 교체한다
4. 워크로드 아이덴티티로 신원을 증명하고 실행마다 수명이 짧은 자격 증명을 발급받는다
파이프라인의 단계 순서를 정할 때 지켜야 할 원칙은?
1. 가장 중요한 검사를 마지막에 배치해 최종 판단으로 삼는다
2. 빠르고 실패 가능성이 높은 검사를 앞에 두어 잘못된 변경이 일찍 멈추게 한다
3. 느린 검사를 앞에 두어 뒤 단계의 대기를 줄인다
4. 단계를 나누지 않고 하나의 작업으로 묶어 실행 시간을 줄인다
파이프라인 실행 시간이 길어져 개발자들이 결과를 기다리지 않게 되었습니다. 가장 먼저 검토할 조치는?
1. 실행 빈도를 줄여 하루 한 번만 파이프라인을 돌린다
2. 느린 테스트를 삭제해 실행 시간을 줄인다
3. 단계 병렬화와 의존성 캐시를 적용하고, 오래 걸리는 검사는 커밋 이후 단계로 옮긴다
4. 빌드 서버를 늘리고 개발자에게 기다리도록 안내한다
플랫폼이 각 팀에 파이프라인 템플릿을 제공할 때 얻는 가장 큰 효과는?
1. 팀별 파이프라인 실행 시간이 균일해진다
2. 팀이 파이프라인 문법을 배우지 않아도 되므로 CI 도구를 자주 교체할 수 있다
3. 파이프라인 관련 장애가 발생하지 않는다
4. 보안 스캔과 서명 같은 필수 단계가 팀마다 다시 만들어지지 않고 한곳에서 갱신된다
사고 대응에서 사고 지휘자(incident commander)의 역할로 가장 정확한 것은?
1. 기술적 조사를 직접 수행하지 않고, 역할을 배분하고 상황을 정리하며 의사 결정 지점을 관리한다
2. 가장 숙련된 엔지니어로서 원인 분석을 직접 주도한다
3. 고객 공지문을 작성하고 배포한다
4. 사고 종료 후 책임 소재를 판단한다
공용 플랫폼이 만들어 내는 위험 가운데 사고 대응 설계에 가장 크게 반영해야 할 것은?
1. 플랫폼 팀의 온콜 인원이 적다는 점
2. 플랫폼 구성 요소 하나의 장애가 그 위에 올라탄 모든 팀의 장애가 된다는 점
3. 플랫폼 사용자가 사고 대응 훈련을 받지 않았다는 점
4. 플랫폼이 여러 클라우드에 걸쳐 있다는 점
운영 사고가 진행 중이고 직전 배포가 의심될 때 우선순위로 옳은 것은?
1. 원인을 정확히 규명한 뒤 정확한 수정본을 배포한다
2. 사용자 영향이 큰 기능부터 차례로 비활성화한다
3. 다음 정기 배포 창까지 기다렸다가 함께 처리한다
4. 먼저 직전 배포를 되돌려 영향을 멈추고, 원인 규명은 그다음에 한다
CI 와 CD 사이의 경계에서 '계약' 역할을 하는 것은?
1. 파이프라인의 단계를 기술한 정의 파일
2. 소스 저장소에 붙인 릴리스 태그
3. 검증을 마치고 불변 식별자로 고정된 아티팩트
4. 배포를 승인한 변경 관리 티켓
CI 작업이 클러스터 자격 증명을 들고 직접 배포까지 수행하는 방식(푸시 모델)의 약점은?
1. 조정 방식에 비해 배포가 반영되는 속도가 눈에 띄게 느려진다
2. CI 시스템이 여러 클러스터에 대한 강한 권한을 상시 보유하게 되고, 배포 후의 상태 유지는 아무도 책임지지 않는다
3. CI 도구 안에서는 환경별 매니페스트를 생성할 수 없다
4. 푸시 모델에서는 어떤 버전이 언제 배포되었는지 이력을 남길 수 없다
GitOps 의 풀(pull) 모델이 보안 측면에서 갖는 장점은?
1. 저장소에 커밋할 수 있는 사람의 수를 줄일 수 있게 된다
2. 클러스터와 저장소 사이의 네트워크 통신이 필요 없어진다
3. 매니페스트에 시크릿을 평문으로 담아도 저장소가 안전해진다
4. 클러스터 안의 에이전트가 저장소를 읽어 가므로, 외부 시스템에 클러스터 자격 증명을 넘기지 않아도 된다
애플리케이션 소스 저장소와 배포 매니페스트 저장소를 나누는 이유로 가장 적절한 것은?
1. 매니페스트 저장소는 접근 권한을 아예 열어 둘 수 있기 때문이다
2. 쿠버네티스가 소스 코드가 섞인 저장소를 동기화하지 못하기 때문이다
3. 배포를 유발하는 커밋과 코드 변경 커밋이 섞이지 않아, 배포 이력과 승인 흐름을 따로 다룰 수 있기 때문이다
4. 매니페스트를 별도 저장소에 두면 동기화 속도가 빨라지기 때문이다
GitOps 로 관리되는 클러스터에서 긴급하다는 이유로 클러스터를 직접 수정하면 벌어지는 일은?
1. 조정 루프가 자동으로 그 변경을 저장소에 반영한다
2. 다음 조정 주기에 변경이 되돌려지므로, 저장소에 반영하지 않으면 조치가 사라진다
3. 해당 애플리케이션의 동기화가 영구히 중단된다
4. 변경이 유지되고 저장소가 자동으로 잠긴다
환경별 차이를 환경마다 별도 브랜치를 두어 관리하는 방식의 문제는?
1. 브랜치가 늘어날수록 저장소 크기와 클론 시간이 함께 커진다
2. 브랜치에 놓인 매니페스트는 배포 전에 검증할 수 없다
3. 조정 도구가 기본 브랜치 외의 브랜치를 추적하지 못한다
4. 환경 간 병합 충돌이 반복되고, 어느 환경에 무엇이 반영되었는지가 커밋 그래프에 흩어져 알기 어려워진다
GitOps 환경에서 스테이징에서 운영으로 승격하는 동작으로 가장 적절한 것은?
1. 스테이징에서 검증된 이미지 다이제스트를 운영 환경 매니페스트에 반영하는 커밋을 올린다
2. 운영 클러스터에서 이미지 태그를 갱신하는 명령을 실행한다
3. 운영 환경의 조정을 잠시 끄고 새 버전을 배포한 뒤 다시 켠다
4. 스테이징 네임스페이스의 리소스를 운영 네임스페이스로 복사한다
쿠버네티스 컨트롤러가 '수준 기반(level-triggered)' 으로 동작한다는 말의 뜻은?
1. 컨트롤러가 우선순위 수준에 따라 리소스를 처리한다는 뜻이다
2. 변경 알림을 하나도 놓치지 않도록 이벤트를 큐에 저장한다는 뜻이다
3. 변경 이벤트가 아니라 현재 상태 자체를 보고 원하는 상태와의 차이를 좁힌다는 뜻이다
4. 일정 수준 이상의 차이가 났을 때만 조정을 수행한다는 뜻이다
커스텀 리소스에서 `spec` 과 `status` 의 역할 분리로 옳은 것은?
1. `spec` 은 컨트롤러가 쓰고 `status` 는 사용자가 쓴다
2. `spec` 은 사용자가 선언한 원하는 상태이고, `status` 는 컨트롤러가 기록하는 관측된 실제 상태다
3. 둘 다 사용자가 작성하며 컨트롤러는 읽기만 한다
4. `status` 는 사용자에게 보이지 않는 내부 필드다
조정 중 외부 API 호출이 실패했을 때 컨트롤러가 취해야 할 동작으로 가장 적절한 것은?
1. 해당 리소스를 오류 상태로 표시하고 더 이상 처리하지 않는다
2. 실패할 때까지 같은 호출을 즉시 반복한다
3. 컨트롤러를 종료해 재시작 시 처음부터 다시 시도하게 한다
4. 오류를 status 에 남기고 지수 백오프로 다시 큐에 넣어 재시도한다
플랫폼이 제공하는 커스텀 리소스에 OpenAPI 스키마 검증을 촘촘히 넣어야 하는 이유는?
1. 잘못된 값이 저장되기 전에 API 서버가 거절해, 오류가 배포 이후가 아니라 제출 시점에 드러나기 때문이다
2. 스키마가 있으면 컨트롤러를 작성하지 않아도 리소스가 동작하기 때문이다
3. 스키마 검증이 있어야 커스텀 리소스를 네임스페이스 범위로 만들 수 있기 때문이다
4. 스키마가 있으면 RBAC 규칙을 따로 작성하지 않아도 되기 때문이다
플랫폼이 제공하던 커스텀 리소스를 `v1alpha1` 에서 `v1` 로 올릴 때 사용자 영향을 줄이는 방식은?
1. 새 버전만 남기고 기존 객체는 사용자가 다시 만들게 한다
2. 두 버전을 서로 다른 CRD 이름으로 각각 등록한다
3. 한 CRD 안에 두 버전을 함께 제공하고 저장 버전을 지정한 뒤, 필요하면 변환 웹훅으로 두 표현을 오가게 한다
4. 새 버전 도입 전까지 조정 컨트롤러를 중지해 둔다
플랫폼 API 를 설계할 때 파드 스펙의 모든 필드를 그대로 노출하면 생기는 문제는?
1. API 서버의 검증 비용이 지나치게 커진다
2. 추상화가 사라져 사용자가 지던 인지 부하가 그대로 남고, 플랫폼이 내부 구현을 바꿀 여지도 없어진다
3. 커스텀 리소스의 크기 제한을 초과한다
4. 쿠버네티스가 중복된 필드 정의를 허용하지 않는다
데이터베이스나 버킷 같은 클라우드 자원을 쿠버네티스 커스텀 리소스로 프로비저닝할 때의 이점은?
1. 클라우드 제공자의 요금이 낮아진다
2. 인프라 자원에 대해서도 상태 드리프트가 발생하지 않는다
3. 인프라 프로비저닝 속도가 전용 도구보다 빨라진다
4. 애플리케이션과 인프라가 같은 선언 모델과 같은 조정·권한 체계 안에서 관리된다
커스텀 리소스로 관리하는 클라우드 자원을 다룰 때 반드시 정해 두어야 할 것은?
1. 자원마다 별도의 클러스터를 둘 것인지 여부
2. 커스텀 리소스를 삭제했을 때 실제 자원까지 삭제할 것인지, 남겨 둘 것인지에 대한 정책
3. 자원 이름에 사용할 접두사 규칙
4. 프로비저닝을 어느 시간대에 수행할 것인지
오퍼레이터 패턴을 한 문장으로 설명한 것으로 가장 정확한 것은?
1. 애플리케이션 설치를 템플릿으로 묶어 배포하는 방식이다
2. 클러스터 운영자에게 관리 권한을 위임하는 RBAC 설계 방식이다
3. 특정 애플리케이션의 운영 지식을 컨트롤러 코드로 옮겨, 백업이나 장애 조치 같은 작업을 조정 루프가 수행하게 하는 방식이다
4. 여러 클러스터를 하나의 컨트롤 플레인에서 다루는 연합 방식이다
어떤 미들웨어를 도입할 때 패키지 차트로 충분한지 오퍼레이터가 필요한지 판단하는 기준으로 가장 적절한 것은?
1. 그 미들웨어가 디스크에 상태를 저장하는 종류인가
2. 커뮤니티가 이미 오퍼레이터를 만들어 제공하고 있는가
3. 설치해야 할 쿠버네티스 리소스의 개수가 많은가
4. 설치 이후에도 백업·확장·버전 업그레이드 같은 지속적인 운영 판단이 필요한가
새 서비스를 만드는 화면에서 점진적 공개(progressive disclosure)를 적용한 예로 가장 적절한 것은?
1. 기본 화면에는 이름과 팀과 언어만 묻고, 자원 크기나 스케일링 설정은 고급 항목으로 접어 둔다
2. 모든 설정 항목을 한 화면에 펼쳐 두고 검색 기능을 제공한다
3. 설정 항목을 여러 단계로 나누어 모두 순서대로 입력하게 한다
4. 설정 항목을 없애고 플랫폼 팀이 대신 값을 정해 준다
서비스 스캐폴딩 템플릿이 개발자 경험에 기여하는 가장 큰 지점은?
1. 코드 작성량이 줄어 개발 속도가 빨라진다
2. 팀마다 다른 프레임워크를 쓰지 못하게 막을 수 있다
3. 저장소 생성 시간이 단축된다
4. 저장소·파이프라인·관측·소유자 정보가 처음부터 표준대로 연결된 상태로 시작한다
소프트웨어 카탈로그의 정보가 오래되지 않게 유지하는 방법으로 가장 효과적인 것은?
1. 분기마다 팀에 카탈로그 갱신을 요청한다
2. 카탈로그 메타데이터를 서비스 저장소 안에 두고 코드와 함께 변경·리뷰되게 한다
3. 카탈로그 편집 권한을 플랫폼 팀으로 한정한다
4. 카탈로그에 최종 수정일을 표시해 오래된 항목을 알아보게 한다
서비스 카탈로그를 화면뿐 아니라 API 로도 제공해야 하는 이유는?
1. 화면보다 API 의 응답 속도가 빠르기 때문이다
2. 카탈로그 데이터의 저장 비용이 줄어들기 때문이다
3. 파이프라인·정책 검사·온콜 도구가 소유자와 의존성 정보를 자동으로 조회해 쓸 수 있기 때문이다
4. API 가 있어야 카탈로그에 접근 권한을 걸 수 있기 때문이다
개발자 포털이 링크 모음집으로 전락하지 않으려면 무엇이 필요합니까?
1. 포털에서 실제로 작업을 끝낼 수 있도록 아래 계층의 기능이 실행 가능한 형태로 연결되어 있어야 한다
2. 포털의 디자인과 검색 기능을 개선해야 한다
3. 모든 내부 도구의 링크를 빠짐없이 등록해야 한다
4. 포털 접속을 전사 표준 시작 페이지로 지정해야 한다
개발자 경험을 포털 방문 수로만 측정할 때의 한계는?
1. 방문 수는 수집이 어렵고 정확도가 낮다
2. 방문 수는 팀 규모에 따라 달라져 비교가 어렵다
3. 방문 수는 개인 정보 보호 문제를 일으킨다
4. 무언가를 찾지 못해 반복해서 들어온 경우와 잘 쓰고 있는 경우가 같은 수치로 나타난다
AI 기반 도우미를 플랫폼에 붙일 때 가장 중요한 설계 원칙은?
1. 가능한 한 많은 운영 작업을 사람 승인 없이 자동 실행하게 한다
2. 생성한 매니페스트나 조치를 기존 정책 검사와 승인 흐름을 그대로 통과시켜, 자동화가 가드레일을 우회하지 않게 한다
3. 모델의 출력을 신뢰할 수 있도록 검사 단계를 줄여 지연을 없앤다
4. 운영 데이터에 대한 접근 권한을 넓게 부여해 답변 품질을 높인다
새로 합류한 개발자가 첫 커밋을 운영에 배포하기까지 걸린 시간을 재는 이유는?
1. 플랫폼이 약속한 '빠르게 시작할 수 있음' 이 실제로 지켜지는지를 한 번의 경로로 확인할 수 있기 때문이다
2. 신규 입사자의 역량을 객관적으로 평가할 근거가 되기 때문이다
3. 다음 분기의 채용 인원 계획을 세우는 데 필요한 값이기 때문이다
4. 신입 교육 과정을 몇 주로 편성할지 정할 수 있기 때문이다
플랫폼 채택률을 셀 때 '활성 사용' 의 정의로 가장 적절한 것은?
1. 플랫폼 계정이 발급된 팀의 수
2. 최근 기간 동안 플랫폼의 경로를 통해 실제로 변경을 배포한 팀의 수
3. 포털에 한 번 이상 접속한 사용자의 수
4. 플랫폼 문서를 열람한 팀의 수
플랫폼 지표를 팀 간 순위 비교와 성과 평가에 사용할 때 벌어지는 일은?
1. 팀 간 건전한 경쟁이 생겨 지표가 전반적으로 개선된다
2. 지표 수집 비용이 늘어난다
3. 측정 주기를 더 짧게 가져가야 한다
4. 지표가 목표가 되어 수치를 올리는 행동이 생기고, 지표는 더 이상 실제 상태를 알려 주지 못한다
SPACE 프레임워크가 DORA 지표를 보완하는 지점으로 가장 정확한 것은?
1. 배포 파이프라인의 성능을 더 정밀하게 측정한다
2. DORA 네 지표를 더 짧은 주기로 계산할 수 있게 한다
3. 만족도, 협업, 업무 효율 같은 시스템 전달 속도만으로는 보이지 않는 차원을 함께 본다
4. 장애 지표를 서비스 단위로 나누어 준다
DORA 의 변경 실패율(change failure rate)의 정의로 옳은 것은?
1. 운영에 반영된 변경 가운데 서비스 저하를 일으켜 즉각적인 조치가 필요했던 비율
2. 파이프라인에서 실패한 빌드의 비율
3. 코드 리뷰에서 반려된 풀 리퀘스트의 비율
4. 롤백이 수행된 배포 중 성공한 롤백의 비율
DORA 의 변경 리드 타임은 어느 구간을 재는 지표입니까?
1. 요구사항이 접수된 시점부터 운영 배포까지
2. 빌드가 시작된 시점부터 빌드가 끝날 때까지
3. 배포가 시작된 시점부터 트래픽 전환이 끝날 때까지
4. 코드가 커밋된 시점부터 그 변경이 운영에서 동작할 때까지
배포 빈도는 높은데 변경 리드 타임이 길게 나오는 조직에 대한 해석으로 가장 타당한 것은?
1. 두 지표가 동시에 성립할 수 없으므로 계산에 오류가 있으며 다시 측정해야 한다
2. 커밋이 배포되기까지 승인 대기나 통합 병목에서 시간이 갇히고, 쌓인 변경이 한꺼번에 나가고 있을 가능성이 크다
3. 배포 자동화가 이미 잘 되어 있다는 뜻이므로 더 개선할 지점이 없다
4. 테스트 커버리지가 낮아 검증을 배포로 대신하고 있다는 뜻이다