Quiz Report Card: Kubernetes PKI List

Date: 2026-03-09 | Qwen 3.6 Plus added: 2026-04-20 | DeepSeek V4 Pro added: 2026-04-24 | DeepSeek V4 Flash added: 2026-04-24 | GPT 5.5 added: 2026-04-25 | Kimi K2.6 added: 2026-04-26 | Qwen3.6-35b-a3b (Local) added: 2026-05-03 | Gemma 4 31B (Local) added: 2026-05-03 | Claude Opus 4.8 added: 2026-05-31 Question: How many different root certificate authorities are created with a stock kubeadm Kubernetes cluster and what is the purpose of each one.

Reference Answer

A stock kubeadm cluster creates 3 root Certificate Authorities (each with a ca.crt/ca.key pair):

CA	Location	Purpose
Kubernetes CA	`/etc/kubernetes/pki/ca.crt`	Main cluster CA — signs API server cert, kubelet certs, scheduler/controller-manager client certs, admin kubeconfigs
etcd CA	`/etc/kubernetes/pki/etcd/ca.crt`	Dedicated to etcd — signs etcd server, peer, and client certs (including apiserver-etcd-client)
Front Proxy CA	`/etc/kubernetes/pki/front-proxy-ca.crt`	API aggregation layer — signs the front-proxy-client cert used when API server proxies to extension API servers

The service account key pair (sa.key/sa.pub) is also in the PKI directory but is not a certificate authority — it’s used for signing/verifying ServiceAccount JWT tokens. Mentioning it is fine as long as it’s not called a CA.

Scoring Criteria

Correct count: The answer is 3 root CAs
All three CAs identified: Kubernetes CA, etcd CA, Front Proxy CA
Correct purposes: Each CA’s purpose accurately described
Service account key pair: If mentioned, must be clearly distinguished as not a CA
No factual errors: Incorrect claims about what each CA signs are penalised

Results Summary

Model	Score	Count Correct	All 3 CAs	Purposes Accurate	SA Key Handled	Errors
anthropic/claude-opus-4.7	10/10	Yes (3)	Yes	Yes	Explicitly excluded	None
openai/gpt-5.4	9/10	Yes (3)	Yes	Yes	Correctly excluded	None
google/gemini-3-flash-preview	9/10	Yes (3)	Yes	Yes	Correctly excluded	None
anthropic/claude-sonnet-4.6	8/10	Confusing	Yes	Yes	Not mentioned	Muddled opening
minimax/minimax-m2.5	7/10	Effectively yes	Yes	Minor errors	Correctly excluded	SA token signing claim
minimax/minimax-m2.7	9/10	Yes (3)	Yes	Yes	Yes (not a CA)	None
deepseek/deepseek-v3.2	6/10	No (says 4)	Yes	Minor errors	Counted despite qualification	Headline answer wrong
qwen/qwen3.6-plus	10/10	Yes (3)	Yes	Yes	Explicitly excluded	None
deepseek/deepseek-v4-pro	9/10	Yes (3)	Yes	Yes	Correctly excluded	None
deepseek/deepseek-v4-flash	10/10	Yes (3)	Yes	Yes	Correctly excluded	None
moonshotai/kimi-k2.6	10/10	Yes (3)	Yes	Yes	Explicitly excluded	None
openai/gpt-5.5	10/10	Yes (3)	Yes	Yes	Explicitly excluded	None
qwen/qwen3.6-35b-a3b (LOCAL)	9/10	3/3	Yes	Yes	Minor path inaccuracy
anthropic/claude-opus-4.8	10/10	Yes (3)	Yes	Yes	Explicitly excluded	None
google/gemma-4-31b (LOCAL)	6/10	No (counts SA signer as 4th)	Yes	Partial	Calls SA signer a CA

Detailed Analysis

anthropic/claude-opus-4.7 — 10/10

Strengths:

Correctly identifies exactly 3 CAs: Kubernetes CA, etcd CA, Front Proxy CA
Correct file paths for all three CAs
Explicitly calls out sa.key/sa.pub as NOT a CA — the key trap, handled perfectly
Excellent security rationale for separate CAs (blast radius limitation)
No hedging or ambiguity

Weaknesses: None significant.

Comparison vs Opus 4.6 (9): Improvement. The explicit SA key pair disclaimer is exactly what the scoring rewards. First perfect score on this question.

