CCAAK · D-1

시험 당일 전략

CCAAK는 지식을 묻는 시험이 아니라 판단 순서를 묻는 시험입니다. 같은 증상에 대해 세 가지 조치가 모두 "틀리지 않은" 선택지로 제시되고, 그중 가장 먼저 해야 할 것을 고르게 합니다. 이 페이지는 그 판단을 빠르게 만드는 패턴표와, 시험장에서의 시간 운영 방법을 정리합니다.

이 페이지의 사용법

시험 조건 — 확인된 것만

CCAAK 응시 조건. 미공개 항목은 추측하지 않습니다.
항목값시험 운영에 주는 영향
시간 90분 원격 프록터링. 환경 점검에 시간을 쓰지 않도록 전날 미리 확인하세요.
문항 유형 multiple-choice · matching · list order matching과 list order는 부분 점수를 기대하기 어렵습니다. 확실히 아는 것부터 채우세요.
문항 수 미공개 "문항당 N초"를 미리 계산할 수 없습니다. 대신 진행률 기준으로 운영합니다.
합격 점수 미공개 "몇 개 틀려도 된다"는 계산이 불가능합니다. 전 섹션 고르게가 유일한 전략입니다.
재응시 7일 대기 실패해도 일주일 뒤 재도전이 가능합니다. 첫 시도에서 취약 섹션을 기록해 두세요.
유효 기간 2년 —

증상별 "먼저 확인할 것" 패턴

이 표가 이 페이지의 핵심입니다. 시나리오 문항의 지문은 대개 아래 왼쪽 열의 형태로 오고, 정답은 대개 가운데 열입니다. 오른쪽 열은 결국 필요하지만 지금은 아닌 조치로, 오답 선택지에 자주 등장합니다.

증상 → 먼저 확인할 것 → 나중에 할 것
증상 먼저 (정답 후보) 나중 (오답 후보)
토픽 생성·설정 변경이 전부 타임아웃 ActiveControllerCount 합계와 쿼럼 과반 브로커 재시작, 토픽 재생성
프로듀서가 NotEnoughReplicas UnderMinIsrPartitionCount, 죽은 브로커 수 acks를 1로 낮추기, unclean 선출 켜기
URP가 0으로 안 돌아온다 남은 복제 스로틀 확인, 어느 브로커가 빠졌는지 replica.lag.time.max.ms 상향
읽기·쓰기가 모두 안 되는 파티션 OfflinePartitionsCount, 레플리카 위치 unclean 선출 활성화(최후 수단)
브로커 전체 지연이 동시에 나빠짐 RequestHandlerAvgIdlePercent, RequestQueueTimeMs 브로커 추가, 파티션 증설
디스크가 찬다 무엇이 공간을 먹는지 분류 → 리텐션 동적 축소 세그먼트 파일 직접 삭제, 토픽 삭제
리텐션을 줄였는데 공간이 안 준다 세그먼트 롤 여부, log.retention.check.interval.ms(5분) 브로커 재시작
컨슈머가 계속 리밸런스 배치 처리 시간과 max.poll.interval.ms, 멤버 수 변동 session.timeout.ms만 늘리기
lag이 계속 늘어난다 파티션별 lag 분포, URP 여부, 유입량 변화 컨슈머를 파티션 수 이상으로 늘리기, 오프셋 리셋
컨슈머가 죽었는데 lag 알림이 없었다 records-lag-max가 컨슈머 발행임을 확인 알림 임계값 하향
외부 클라이언트가 붙지 못한다 advertised.listeners와 인증서 SAN 포트 변경, 리스너 추가
인증에 실패한다 security.protocol 일치 → sasl.mechanism 허용 여부 → 자격증명 존재 allow.everyone.if.no.acl.found=true
프로듀서는 되고 컨슈머만 실패 오류 이름(GROUP_AUTHORIZATION_FAILED) 확인 → 그룹 ACL 토픽 ACL 재부여
보안을 켠 뒤 브로커가 안 뜬다 리스너 이름이 map에 있는지, 컨트롤러 리스너 충돌 인증서 재발급
Connect 워커가 죽었다. 예외를 보려면 죽은 노드 로컬 로그 + 다른 워커의 status 응답 trace 죽은 워커의 REST 호출
Connect REST가 409 리밸런스 진행 여부 → 잠시 후 재시도 커넥터 삭제·재생성
워커를 늘렸는데 처리량이 그대로 tasks.max(기본 1)와 실제 태스크 수 워커 추가
MM2 페일오버 후 컨슈머가 처음부터 읽음 sync.group.offsets.enabled(기본 false) 오프셋 수동 리셋
롤링 재시작 후 특정 브로커만 CPU 높음 PreferredReplicaImbalanceCount 파티션 재할당

문항 유형 3종별 접근법

multiple-choice

matching (연결형)

list order (순서 배열)

반드시 외울 숫자

운영자 시험에서 확실하게 득점할 수 있는 부분입니다. 근사값으로 외우면 경계값 문항에서 틀립니다.

