PCA — 프로메테우스 인증 어소시에이트 · 모의고사 · 퀴즈

PCA 모의고사 A

LabHub 에서 이어서 보기

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

메트릭이 로그에 비해 갖는 강점으로 가장 정확한 것은?
1. 개별 요청의 전체 맥락을 그대로 담아 사후 조사가 쉽다
2. 시간에 따라 집계된 수치라 저장 비용이 낮고 장기 추세와 알림에 적합하다
3. 서비스 사이의 호출 관계를 그대로 보여 준다
4. 샘플링 없이 모든 이벤트를 개별적으로 보존한다
가용성이 아니라 지연으로 사용자 경험이 나빠지는 상황을 잡으려면 SLI 를 어떻게 정의해야 하는가?
1. 성공 응답의 비율만 본다
2. 정해진 기준 시간 안에 성공한 요청의 비율을 본다
3. 요청 수의 총합을 본다
4. 응답 시간의 산술 평균을 본다
화이트박스 모니터링과 블랙박스 모니터링의 차이로 올바른 것은?
1. 화이트박스는 시스템 내부가 노출한 지표를 보고, 블랙박스는 밖에서 관찰 가능한 증상을 본다
2. 화이트박스는 외부 프로브로 확인하고, 블랙박스는 코드 계측으로 확인한다
3. 화이트박스는 로그만 쓰고, 블랙박스는 메트릭만 쓴다
4. 화이트박스는 운영 환경에서만, 블랙박스는 개발 환경에서만 쓸 수 있다
관측 가능성(observability)과 모니터링의 관계로 가장 적절한 것은?
1. 모니터링은 미리 정한 질문에 답하고, 관측 가능성은 예상하지 못한 질문에도 답할 수 있는 성질이다
2. 관측 가능성은 모니터링의 옛 이름이라 둘은 같은 말이다
3. 모니터링은 메트릭만, 관측 가능성은 트레이스만 다룬다
4. 관측 가능성은 도구의 이름이고 모니터링은 절차의 이름이다
네 가지 골든 시그널에 해당하지 않는 것은?
1. 지연(latency)
2. 트래픽(traffic)
3. 배포 빈도(deployment frequency)
4. 포화도(saturation)
카디널리티가 높은 레이블이 문제가 되는 이유는?
1. 레이블 값의 조합마다 별도의 시계열이 만들어져 메모리와 저장 공간이 급격히 늘기 때문
2. 레이블 값이 길면 스크레이프 요청이 실패하기 때문
3. 레이블이 많으면 PromQL 문법 오류가 나기 때문
4. 레이블 값이 많으면 알림 규칙을 만들 수 없기 때문
SLO 를 정할 때 100% 를 목표로 삼지 않는 이유로 가장 적절한 것은?
1. 100% 는 측정 자체가 불가능하기 때문
2. 마지막 몇 자릿수의 비용이 급격히 커지고 변경을 감당할 여유가 사라지기 때문
3. 고객이 100% 를 요구하지 않기 때문
4. 프로메테우스가 100% 를 표현하지 못하기 때문
에러 버짓이 소진되었을 때의 조치로 가장 적절한 것은?
1. SLO 목표치를 낮춰 버짓을 다시 확보한다
2. 새 기능 배포를 늦추고 안정성 개선에 힘을 옮긴다
3. 알림 임계값을 올려 알림이 덜 오게 한다
4. 측정 창을 늘려 위반이 희석되게 한다
분산 추적이 메트릭으로는 답하기 어려운 질문에 답해 주는 예로 가장 적절한 것은?
1. 지난 30일 동안 오류율이 어떻게 변했는가
2. 이 느린 요청 하나가 어느 서비스 구간에서 시간을 썼는가
3. 현재 클러스터의 총 요청 처리량은 얼마인가
4. 노드의 메모리 사용률이 임계값을 넘었는가
USE 방법론에서 보는 세 가지로 올바른 것은?
1. 사용률(Utilization), 포화도(Saturation), 에러(Errors)
2. 요청률(Rate), 에러(Errors), 지속시간(Duration)
3. 사용률(Utilization), 속도(Speed), 규모(Extent)
4. 가용성(Uptime), 서비스(Service), 경험(Experience)
대시보드를 만들 때 흔히 저지르는 실수로 가장 적절한 것은?
1. 패널을 잘게 나누지 않고 몇 개의 핵심 지표만 크게 배치하는 것
2. 가능한 모든 지표를 한 화면에 늘어놓아 어디를 봐야 할지 알 수 없게 만드는 것
3. 패널마다 단위를 명시하는 것
4. 사용자 관점의 지표를 맨 위에 두는 것
프로메테우스의 데이터 모델에서 하나의 시계열을 유일하게 식별하는 것은?
1. 메트릭 이름과 레이블 이름·값 집합의 조합
2. 메트릭 이름 하나
3. 스크레이프한 타깃의 IP 주소
4. 샘플의 타임스탬프
프로메테우스의 네 가지 메트릭 타입에 해당하지 않는 것은?
1. Counter
2. Gauge
3. Timer
4. Histogram
Counter 타입에 대한 설명으로 올바른 것은?
1. 오르내릴 수 있으므로 현재 온도나 큐 길이에 적합하다
2. 단조 증가하며 프로세스가 재시작하면 0 으로 되돌아간다
3. 값이 자동으로 초당 비율로 변환되어 저장된다
4. 최근 값 하나만 저장되고 과거 값은 버려진다
프로메테우스가 pull 방식을 기본으로 택한 이유로 가장 적절한 것은?
1. 타깃 목록을 서버가 알고 있어 대상이 살아 있는지 스크레이프 자체로 판단할 수 있기 때문
2. push 방식보다 네트워크 대역폭을 항상 적게 쓰기 때문
3. 타깃이 자기 지표를 저장하지 않아도 되기 때문
4. 방화벽 설정이 전혀 필요 없기 때문
타깃의 `up` 메트릭이 0 이라는 것의 의미로 가장 정확한 것은?
1. 타깃의 애플리케이션이 오류 응답을 반환했다
2. 직전 스크레이프가 실패했다
3. 타깃이 서비스 디스커버리에서 사라졌다
4. 타깃의 지표 값이 모두 0 이다
서비스 디스커버리를 쓰지 않고 static_configs 로만 타깃을 관리할 때의 문제는?
1. 타깃이 늘거나 줄 때마다 설정을 고치고 다시 읽어야 한다
2. 레이블을 붙일 수 없어 쿼리에서 구분할 수 없다
3. 스크레이프 간격을 지정할 수 없다
4. TLS 로 스크레이프할 수 없다
`scrape_interval` 을 지나치게 짧게 잡을 때 생기는 대가로 가장 적절한 것은?
1. 샘플 수가 늘어 저장 용량과 쿼리 비용이 함께 증가한다
2. 레이블 카디널리티가 자동으로 늘어난다
3. 타깃이 스크레이프를 거부하게 된다
4. 알림 규칙이 평가되지 않는다
프로메테우스 TSDB 의 head 블록이 하는 역할은?
1. 가장 오래된 데이터를 압축해 오브젝트 스토리지로 옮겨 장기 보관한다
2. 최근 샘플을 메모리에 두고 WAL 에 기록했다가 주기적으로 디스크 블록으로 내린다
3. 쿼리 결과를 캐시해 같은 요청이 반복될 때 빠르게 응답한다
4. 알림 규칙의 상태를 저장해 재시작한 뒤에도 그대로 유지되게 한다
프로메테우스의 데이터 보존 기간을 늘리는 대신 장기 저장소를 붙이는 이유로 가장 적절한 것은?
1. 단일 인스턴스의 디스크와 메모리로는 감당하기 어렵고 이중화도 되지 않기 때문
2. 프로메테우스가 30일을 넘는 보존을 지원하지 않기 때문
3. 장기 저장소가 PromQL 을 더 빠르게 실행하기 때문
4. 장기 저장소를 붙이면 카디널리티 제한이 사라지기 때문
`honor_labels: true` 를 설정하면 어떻게 되는가?
1. 스크레이프한 데이터의 레이블이 프로메테우스가 붙이는 레이블보다 우선한다
2. 모든 레이블이 소문자로 변환된다
3. 타깃의 레이블이 무시되고 job 레이블만 남는다
4. 레이블 값의 길이 제한이 해제된다
프로메테우스 페더레이션(federation)의 적절한 사용법은?
1. 하위 서버의 모든 시계열을 상위로 복제해 단일 저장소를 만든다
2. 하위 서버에서 이미 집계한 소수의 시계열만 상위로 가져와 전역 관점을 만든다
3. 상위 서버가 하위 서버 대신 타깃을 직접 스크레이프하게 한다
4. 하위 서버의 알림 규칙을 상위로 옮겨 중앙에서 평가한다
프로메테우스가 고가용성을 위해 쓰는 일반적인 방식은?
1. 여러 인스턴스가 리더를 선출해 하나만 스크레이프한다
2. 동일한 설정의 인스턴스 두 대가 같은 타깃을 각각 독립적으로 스크레이프한다
3. 인스턴스끼리 데이터를 실시간 복제해 동일한 블록을 유지한다
4. 하나의 인스턴스가 다른 인스턴스의 WAL 을 공유 볼륨으로 읽는다
PromQL 에서 `http_requests_total[5m]` 의 결과 타입은?
1. 즉시 벡터
2. 구간 벡터
3. 스칼라
4. 문자열
Counter 에 `rate()` 를 쓸 때 구간 길이를 스크레이프 간격의 최소 몇 배 이상으로 잡으라고 하는가?
1. 1배
2. 2배
3. 4배
4. 10배
`rate()` 와 `irate()` 의 차이로 올바른 것은?
1. rate 는 구간 전체에 대한 평균 증가율이고, irate 는 마지막 두 샘플만 보는 순간 증가율이다
2. rate 는 Gauge 에, irate 는 Counter 에 쓴다
3. rate 는 리셋을 보정하지 않고 irate 만 보정한다
4. irate 는 구간 전체를 보고 rate 는 마지막 샘플만 본다
`increase(http_requests_total[1h])` 를 가장 정확히 설명한 것은?
1. 지난 1시간 동안 관측된 마지막 값에서 첫 값을 뺀 정수 차이다
2. rate 에 구간 길이를 곱한 값이라 외삽 때문에 소수가 나올 수 있다
3. 지난 1시간의 평균값이다
4. 지난 1시간 중 가장 큰 값이다
Gauge 의 변화 추세를 보려 할 때 `rate()` 대신 써야 하는 함수는?
1. delta()
2. increase()
3. resets()
4. idelta()와 rate()의 조합
`sum(rate(http_requests_total[5m])) by (job)` 과 `sum(rate(...)) without (instance)` 의 차이로 올바른 것은?
1. by 는 나열한 레이블만 남기고, without 은 나열한 레이블만 버리고 나머지를 남긴다
2. by 는 합계를, without 은 평균을 계산한다
3. by 는 즉시 벡터를, without 은 구간 벡터를 돌려준다
4. 둘은 완전히 같은 표현이라 어느 쪽을 써도 결과가 같다
`sum(rate(http_request_duration_seconds_sum[5m])) / sum(rate(http_request_duration_seconds_count[5m]))` 가 계산하는 값은?
1. 구간 동안의 평균 응답 시간
2. 구간 동안의 95 분위 응답 시간
3. 구간 동안의 최대 응답 시간
4. 구간 동안의 초당 요청 수
`histogram_quantile(0.95, sum(rate(x_bucket[5m])) by (le))` 에서 `by (le)` 를 빠뜨리면?
1. 버킷 경계 정보가 사라져 분위수를 계산할 수 없고 결과가 비거나 잘못된다
2. 결과가 항상 0 이 된다
3. 모든 분위수가 같은 값으로 나온다
4. 쿼리는 정상 동작하고 성능만 느려진다
히스토그램 분위수 값이 실제와 다를 수 있는 근본적인 이유는?
1. 프로메테우스가 샘플을 무작위로 버리기 때문
2. 분위수 계산이 부동소수점 오차를 누적하기 때문
3. 버킷이 누적이 아니라 배타적으로 저장되기 때문
4. 버킷 안에서 값이 고르게 분포한다고 가정하고 보간하기 때문
Summary 로는 서비스 전체의 분위수를 구할 수 없는 이유는?
1. Summary 가 레이블을 지원하지 않기 때문
2. Summary 의 값이 문자열로 저장되기 때문
3. Summary 는 프로메테우스가 스크레이프하지 못하기 때문
4. Summary 는 인스턴스 안에서 이미 계산된 분위수 값을 노출하므로 인스턴스끼리 더하거나 평균 낼 수 없기 때문
벡터 매칭에서 `on(job)` 과 `ignoring(instance)` 의 관계로 올바른 것은?
1. on 은 왼쪽 벡터에만, ignoring 은 오른쪽 벡터에만 적용된다
2. on 은 일대일 매칭에만, ignoring 은 다대일 매칭에만 쓸 수 있다
3. 둘은 결과가 항상 같아 취향의 문제다
4. on 은 나열한 레이블로만 짝을 맞추고, ignoring 은 나열한 레이블을 뺀 나머지로 짝을 맞춘다
`group_left` 를 쓰는 상황으로 가장 적절한 것은?
1. 왼쪽 벡터의 시계열을 오른쪽 벡터의 순서에 맞춰 정렬하려고
2. 연산 결과에서 왼쪽 벡터가 가진 레이블을 모두 지우려고
3. 왼쪽의 여러 시계열이 오른쪽 한 시계열에 대응할 때 오른쪽 레이블을 끌어오려고
4. 왼쪽 벡터의 값을 오른쪽 벡터의 값으로 대체하려고
`absent(up{job="payments"})` 가 유용한 경우는?
1. 해당 시계열의 값이 0 일 때 알림을 띄우려는 경우
2. 해당 시계열의 증가율을 구하려는 경우
3. 여러 시계열의 평균을 구하려는 경우
4. 해당 시계열이 아예 존재하지 않을 때 알림을 띄우려는 경우
`offset 1h` 를 쓰는 목적으로 가장 적절한 것은?
1. 쿼리 실행을 한 시간 뒤로 미루려고
2. 구간 길이를 한 시간으로 늘리려고
3. 한 시간 전 시점의 값을 가져와 현재와 비교하려고
4. 알림 평가 주기를 한 시간으로 바꾸려고
`topk(5, sum(rate(errors_total[5m])) by (service))` 의 결과로 올바른 것은?
1. 오류율 상위 다섯 개의 값을 합한 스칼라 하나
2. 무작위로 고른 다섯 개의 서비스
3. 오류율이 가장 낮은 서비스 다섯 개
4. 오류율이 가장 높은 서비스 다섯 개의 시계열
`avg_over_time(node_memory_usage_bytes[1h])` 와 `avg(node_memory_usage_bytes)` 의 차이는?
1. 앞은 Gauge 에만, 뒤는 Counter 에만 쓸 수 있다
2. 앞은 즉시 벡터를, 뒤는 구간 벡터를 돌려준다
3. 앞은 시계열마다 시간 축으로 평균을 내고, 뒤는 한 시점에서 시계열들 사이의 평균을 낸다
4. 두 표현은 항상 같은 값을 돌려준다
PromQL 쿼리가 느릴 때 가장 먼저 점검할 것으로 적절한 것은?
1. 프로메테우스의 로그 레벨 설정
2. 알림 규칙의 for 값
3. Alertmanager 의 그룹 설정
4. 선택되는 시계열 수와 조회 구간의 길이
프로메테우스 명명 규약에 맞는 메트릭 이름은?
1. httpRequestsTotal
2. http_requests_total
3. http.requests.count
4. HTTP-Requests
익스포터를 쓰는 이유로 가장 정확한 것은?
1. 프로메테우스가 저장할 수 없는 데이터를 대신 저장하려고
2. 여러 프로메테우스 인스턴스 사이의 데이터를 동기화하려고
3. 직접 계측할 수 없는 서드파티 시스템의 상태를 프로메테우스 형식으로 변환해 노출하려고
4. 알림을 수신자에게 전달하려고
node_exporter 가 제공하는 지표로 가장 적절한 것은?
1. 쿠버네티스 오브젝트의 상태
2. 애플리케이션의 HTTP 요청 지연
3. 컨테이너별 자원 사용량
4. 호스트의 CPU·메모리·디스크·네트워크 같은 운영체제 수준 지표
blackbox_exporter 의 동작 방식으로 올바른 것은?
1. 대상 시스템 안에 설치되어 내부 상태를 직접 읽는다
2. 프로메테우스 대신 알림을 평가해 Alertmanager 로 보낸다
3. 프로메테우스가 대상 주소를 파라미터로 넘겨 프로브를 요청하면 결과를 지표로 돌려준다
4. 여러 익스포터의 지표를 모아 한곳에 캐시한다
Pushgateway 를 상시 워크로드에 쓰면 안 되는 이유는?
1. Pushgateway 가 Counter 타입을 지원하지 않기 때문
2. Pushgateway 가 레이블을 지원하지 않기 때문
3. Pushgateway 를 쓰면 스크레이프 간격을 지정할 수 없기 때문
4. 값이 계속 남아 있어 인스턴스가 죽어도 지표가 살아 있는 것처럼 보이고 up 으로 생존을 판단할 수 없기 때문
kube-state-metrics 와 metrics-server 의 차이로 올바른 것은?
1. 둘은 같은 기능을 하며 이름만 다르다
2. kube-state-metrics 는 자원 사용량을, metrics-server 는 오브젝트 상태를 다룬다
3. kube-state-metrics 는 오브젝트의 선언과 상태를 지표로 내고, metrics-server 는 오토스케일링용 자원 사용량을 API 로 제공한다
4. metrics-server 가 프로메테우스 형식으로 장기 저장을 제공한다
레코딩 룰을 쓰는 주된 목적은?
1. 조건이 참인 동안 알림을 발생시켜 Alertmanager 로 보낸다
2. 보존 기간이 지난 오래된 시계열을 찾아 자동으로 삭제한다
3. 레이블 값의 가짓수를 감시해 카디널리티를 자동으로 낮춘다
4. 자주 쓰는 무거운 표현식을 미리 계산해 새 시계열로 저장해 둔다
레코딩 룰 이름의 관례로 권장되는 형태는?
1. 원본 메트릭과 같은 이름을 쓰되 레이블만 다르게 한다
2. 규칙 파일 이름을 그대로 메트릭 이름으로 쓴다
3. `level:metric:operations` 형태로 집계 수준과 연산을 이름에 담는다
4. 접두사 없이 임의의 짧은 이름을 쓴다
애플리케이션을 계측할 때 레이블 값으로 쓰기에 가장 위험한 것은?
1. HTTP 상태 코드
2. 요청 경로의 라우트 템플릿
3. 요청마다 달라지는 사용자 식별자
4. 서비스 이름
알림 규칙의 `for` 절이 하는 일은?
1. 알림이 발생한 뒤 그 기간 동안 재발송을 막는다
2. 그 기간이 지나면 알림을 자동으로 해제한다
3. 그 기간마다 규칙을 한 번씩 평가한다
4. 조건이 그 기간 동안 계속 참이어야 firing 으로 바뀌게 한다
알림 규칙에서 labels 와 annotations 의 역할 차이로 올바른 것은?
1. labels 는 사람이 읽을 설명을, annotations 는 라우팅 정보를 담는다
2. 둘 다 라우팅에 쓰이며 차이는 이름뿐이다
3. labels 는 알림의 신원과 라우팅에 쓰이고, annotations 는 사람이 읽을 설명을 담는다
4. labels 는 Alertmanager 가, annotations 는 프로메테우스가 각각 생성한다
Alertmanager 의 그룹핑(grouping)이 해결하는 문제는?
1. 알림의 심각도를 자동으로 판정한다
2. 중복 수신자를 제거해 비용을 줄인다
3. 알림 조건을 다시 평가해 오탐을 걸러 낸다
4. 같은 원인으로 한꺼번에 터진 알림들을 하나의 알림으로 묶어 보내 폭주를 막는다
Alertmanager 의 억제(inhibition) 규칙을 쓰는 상황으로 가장 적절한 것은?
1. 같은 알림이 반복될 때 두 번째부터 무시한다
2. 야간에는 모든 알림을 보내지 않게 한다
3. 클러스터 전체가 죽었다는 알림이 있을 때 그 하위 서비스의 알림을 보내지 않게 한다
4. 알림을 심각도 순으로 정렬한다
사일런스(silence)와 억제(inhibition)의 차이로 올바른 것은?
1. 사일런스는 설정 파일로만, 억제는 UI 로만 만들 수 있다
2. 사일런스는 알림 평가 자체를 멈추고 억제는 전송만 막는다
3. 둘은 같은 기능이며 이름만 다르다
4. 사일런스는 사람이 기간을 정해 거는 일시적 조치이고, 억제는 설정으로 정의한 알림 사이의 관계다
알림 피로(alert fatigue)를 줄이는 방법으로 가장 적절한 것은?
1. 임계값을 모두 높여 알림 수를 줄인다
2. 알림 수신자를 늘려 부담을 나눈다
3. 사람이 즉시 행동해야 하는 것만 호출로 보내고 나머지는 티켓이나 대시보드로 돌린다
4. 알림 규칙의 for 값을 일괄적으로 크게 늘린다
증상 기반 알림(symptom-based alerting)을 권하는 이유로 가장 적절한 것은?
1. 원인 기반 알림보다 항상 더 빨리 발생하기 때문
2. 알림 규칙을 더 적게 쓸 수 있어 설정이 짧아지기 때문
3. 증상 지표가 원인 지표보다 카디널리티가 낮기 때문
4. 사용자가 겪는 문제를 직접 감지하므로 예상하지 못한 원인으로 생긴 장애도 잡을 수 있기 때문
번 레이트(burn rate) 기반 알림에서 긴 창과 짧은 창을 함께 쓰는 이유는?
1. 두 창의 평균을 내어 정확도를 높이려고
2. 긴 창은 낮에, 짧은 창은 밤에 쓰려고
3. 긴 창으로 오탐을 줄이고 짧은 창으로 이미 회복된 상황에서 알림이 계속 남는 것을 막는다
4. 짧은 창이 실패했을 때를 대비한 예비 조건이라서
Alertmanager 의 `group_wait` 가 하는 일은?
1. 이미 보낸 그룹에 새 알림이 추가됐을 때 다음 전송까지 기다린다
2. 같은 내용의 알림을 다시 보내기까지 기다린다
3. 수신자가 응답하지 않을 때 다음 수신자로 넘어가기까지 기다린다
4. 새 그룹의 첫 알림을 보내기 전에 같은 그룹의 다른 알림이 더 오는지 잠시 기다린다
알림 라우팅 트리에서 하위 라우트가 상위와 다른 값을 지정하지 않았을 때의 동작은?
1. 기본값으로 되돌아간다
2. 설정 검증에서 오류가 난다
3. 상위 라우트의 설정을 물려받는다
4. 그 라우트가 무시된다
대시보드에서 알림 임계선을 함께 그려 두는 것이 도움이 되는 이유는?
1. 임계선을 그리면 알림이 더 빨리 발생하기 때문
2. 임계선이 있어야 PromQL 이 정확한 값을 돌려주기 때문
3. 임계선을 그리면 시계열 저장 용량이 줄기 때문
4. 지금 값이 알림 기준에서 얼마나 떨어져 있는지 한눈에 보여 대응 여유를 판단할 수 있기 때문