Notable: The first perfect 10/10 on any quiz question across all models. The clean, unambiguous identification of exactly 3 CAs with explicit exclusion of the SA key pair is the ideal response.

openai/gpt-5.4 — 9/10

Strengths:

Clear final answer: “3 root CAs” — explicitly numbered and named
All three CAs correctly identified with accurate file locations
Each CA’s purpose is accurate and concise
Service account key pair handled perfectly: listed separately as item 4, explicitly labelled “not a certificate authority”, with clear explanation of what it actually does (sign/verify SA tokens)
Clean structure with definitive answer at the end

Weaknesses:

Opening hedges slightly (“sometimes effectively a 4th… depending on how you categorize things”) before arriving at the correct answer — minor
Could have explained the security rationale for separate CAs

Notable: The best handling of the service account key pair across all models — it’s exactly what the question calls for. Listed for completeness, clearly excluded from the CA count, purpose accurately described.

google/gemini-3-flash-preview — 9/10

Strengths:

Clear, definitive opening: “there are three distinct, independent Root Certificate Authorities”
All three CAs correctly identified with file locations and detailed purposes
Service account keys noted separately as “not technically a X.509 Certificate Authority and are not used for TLS”
Excellent security rationale for each CA’s separation (compromise isolation, “confused deputy” prevention for front proxy)
Good detail on what each CA specifically signs

Weaknesses:

Minor: the claim that ca.crt is “injected into every Pod via a Volume Mount” for Service Accounts conflates the CA certificate with the SA token mechanism — pods get the CA cert to verify the API server, not for SA token purposes specifically

Notable: The “confused deputy” explanation for the front proxy CA is the most insightful security rationale across all responses.

anthropic/claude-sonnet-4.6 — 8/10

Strengths:

All three CAs correctly identified with accurate file locations
Detailed and accurate description of what each CA signs
Good explanation of the principle of least privilege for CA separation
Front proxy CA purpose accurately described (API aggregation layer, extension API servers)

Weaknesses:

Confusing opening: “3 root Certificate Authorities (4 if etcd is configured, which it is by default)” — etcd is always present in stock kubeadm, so this reads as if the answer might be 3 or 4. The answer is always 3. This would confuse a reader.
Does not mention the service account key pair at all — neither positively nor negatively

Notable: Despite the muddled opening, the actual CA descriptions are among the most detailed. The “Why Separate CAs?” section with specific compromise scenarios is excellent.

minimax/minimax-m2.5 — 7/10

Strengths:

Lists 3 CAs plus the SA key pair — effectively arrives at the correct count
Service account key pair correctly noted as “not a CA in the traditional sense”
All three CAs identified with correct names and general purposes
etcd CA description is accurate

Weaknesses:

Claims the Kubernetes CA is used for “signing service account tokens” — this is incorrect. SA tokens are signed by sa.key, not the cluster CA. The CA cert (ca.crt) is included in pod mounts for API server TLS verification, but that’s different from token signing.
Claims Front Proxy CA signs “Front proxy server certificates” — the front proxy CA only signs the front-proxy-client certificate, not server certificates
These are minor but represent genuine factual inaccuracies about the PKI structure

Notable negative: The SA token signing claim is a common misconception. The cluster CA and the SA signing key are separate cryptographic entities with different purposes. Conflating them suggests imprecise understanding of the PKI.

minimax/minimax-m2.7 — 9/10

Strengths:

Correctly identifies all three root CAs (Kubernetes CA, etcd CA, Front Proxy CA) with the correct count of 3
Excellent detailed explanations of each CA’s purpose and what certificates it signs
Correctly notes the service account signing key is NOT a certificate authority — properly distinguished from the three CAs
Good file path table showing the location of each CA’s key pair
Explains the isolation purpose: why separate CAs exist for security compartmentalisation

Weaknesses:

Very minor — could have mentioned RSA-PSS for the SA signer as an additional detail

Notable: A very high-quality response demonstrating deep understanding of the kubeadm PKI structure. Matches the quality of GPT 5.4, Gemini 3 Flash, and Opus on this question. Represents a significant improvement over MiniMax M2.5 (which had the SA token signing error and scored 7/10). The correct handling of the SA key pair as “not a CA” is particularly notable given that MiniMax M2.5 incorrectly claimed the Kubernetes CA signs SA tokens.

deepseek/deepseek-v3.2 — 6/10

Strengths:

All three actual CAs correctly identified with file locations
Good descriptions of each CA’s purpose
SA key pair noted as “not a full X.509 CA”
Useful additional notes about HA etcd and custom CAs