Kafka 4.3 기준 — 시험에 자주 나오는 값
항목값함정
message.max.bytes10485881MB(1048576)가 아닙니다. 압축 후 배치 기준
retention.ms604800000 (7일)segment.ms도 같은 값입니다
retention.bytes-1 (무제한)크기 리텐션은 기본적으로 꺼져 있습니다
log.segment.bytes1073741824 (1 GiB)—
log.retention.check.interval.ms300000 (5분)리텐션이 즉시 안 듣는 이유
num.partitions / default.replication.factor1 / 1자동 생성 토픽이 RF=1이 되는 원인
min.insync.replicas1RF=3이어도 기본값이면 acks=all이 리더 하나로 성공
unclean.leader.election.enablefalse—
replica.lag.time.max.ms30000read-only — 동적으로 못 바꿉니다
offsets.topic.replication.factor3브로커 3대 미만이면 실습에서 실패합니다
transaction.state.log.replication.factor / .min.isr3 / 2둘이 다릅니다
num.io.threads / num.network.threads8 / 3바꿔 놓은 오답이 자주 나옵니다
num.replica.fetchers1복제가 느릴 때 첫 후보
Idle percent 기준> 0.3유휴 비율이므로 높은 게 좋습니다
컨트롤러 수3 또는 5 (2N+1)4대는 3대와 내결함성이 같습니다
컨트롤러 리소스메모리 5GB · 디스크 5GB—
controller.quorum.fetch.timeout.ms2000election.timeout.ms는 1000
랙 분산min(랙 수, RF)나중에 broker.rack을 붙여도 기존 배치는 안 바뀝니다
파일 디스크립터최소 100000세그먼트 1개 = map area 2개
Java17 · 21 · 258은 4.0에서 제거. 브로커 최소 17
4.3 업그레이드 최소 버전3.3.x더 오래된 KRaft는 3.9.x 경유 권장
Connect 내부 토픽 파티션config 1 / offset 25 / status 5config는 반드시 1
scheduled.rebalance.max.delay.ms300000 (5분)워커 이탈 후 태스크가 5분간 미할당
tasks.max1Connect 스케일링 사고 1위
errors.tolerancenone첫 오류에 태스크 FAILED
MM2 replication.factor23이 아닙니다
MM2 sync.group.offsets.enabledfalse페일오버 사고의 원인
max.poll.interval.ms / max.poll.records300000 / 500리밸런스 스톰의 두 축
session.timeout.ms / heartbeat.interval.ms45000 / 3000세션은 3.x에서 10000이었습니다
group.protocolclassicKIP-848은 4.0 GA지만 기본값 아님
SCRAM 반복 횟수기본·최소 4096—
ssl.client.authnonemTLS를 켜도 이걸 안 바꾸면 인증 안 됩니다
sasl.enabled.mechanismsGSSAPISCRAM은 명시해야 열립니다
super.users 구분자세미콜론콤마가 아닙니다

선택지 소거 원칙

오답 유도 패턴과 식별법
패턴예식별법
순서를 뒤집은 선택지 "--verify 후 --execute" 절차 문항은 골격(확인 → 준비 → 실행 → 검증)에 맞는지 봅니다
비가역 조치를 앞세운 선택지 "먼저 unclean 선출을 활성화한다" 유실·삭제를 동반하는 조치는 첫 단계가 아닙니다
재시작으로 해결하는 선택지 "브로커를 재시작한다" 진단 단계를 건너뛴 조치입니다
설정 소속을 바꿔 놓은 선택지 컨슈머의 max.poll.records를 브로커 설정으로 서술 설정이 브로커/토픽/프로듀서/컨슈머 중 어디 것인지 확인합니다
기본값을 미묘하게 바꾼 선택지 1048576 / 30000 / RF 3 숫자 표를 그대로 외워 둡니다
인증과 인가를 섞은 선택지 "인증을 켰으니 ACL도 적용된다" 둘은 별개의 스위치입니다
현행이 아닌 아키텍처를 전제한 선택지 메타데이터를 외부 코디네이션 서비스에서 조회한다는 서술 4.x는 KRaft 전용입니다. 메타데이터는 __cluster_metadata에 있습니다
절대적 표현 "항상", "모든 경우에", "절대" Kafka는 거의 모든 동작에 조건이 붙습니다

시간 운영 — 문항 수를 모를 때

문항 수가 공개되지 않으므로 "문항당 몇 초"를 계산할 수 없습니다. 대신 진행률 기준으로 운영합니다.

  1. 1차 통과: 전체를 한 번 훑으며 즉시 답이 보이는 것만 답합니다. 망설이면 표시하고 넘어갑니다. 목표는 전체 시간의 절반 안에 끝까지 도달하는 것입니다.
  2. 2차 통과: 표시한 문항을 다시 봅니다. 시나리오 문항은 여기서 패턴표를 떠올려 풉니다.
  3. 3차 통과: 남은 시간에 list order와 matching을 재검토합니다. 이 두 유형은 한 칸만 어긋나도 전체가 틀리므로 검산 효과가 가장 큽니다.
  4. 빈칸을 남기지 않습니다. 오답 감점 정책은 공개되어 있지 않으므로 비워 두는 것이 이득일 근거가 없습니다.

최종 체크리스트

시험 직전 10분에 이것만 확인하세요. 하나라도 막히면 해당 섹션 페이지의 요약 표만 다시 봅니다.

섹션별 자기 점검 질문
섹션이 질문에 즉시 답할 수 있는가
Kafka Fundamentals high watermark는 어떻게 결정되는가. RF=3 · min.insync.replicas=2에서 브로커 2대를 잃으면 쓰기와 데이터는 각각 어떻게 되는가.
Kafka Security 4개 보안 프로토콜 중 자격증명이 평문으로 흐르는 것은. ACL이 없는 리소스의 기본 동작은.
Kafka Connect 죽은 워커의 태스크 예외를 어디서 보는가. 내부 토픽 3종의 파티션 요구는.
Deployment Architecture 컨트롤러 5대는 몇 대까지 잃어도 되는가. combined 모드가 권장되지 않는 이유는.
Cluster Configuration 재할당 3단계와 스로틀 해제 시점은. 파티션 수는 줄일 수 있는가.
Observability ActiveControllerCount의 정상값은. records-lag-max는 누가 발행하는가.
Troubleshooting 디스크가 찼을 때 가장 먼저 하는 것과 절대 하지 말아야 할 것은.

공식 문서 출처