Weaknesses:

Headline answer is wrong: “there are four main Certificate Authorities (CAs)” — the question asks how many root CAs, and the answer is 3, not 4
Despite qualifying the SA key pair later, the opening count and the final summary both say “four distinct CAs/key pairs” — the qualification doesn’t override the wrong count
Claims the main CA “signs front-proxy CA” — this is incorrect; the front-proxy CA is a self-signed root CA, not signed by the cluster CA
Claims the main CA is “involved in validation” of SA tokens — misleading (the SA public key validates tokens, not the CA)

Notable negative: When the question specifically asks “how many root certificate authorities”, answering “four” — even with qualifications — is the wrong answer. The SA key pair is explicitly not a CA, so including it in the count is an error. The response shows good knowledge of the individual components but fails the headline question.

qwen/qwen3.6-plus — 10/10

Strengths:

Correctly identifies exactly 3 root CAs: Cluster CA, etcd CA, Front-Proxy CA
Correct file paths for all three CAs including etcd subdirectory
Explicitly calls out sa.pub/sa.key as NOT a CA: “not a CA. It’s an RSA key pair used to sign/verify JWTs for ServiceAccount tokens. It doesn’t issue X.509 certificates” — handles the trap perfectly
Excellent security rationale: compartmentalisation with specific compromise scenarios for each CA
Additional clarification about kubelet server certs not having their own CA — prevents a common misconception
Notes leaf certificates are not CAs — thorough disambiguation

Weaknesses: None significant.

Notable: Joins Opus 4.7 as the second perfect 10/10 on this question. The explicit SA key pair disclaimer, kubelet cert clarification, and leaf certificate note demonstrate the most thorough PKI understanding across all models. The response leaves no room for misinterpretation.

deepseek/deepseek-v4-pro — 9/10

Strengths:

Correctly identifies all three CAs: cluster CA, etcd CA, front-proxy CA
Clear explanation of trust domain separation between CAs
Includes correct file paths for all three CAs
Correctly distinguishes the SA key pair from CAs

Weaknesses:

None significant

Notable: A major improvement over DeepSeek V3.2 (which scored 6/10 with an incorrect headline count of “four CAs”). V4 Pro correctly identifies exactly 3 CAs and properly excludes the SA key pair — matching GPT 5.4, Gemini 3 Flash, and MiniMax M2.7 at 9/10.

deepseek/deepseek-v4-flash — 10/10

Strengths:

Correctly identifies exactly 3 root CAs: Kubernetes CA, etcd CA, Front Proxy CA
All three CAs described with correct purposes and file paths
Service account key pair correctly excluded from the CA count
Clean, unambiguous presentation

Weaknesses: None significant.

Notable: A perfect score, joining Opus 4.7 and Qwen 3.6 Plus as the third model to achieve 10/10 on PKI List. Demonstrates strong understanding of kubeadm PKI architecture. This is V4 Flash’s strongest result across all quiz questions and a significant improvement over V3.2 (6/10, which incorrectly counted 4 CAs).

openai/gpt-5.5 — 10/10

Strengths:

Correctly identifies exactly 3 root CAs: Kubernetes cluster CA, etcd CA, Front proxy CA
Correct file paths for all three CAs including the etcd subdirectory
Detailed and accurate purpose descriptions: Kubernetes CA signs “API server and Kubernetes clients such as admin.conf, controller-manager.conf, scheduler.conf”; etcd CA signs “etcd server, peer, healthcheck-client, and API server etcd-client certificates”
Explicitly calls out sa.key/sa.pub as NOT a certificate authority: “that is not a certificate authority. It is used to sign and verify Kubernetes service account tokens” — handles the trap perfectly
Clean structure with table followed by summary list reinforcing the count
Correct note that etcd CA “is only created when kubeadm manages a local/stacked etcd cluster”

Weaknesses: None significant.

Notable: Joins Opus 4.7, Qwen 3.6 Plus, and DeepSeek V4 Flash as the fourth model to achieve a perfect 10/10 on PKI List. The explicit SA key pair disclaimer is precisely what the scoring rewards. The response is clean, unambiguous, and accurate throughout — a significant improvement over GPT 5.4 (9/10, which hedged slightly with “sometimes effectively a 4th” before arriving at 3).

moonshotai/kimi-k2.6 — 10/10

Strengths:

Correctly identifies exactly 3 root CAs: Kubernetes CA, etcd CA, Front Proxy CA
All three CAs described with correct purposes
Service account key pair explicitly identified as NOT a CA
Bonus mention of external etcd CA configuration

Weaknesses: None significant.

Notable: Joins Opus 4.7, Qwen 3.6 Plus, DeepSeek V4 Flash, and GPT 5.5 as the fifth model to achieve a perfect 10/10 on PKI List. The explicit SA key pair exclusion and external etcd bonus demonstrate strong PKI understanding.

qwen/qwen3.6-35b-a3b (LOCAL) — 9/10

Strengths:

Correctly identifies all 3 root CAs: Kubernetes CA, etcd CA, Front Proxy CA
Correctly excludes sa.key/sa.pub as not-a-CA — handles the trap well
Good explanation of etcd CA separation rationale (trust domain isolation)
Accurate descriptions of each CA’s purpose

Weaknesses:

Minor path inaccuracy in file locations — does not affect the conceptual understanding

Notable: An excellent result for a local 35B model — matches GPT 5.4, Gemini 3 Flash, MiniMax M2.7, and DeepSeek V4 Pro at 9/10. The PKI question tests well-structured factual knowledge that is well-represented in training data, which plays to the local model’s strengths. The correct SA key pair exclusion demonstrates precise understanding of the PKI architecture.

google/gemma-4-31b (LOCAL) — 6/10

Strengths:

Correctly identifies all three CAs: Kubernetes CA, etcd CA, Front Proxy CA
Accurate descriptions of each CA’s purpose
Good explanation of trust domain separation rationale

Weaknesses:

Calls the service account signer a “fourth CA” — the SA key pair (sa.key/sa.pub) is not a certificate authority. It is an RSA key pair used to sign/verify ServiceAccount JWTs. This is the trap the question is designed to test, and it falls for it — similar to DeepSeek V3.2’s error (which also counted “four CAs”).
Missing precise file path details

Notable: Matches DeepSeek V3.2 at 6/10 with the same type of SA key pair counting error. Unlike Qwen-35b (9/10) which correctly excluded the SA signer, Gemma 4 31B counts it as a CA, giving the wrong headline answer. This is a notable regression compared to the other local model tested.

anthropic/claude-opus-4.8 — 10/10

Strengths:

Correctly identifies exactly 3 CAs: Kubernetes CA, etcd CA, Front Proxy CA
Correct file paths for all three CAs
Explicitly and correctly states SA key pair is NOT a CA — handles the trap perfectly
Good security rationale for separate CAs (trust domain isolation)
No hedging or ambiguity

Weaknesses: None significant.

Comparison vs Opus 4.7 (10): Same perfect score. Both Opus 4.7 and 4.8 handle the SA key pair trap correctly with explicit exclusion.

Notable: Joins Opus 4.7, Qwen 3.6 Plus, DeepSeek V4 Flash, GPT 5.5, and Kimi K2.6 as the sixth model to achieve a perfect 10/10 on PKI List. The Anthropic family’s PKI knowledge is consistently strong — Opus 4.6 scored 9, and both Opus 4.7 and 4.8 score 10.

Key Findings

This is a precision question: The correct answer is specifically 3. Models that hedged or inflated the count lost marks even when they showed good underlying knowledge. Opus 4.7 achieved the first perfect 10/10 by being clean, unambiguous, and explicitly addressing the SA key pair trap.
GPT 5.4, Gemini 3 Flash, and Opus 4.7 gave the cleanest answers: All opened with a clear, correct count and maintained it throughout. All also handled the SA key pair correctly. Opus 4.7 went further with the most explicit SA exclusion.
The SA key pair is a useful discriminator: Models that mention it and correctly exclude it from the CA count (GPT 5.4, Gemini 3 Flash, MiniMax M2.5) demonstrate precise PKI understanding. DeepSeek V3.2 counted it despite the qualification.
Claude’s opening was unnecessarily confusing: The “3 (4 if etcd)” formulation muddles what should be a straightforward answer, even though the underlying knowledge is strong.
MiniMax M2.5’s SA token signing claim is a common misconception: The cluster CA doesn’t sign SA tokens — that’s sa.key’s job. This is a subtle but important distinction in the PKI architecture.
Front proxy CA is consistently well-understood: All five models correctly identified its purpose for the API aggregation layer. This is the CA most likely to trip up non-specialists, but all models handled it well.