Split View: [Golden Kubestronaut] KCSA 추가 실전 문제 30제 - 클라우드 네이티브 보안 심화
[Golden Kubestronaut] KCSA 추가 실전 문제 30제 - 클라우드 네이티브 보안 심화
- KCSA 추가 실전 문제 30제
- 문제 1. SLSA 프레임워크
- 문제 2. Sigstore 프로젝트
- 문제 3. in-toto 프레임워크
- 문제 4. Falco 런타임 보안
- 문제 5. Tetragon
- 문제 6. 제로 트러스트 네트워킹
- 문제 7. SPIFFE/SPIRE
- 문제 8. Vault와 Kubernetes 통합
- 문제 9. Cosign 이미지 서명
- 문제 10. Notation(Notary v2)
- 문제 11. SBOM(Software Bill of Materials)
- 문제 12. CycloneDX vs SPDX
- 문제 13. Admission Controller 개요
- 문제 14. Kyverno 정책 엔진
- 문제 15. OPA/Gatekeeper
- 문제 16. Pod Security Standards
- 문제 17. Pod Security Admission
- 문제 18. PodSecurityPolicy 지원 중단
- 문제 19. 네트워크 정책(NetworkPolicy)
- 문제 20. 시크릿 관리
- 문제 21. 이미지 스캐닝
- 문제 22. RBAC 최소 권한 원칙
- 문제 23. mTLS(상호 TLS)
- 문제 24. 감사 로그(Audit Logging)
- 문제 25. SecurityContext
- 문제 26. AppArmor와 Seccomp
- 문제 27. 이미지 정책
- 문제 28. ServiceAccount 보안
- 문제 29. 컨테이너 격리
- 문제 30. 보안 모범 사례 종합
- 마무리
KCSA 추가 실전 문제 30제
KCSA 시험의 핵심 도메인인 공급망 보안, 런타임 보안, 제로 트러스트 네트워킹, 이미지 검증, 정책 엔진, Pod 보안을 심화 학습하기 위한 추가 문제 30제입니다.
문제 1. SLSA 프레임워크
SLSA(Supply-chain Levels for Software Artifacts) 프레임워크의 주요 목적은?
- A) 컨테이너 런타임 성능을 최적화한다
- B) 소프트웨어 공급망의 무결성을 보장하기 위한 보안 수준을 정의한다
- C) Kubernetes 클러스터의 네트워크 정책을 관리한다
- D) 컨테이너 이미지의 크기를 줄인다
정답 및 해설
정답: B) 소프트웨어 공급망의 무결성을 보장하기 위한 보안 수준을 정의한다
SLSA는 소프트웨어 공급망 공격을 방지하기 위한 보안 프레임워크로, Build Level 0부터 Level 3까지의 보안 수준을 정의합니다. 빌드 프로세스의 출처(provenance) 추적, 변조 방지, 격리된 빌드 환경 등을 요구합니다.
문제 2. Sigstore 프로젝트
Sigstore의 핵심 구성 요소가 아닌 것은?
- A) Cosign - 컨테이너 이미지 서명
- B) Fulcio - 단기 인증서 발급 CA
- C) Rekor - 투명성 로그
- D) Falco - 런타임 위협 탐지
정답 및 해설
정답: D) Falco - 런타임 위협 탐지
Sigstore는 Cosign(이미지/아티팩트 서명), Fulcio(키리스 서명을 위한 단기 인증서 발급), Rekor(서명 투명성 로그)로 구성됩니다. Falco는 런타임 보안 도구로 Sigstore와는 별개의 CNCF 프로젝트입니다.
문제 3. in-toto 프레임워크
in-toto가 보호하는 대상은?
- A) 런타임 컨테이너의 메모리 접근
- B) 소프트웨어 공급망의 전체 프로세스(레이아웃과 링크를 통한 단계별 검증)
- C) Kubernetes API 서버의 인증
- D) 네트워크 트래픽의 암호화
정답 및 해설
정답: B) 소프트웨어 공급망의 전체 프로세스(레이아웃과 링크를 통한 단계별 검증)
in-toto는 소프트웨어 공급망의 전체 과정을 보호하는 프레임워크입니다. 레이아웃(layout)으로 공급망의 예상 단계를 정의하고, 링크(link) 메타데이터로 각 단계의 실제 수행을 기록하여 변조를 탐지합니다.
문제 4. Falco 런타임 보안
Falco가 시스템 이벤트를 감지하는 주요 메커니즘은?
- A) 컨테이너 이미지를 정적 분석한다
- B) eBPF 또는 커널 모듈을 통해 시스템 콜을 실시간으로 모니터링한다
- C) Kubernetes API를 폴링하여 리소스 변경을 감지한다
- D) 네트워크 패킷을 캡처하여 분석한다
정답 및 해설
정답: B) eBPF 또는 커널 모듈을 통해 시스템 콜을 실시간으로 모니터링한다
Falco는 eBPF 프로브 또는 커널 모듈을 사용하여 시스템 콜을 실시간으로 모니터링하고, YAML 기반 규칙에 따라 비정상적인 행위(예: 예기치 않은 셸 실행, 민감한 파일 접근)를 탐지합니다.
문제 5. Tetragon
Cilium Tetragon의 차별화된 기능은?
- A) 컨테이너 이미지 빌드 자동화
- B) eBPF 기반으로 커널 레벨에서 보안 정책을 적용하고 프로세스를 즉시 차단할 수 있다
- C) Kubernetes 매니페스트의 정적 분석
- D) SSL 인증서 자동 갱신
정답 및 해설
정답: B) eBPF 기반으로 커널 레벨에서 보안 정책을 적용하고 프로세스를 즉시 차단할 수 있다
Tetragon은 Cilium 프로젝트의 eBPF 기반 보안 관찰성 및 런타임 강제 도구입니다. Falco와 달리 탐지뿐 아니라 커널 레벨에서 직접 프로세스를 차단(kill)할 수 있는 런타임 강제(enforcement) 기능을 제공합니다.
문제 6. 제로 트러스트 네트워킹
제로 트러스트(Zero Trust) 보안 모델의 핵심 원칙은?
- A) 내부 네트워크는 항상 신뢰할 수 있다
- B) 네트워크 위치에 관계없이 모든 요청을 검증하고 최소 권한을 부여한다
- C) 방화벽만으로 충분한 보안을 제공한다
- D) VPN을 사용하면 모든 트래픽이 안전하다
정답 및 해설
정답: B) 네트워크 위치에 관계없이 모든 요청을 검증하고 최소 권한을 부여한다
제로 트러스트 모델은 "절대 신뢰하지 않고, 항상 검증한다(Never Trust, Always Verify)"를 원칙으로 합니다. 네트워크 경계 내부라도 모든 요청에 대해 인증, 인가, 암호화를 요구하며 최소 권한 원칙을 적용합니다.
문제 7. SPIFFE/SPIRE
SPIFFE(Secure Production Identity Framework for Everyone)의 핵심 개념은?
- A) DNS 기반 서비스 디스커버리
- B) 워크로드에 통일된 ID(SPIFFE ID)를 부여하고 SVID를 통해 인증한다
- C) 컨테이너 이미지 스캐닝
- D) 네트워크 세그먼테이션
정답 및 해설
정답: B) 워크로드에 통일된 ID(SPIFFE ID)를 부여하고 SVID를 통해 인증한다
SPIFFE는 워크로드에 플랫폼 독립적인 ID(spiffe://trust-domain/path 형식)를 부여하는 표준입니다. SPIRE는 SPIFFE의 참조 구현체로, X.509 SVID 또는 JWT SVID를 발급하여 워크로드 간 mTLS 인증을 가능하게 합니다.
문제 8. Vault와 Kubernetes 통합
HashiCorp Vault를 Kubernetes와 통합할 때 가장 일반적인 인증 방식은?
- A) 사용자 이름/비밀번호
- B) Kubernetes Auth Method (ServiceAccount 토큰 기반)
- C) SSH 키 인증
- D) LDAP 인증
정답 및 해설
정답: B) Kubernetes Auth Method (ServiceAccount 토큰 기반)
Vault의 Kubernetes Auth Method는 Pod의 ServiceAccount 토큰을 사용하여 Vault에 인증합니다. Vault Agent Injector 또는 CSI Provider를 통해 시크릿을 Pod에 주입할 수 있으며, 동적 시크릿 관리가 가능합니다.
문제 9. Cosign 이미지 서명
cosign으로 컨테이너 이미지를 서명할 때 "Keyless Signing"이 의미하는 것은?
- A) 서명 없이 이미지를 배포한다
- B) OIDC 기반 ID를 사용하여 장기 키 관리 없이 단기 인증서로 서명한다
- C) 이미지를 암호화하지 않는다
- D) 공개 키만 사용하여 서명한다
정답 및 해설
정답: B) OIDC 기반 ID를 사용하여 장기 키 관리 없이 단기 인증서로 서명한다
Keyless Signing은 Fulcio CA에서 OIDC 인증(예: Google, GitHub)을 통해 단기 서명 인증서를 발급받아 서명하고, Rekor 투명성 로그에 기록합니다. 장기 개인 키를 관리할 필요가 없어 키 관리 부담을 제거합니다.
문제 10. Notation(Notary v2)
Notation(Notary v2)의 주요 역할은?
- A) Kubernetes 클러스터 백업
- B) OCI 아티팩트에 서명하고 검증하기 위한 표준 도구
- C) Pod 네트워크 정책 관리
- D) 로그 수집 및 분석
정답 및 해설
정답: B) OCI 아티팩트에 서명하고 검증하기 위한 표준 도구
Notation은 OCI 이미지 및 아티팩트에 대한 서명과 검증을 위한 CLI 도구이자 라이브러리입니다. 플러그인 확장 모델을 지원하며, Azure Key Vault, AWS Signer 등의 KMS와 통합할 수 있습니다.
문제 11. SBOM(Software Bill of Materials)
SBOM의 주요 목적은?
- A) 컨테이너의 CPU 사용량을 추적한다
- B) 소프트웨어에 포함된 모든 구성 요소(라이브러리, 의존성)의 목록을 제공하여 취약점 관리를 지원한다
- C) 네트워크 트래픽을 모니터링한다
- D) Kubernetes 리소스 할당량을 관리한다
정답 및 해설
정답: B) 소프트웨어에 포함된 모든 구성 요소(라이브러리, 의존성)의 목록을 제공하여 취약점 관리를 지원한다
SBOM은 소프트웨어의 "재료 목록"으로, 포함된 모든 컴포넌트와 버전을 문서화합니다. 새로운 CVE가 발견되면 SBOM을 통해 영향받는 소프트웨어를 빠르게 식별할 수 있습니다.
문제 12. CycloneDX vs SPDX
CycloneDX와 SPDX의 공통점은?
- A) 둘 다 컨테이너 런타임이다
- B) 둘 다 SBOM 형식 표준이다
- C) 둘 다 서비스 메시 구현체이다
- D) 둘 다 Kubernetes 배포 도구이다
정답 및 해설
정답: B) 둘 다 SBOM 형식 표준이다
CycloneDX(OWASP)와 SPDX(Linux Foundation)는 모두 SBOM을 생성하기 위한 표준 형식입니다. SPDX는 라이선스 컴플라이언스에 초점이 있고, CycloneDX는 보안과 취약점 분석에 최적화되어 있습니다.
문제 13. Admission Controller 개요
Kubernetes Admission Controller의 실행 순서로 올바른 것은?
- A) Mutating -> Validating -> Object Persistence
- B) Validating -> Mutating -> Object Persistence
- C) Object Persistence -> Mutating -> Validating
- D) Mutating -> Object Persistence -> Validating
정답 및 해설
정답: A) Mutating -> Validating -> Object Persistence
Kubernetes API 요청은 인증/인가 후 먼저 MutatingAdmissionWebhook을 거쳐 리소스를 변형(수정)하고, 그 다음 ValidatingAdmissionWebhook으로 유효성을 검증한 후 etcd에 저장됩니다.
문제 14. Kyverno 정책 엔진
Kyverno가 OPA/Gatekeeper와 차별화되는 점은?
- A) Rego 언어를 사용한다
- B) YAML 기반으로 정책을 정의하며, 검증 외에 변형(mutate)과 생성(generate) 기능을 제공한다
- C) Kubernetes 외부에서만 동작한다
- D) 정책 감사 기능이 없다
정답 및 해설
정답: B) YAML 기반으로 정책을 정의하며, 검증 외에 변형(mutate)과 생성(generate) 기능을 제공한다
Kyverno는 Kubernetes 네이티브 정책 엔진으로, YAML과 CEL로 정책을 정의합니다. validate(검증), mutate(변형), generate(리소스 생성), verifyImages(이미지 검증) 규칙을 지원합니다.
문제 15. OPA/Gatekeeper
OPA(Open Policy Agent) Gatekeeper에서 정책을 정의하는 데 사용하는 언어는?
- A) YAML
- B) JSON
- C) Rego
- D) Python
정답 및 해설
정답: C) Rego
OPA는 범용 정책 엔진으로, Rego라는 선언적 쿼리 언어를 사용하여 정책을 정의합니다. Gatekeeper는 OPA를 Kubernetes에 통합한 것으로, ConstraintTemplate에 Rego로 정책 로직을 작성합니다.
문제 16. Pod Security Standards
Kubernetes Pod Security Standards의 세 가지 정책 수준은?
- A) Low, Medium, High
- B) Privileged, Baseline, Restricted
- C) Open, Default, Strict
- D) Allow, Warn, Deny
정답 및 해설
정답: B) Privileged, Baseline, Restricted
Pod Security Standards는 Privileged(무제한), Baseline(최소한의 제한으로 알려진 권한 상승 방지), Restricted(최대 보안으로 Pod 하드닝 모범 사례 적용) 세 단계를 정의합니다.
문제 17. Pod Security Admission
Pod Security Admission에서 사용하는 세 가지 모드는?
- A) allow, block, audit
- B) enforce, audit, warn
- C) accept, reject, log
- D) permit, deny, monitor
정답 및 해설
정답: B) enforce, audit, warn
Pod Security Admission은 enforce(위반 시 거부), audit(위반을 감사 로그에 기록), warn(위반 시 경고 메시지 표시) 세 가지 모드를 지원합니다. 네임스페이스 레이블로 적용합니다.
문제 18. PodSecurityPolicy 지원 중단
PodSecurityPolicy(PSP)가 Kubernetes에서 제거된 이유로 가장 적절한 것은?
- A) 성능이 너무 느렸다
- B) 사용법이 복잡하고, RBAC 바인딩이 혼란스러우며, 적용 범위가 예측하기 어려웠다
- C) 보안 기능이 부족했다
- D) 오직 하나의 클라우드 프로바이더만 지원했다
정답 및 해설
정답: B) 사용법이 복잡하고, RBAC 바인딩이 혼란스러우며, 적용 범위가 예측하기 어려웠다
PSP는 RBAC를 통한 바인딩 메커니즘이 직관적이지 않았고, 어떤 PSP가 어떤 Pod에 적용되는지 예측이 어려웠습니다. Kubernetes 1.25에서 제거되었으며, Pod Security Admission, Kyverno, OPA/Gatekeeper가 대체합니다.
문제 19. 네트워크 정책(NetworkPolicy)
Kubernetes NetworkPolicy에 대한 올바른 설명은?
- A) NetworkPolicy가 없으면 모든 트래픽이 차단된다
- B) NetworkPolicy가 없으면 모든 트래픽이 허용되며, 정책이 적용되면 명시적으로 허용된 트래픽만 통과한다
- C) NetworkPolicy는 노드 간 통신만 제어한다
- D) 모든 CNI 플러그인이 NetworkPolicy를 지원한다
정답 및 해설
정답: B) NetworkPolicy가 없으면 모든 트래픽이 허용되며, 정책이 적용되면 명시적으로 허용된 트래픽만 통과한다
기본적으로 Kubernetes는 모든 Pod 간 통신을 허용합니다. NetworkPolicy를 적용하면 선택된 Pod에 대해 명시적으로 허용된 인그레스/이그레스 트래픽만 통과합니다. 단, CNI 플러그인이 NetworkPolicy를 지원해야 합니다.
문제 20. 시크릿 관리
Kubernetes Secret의 기본 저장 방식에 대한 올바른 설명은?
- A) 기본적으로 AES-256으로 암호화되어 etcd에 저장된다
- B) 기본적으로 Base64 인코딩만 되어 etcd에 저장되며, 암호화하려면 EncryptionConfiguration을 별도 설정해야 한다
- C) Secret은 메모리에만 저장되고 디스크에 기록되지 않는다
- D) Secret은 자동으로 Vault에 저장된다
정답 및 해설
정답: B) 기본적으로 Base64 인코딩만 되어 etcd에 저장되며, 암호화하려면 EncryptionConfiguration을 별도 설정해야 한다
Kubernetes Secret은 기본적으로 Base64 인코딩된 상태로 etcd에 저장됩니다. 이는 암호화가 아니므로, etcd 접근 권한이 있으면 시크릿을 읽을 수 있습니다. 정적 암호화를 위해 EncryptionConfiguration을 설정하거나, KMS 프로바이더를 사용해야 합니다.
문제 21. 이미지 스캐닝
컨테이너 이미지 취약점 스캐닝 도구가 아닌 것은?
- A) Trivy
- B) Grype
- C) Clair
- D) Helm
정답 및 해설
정답: D) Helm
Trivy(Aqua Security), Grype(Anchore), Clair(Quay)는 모두 컨테이너 이미지 취약점 스캐닝 도구입니다. Helm은 Kubernetes 패키지 매니저로 보안 스캐닝과는 관련이 없습니다.
문제 22. RBAC 최소 권한 원칙
RBAC에서 최소 권한 원칙을 적용할 때 올바른 접근 방식은?
- A) 모든 ServiceAccount에 cluster-admin 역할을 부여한다
- B) 필요한 리소스와 동사(verbs)만 포함하는 Role을 생성하고 최소 범위의 RoleBinding을 사용한다
- C) ClusterRole만 사용하고 네임스페이스 Role은 사용하지 않는다
- D) 와일드카드(*)를 사용하여 모든 리소스에 접근을 허용한다
정답 및 해설
정답: B) 필요한 리소스와 동사(verbs)만 포함하는 Role을 생성하고 최소 범위의 RoleBinding을 사용한다
최소 권한 원칙은 필요한 최소한의 권한만 부여하는 것입니다. 특정 리소스의 특정 동사만 허용하는 Role을 만들고, 해당 네임스페이스에만 적용하는 RoleBinding을 사용합니다. 와일드카드 사용과 cluster-admin 남용을 피해야 합니다.
문제 23. mTLS(상호 TLS)
서비스 메시에서 mTLS의 역할은?
- A) 서비스 간 통신을 압축한다
- B) 서버와 클라이언트 양쪽 모두 인증서로 상호 인증하고 통신을 암호화한다
- C) DNS 쿼리를 암호화한다
- D) 로드밸런싱을 수행한다
정답 및 해설
정답: B) 서버와 클라이언트 양쪽 모두 인증서로 상호 인증하고 통신을 암호화한다
mTLS(mutual TLS)는 서버뿐 아니라 클라이언트도 인증서를 제시하여 양방향 인증을 수행합니다. Istio, Linkerd 등의 서비스 메시는 사이드카 프록시를 통해 서비스 간 mTLS를 자동으로 적용합니다.
문제 24. 감사 로그(Audit Logging)
Kubernetes 감사 로그의 레벨 중 가장 상세한 정보를 기록하는 것은?
- A) None
- B) Metadata
- C) Request
- D) RequestResponse
정답 및 해설
정답: D) RequestResponse
Kubernetes 감사 로그는 None(기록 없음), Metadata(요청 메타데이터만), Request(메타데이터 + 요청 본문), RequestResponse(메타데이터 + 요청 + 응답 본문) 4단계를 지원합니다. RequestResponse가 가장 상세합니다.
문제 25. SecurityContext
Pod 레벨 SecurityContext에서 설정할 수 있는 항목이 아닌 것은?
- A) runAsUser
- B) fsGroup
- C) networkPolicy
- D) runAsNonRoot
정답 및 해설
정답: C) networkPolicy
Pod SecurityContext에서는 runAsUser, runAsNonRoot, runAsGroup, fsGroup, supplementalGroups, sysctls, seccompProfile 등을 설정할 수 있습니다. NetworkPolicy는 별도의 Kubernetes 리소스로 SecurityContext와는 관련이 없습니다.
문제 26. AppArmor와 Seccomp
Seccomp 프로파일의 역할은?
- A) 파일 시스템 접근을 제어한다
- B) 컨테이너가 사용할 수 있는 시스템 콜을 필터링한다
- C) 네트워크 트래픽을 제한한다
- D) CPU 사용량을 제한한다
정답 및 해설
정답: B) 컨테이너가 사용할 수 있는 시스템 콜을 필터링한다
Seccomp(Secure Computing Mode)은 프로세스가 호출할 수 있는 시스템 콜을 허용 목록 또는 차단 목록으로 필터링합니다. Kubernetes에서는 seccompProfile을 통해 RuntimeDefault 또는 커스텀 프로파일을 적용할 수 있습니다.
문제 27. 이미지 정책
Kubernetes에서 신뢰할 수 있는 이미지만 실행하도록 강제하는 방법은?
- A) 모든 이미지에 latest 태그를 사용한다
- B) Admission Controller(Kyverno, OPA)를 통해 서명된 이미지만 허용하는 정책을 적용한다
- C) 공용 레지스트리에서만 이미지를 가져온다
- D) imagePullPolicy를 Never로 설정한다
정답 및 해설
정답: B) Admission Controller(Kyverno, OPA)를 통해 서명된 이미지만 허용하는 정책을 적용한다
Kyverno의 verifyImages 규칙이나 OPA/Gatekeeper의 ConstraintTemplate을 사용하여 cosign 서명 또는 Notation 서명이 검증된 이미지만 배포를 허용할 수 있습니다. 이는 공급망 보안의 핵심 요소입니다.
문제 28. ServiceAccount 보안
Kubernetes 1.24 이후 ServiceAccount 토큰 관리의 변경 사항은?
- A) ServiceAccount 토큰이 완전히 제거되었다
- B) 자동 마운트되는 영구 토큰이 더 이상 생성되지 않으며, TokenRequest API를 통한 단기 토큰 사용이 권장된다
- C) 모든 Pod에 cluster-admin 토큰이 자동 마운트된다
- D) ServiceAccount가 더 이상 존재하지 않는다
정답 및 해설
정답: B) 자동 마운트되는 영구 토큰이 더 이상 생성되지 않으며, TokenRequest API를 통한 단기 토큰 사용이 권장된다
Kubernetes 1.24부터 ServiceAccount 생성 시 자동으로 Secret이 생성되지 않습니다. 대신 TokenRequest API를 통해 시간 제한이 있는 단기 토큰을 발급받는 방식이 권장되어 보안이 강화되었습니다.
문제 29. 컨테이너 격리
gVisor와 Kata Containers가 제공하는 보안 이점은?
- A) 네트워크 암호화
- B) 커널을 공유하지 않거나 추가 격리 레이어를 통해 컨테이너 이스케이프 위험을 줄인다
- C) 이미지 서명 검증
- D) RBAC 정책 강화
정답 및 해설
정답: B) 커널을 공유하지 않거나 추가 격리 레이어를 통해 컨테이너 이스케이프 위험을 줄인다
gVisor는 사용자 공간 커널(application kernel)을 제공하여 호스트 커널과의 직접 시스템 콜을 차단합니다. Kata Containers는 경량 VM 내에서 컨테이너를 실행하여 하드웨어 레벨 격리를 제공합니다. 두 기술 모두 RuntimeClass를 통해 선택적으로 사용합니다.
문제 30. 보안 모범 사례 종합
다계층 방어(Defense in Depth) 전략에 해당하지 않는 것은?
- A) 이미지 스캐닝 + 서명 검증
- B) NetworkPolicy + mTLS
- C) RBAC + Pod Security Standards
- D) 모든 워크로드를 root로 실행하고 privileged 모드를 사용
정답 및 해설
정답: D) 모든 워크로드를 root로 실행하고 privileged 모드를 사용
다계층 방어는 여러 보안 계층을 중첩하여 하나의 계층이 실패해도 다른 계층이 보호하는 전략입니다. 이미지 보안, 네트워크 보안, 접근 제어, 런타임 보안을 결합합니다. root 실행과 privileged 모드는 보안 모범 사례에 반합니다.
마무리
이 30문제는 KCSA 시험의 핵심 도메인인 공급망 보안, 런타임 보안, 플랫폼 보안, 네트워크 보안, 컴플라이언스와 보안 프레임워크를 심화 학습하기 위해 구성되었습니다. 실제 시험에서는 Kubernetes 보안 메커니즘뿐 아니라 CNCF 보안 생태계 전반에 대한 이해가 요구됩니다.
[Golden Kubestronaut] KCSA Extra 30 Practice Questions - Advanced Cloud Native Security
- KCSA Extra 30 Practice Questions
- Question 1. SLSA Framework
- Question 2. Sigstore Project
- Question 3. in-toto Framework
- Question 4. Falco Runtime Security
- Question 5. Tetragon
- Question 6. Zero Trust Networking
- Question 7. SPIFFE/SPIRE
- Question 8. Vault and Kubernetes Integration
- Question 9. Cosign Image Signing
- Question 10. Notation (Notary v2)
- Question 11. SBOM (Software Bill of Materials)
- Question 12. CycloneDX vs SPDX
- Question 13. Admission Controller Overview
- Question 14. Kyverno Policy Engine
- Question 15. OPA/Gatekeeper
- Question 16. Pod Security Standards
- Question 17. Pod Security Admission
- Question 18. PodSecurityPolicy Deprecation
- Question 19. Network Policy
- Question 20. Secret Management
- Question 21. Image Scanning
- Question 22. RBAC Least Privilege Principle
- Question 23. mTLS (Mutual TLS)
- Question 24. Audit Logging
- Question 25. SecurityContext
- Question 26. AppArmor and Seccomp
- Question 27. Image Policy
- Question 28. ServiceAccount Security
- Question 29. Container Isolation
- Question 30. Comprehensive Security Best Practices
- Summary
KCSA Extra 30 Practice Questions
These 30 additional questions cover the key KCSA exam domains: supply chain security, runtime security, zero trust networking, image verification, policy engines, and Pod security.
Question 1. SLSA Framework
What is the primary purpose of the SLSA (Supply-chain Levels for Software Artifacts) framework?
- A) Optimizes container runtime performance
- B) Defines security levels to ensure the integrity of the software supply chain
- C) Manages Kubernetes cluster network policies
- D) Reduces container image sizes
Answer and Explanation
Answer: B) Defines security levels to ensure the integrity of the software supply chain
SLSA is a security framework designed to prevent software supply chain attacks, defining security levels from Build Level 0 to Level 3. It requires provenance tracking of build processes, tamper prevention, and isolated build environments.
Question 2. Sigstore Project
Which is NOT a core component of Sigstore?
- A) Cosign - container image signing
- B) Fulcio - short-lived certificate issuing CA
- C) Rekor - transparency log
- D) Falco - runtime threat detection
Answer and Explanation
Answer: D) Falco - runtime threat detection
Sigstore consists of Cosign (image/artifact signing), Fulcio (short-lived certificate issuance for keyless signing), and Rekor (signature transparency log). Falco is a runtime security tool and a separate CNCF project.
Question 3. in-toto Framework
What does in-toto protect?
- A) Runtime container memory access
- B) The entire software supply chain process through layouts and links for step-by-step verification
- C) Kubernetes API server authentication
- D) Network traffic encryption
Answer and Explanation
Answer: B) The entire software supply chain process through layouts and links for step-by-step verification
in-toto protects the entire software supply chain process. Layouts define the expected steps of the supply chain, and link metadata records the actual execution of each step to detect tampering.
Question 4. Falco Runtime Security
What is the primary mechanism Falco uses to detect system events?
- A) Static analysis of container images
- B) Real-time monitoring of system calls through eBPF or kernel modules
- C) Polling Kubernetes API for resource changes
- D) Capturing and analyzing network packets
Answer and Explanation
Answer: B) Real-time monitoring of system calls through eBPF or kernel modules
Falco uses eBPF probes or kernel modules to monitor system calls in real-time and detects abnormal behavior (e.g., unexpected shell execution, sensitive file access) based on YAML-based rules.
Question 5. Tetragon
What differentiates Cilium Tetragon?
- A) Container image build automation
- B) Applies security policies at the kernel level using eBPF and can immediately terminate processes
- C) Static analysis of Kubernetes manifests
- D) Automatic SSL certificate renewal
Answer and Explanation
Answer: B) Applies security policies at the kernel level using eBPF and can immediately terminate processes
Tetragon is an eBPF-based security observability and runtime enforcement tool from the Cilium project. Unlike Falco, which focuses on detection, Tetragon can directly kill processes at the kernel level, providing runtime enforcement capabilities.
Question 6. Zero Trust Networking
What is the core principle of the Zero Trust security model?
- A) The internal network is always trustworthy
- B) Verify every request regardless of network location and grant least privilege
- C) Firewalls alone provide sufficient security
- D) Using a VPN makes all traffic safe
Answer and Explanation
Answer: B) Verify every request regardless of network location and grant least privilege
The Zero Trust model follows the principle of "Never Trust, Always Verify." It requires authentication, authorization, and encryption for all requests even within the network perimeter, applying the principle of least privilege.
Question 7. SPIFFE/SPIRE
What is the core concept of SPIFFE (Secure Production Identity Framework for Everyone)?
- A) DNS-based service discovery
- B) Assigns unified IDs (SPIFFE IDs) to workloads and authenticates through SVIDs
- C) Container image scanning
- D) Network segmentation
Answer and Explanation
Answer: B) Assigns unified IDs (SPIFFE IDs) to workloads and authenticates through SVIDs
SPIFFE is a standard that assigns platform-independent IDs (in spiffe://trust-domain/path format) to workloads. SPIRE is the reference implementation that issues X.509 SVIDs or JWT SVIDs, enabling mTLS authentication between workloads.
Question 8. Vault and Kubernetes Integration
What is the most common authentication method when integrating HashiCorp Vault with Kubernetes?
- A) Username/password
- B) Kubernetes Auth Method (ServiceAccount token-based)
- C) SSH key authentication
- D) LDAP authentication
Answer and Explanation
Answer: B) Kubernetes Auth Method (ServiceAccount token-based)
Vault's Kubernetes Auth Method uses the Pod's ServiceAccount token to authenticate with Vault. Secrets can be injected into Pods via the Vault Agent Injector or CSI Provider, enabling dynamic secret management.
Question 9. Cosign Image Signing
What does "Keyless Signing" mean when signing container images with cosign?
- A) Deploying images without signatures
- B) Using OIDC-based identity to sign with short-lived certificates without long-term key management
- C) Not encrypting the image
- D) Only using a public key to sign
Answer and Explanation
Answer: B) Using OIDC-based identity to sign with short-lived certificates without long-term key management
Keyless Signing obtains a short-lived signing certificate from Fulcio CA through OIDC authentication (e.g., Google, GitHub), signs the artifact, and records it in the Rekor transparency log. This eliminates the need for long-term private key management.
Question 10. Notation (Notary v2)
What is the primary role of Notation (Notary v2)?
- A) Kubernetes cluster backup
- B) A standard tool for signing and verifying OCI artifacts
- C) Pod network policy management
- D) Log collection and analysis
Answer and Explanation
Answer: B) A standard tool for signing and verifying OCI artifacts
Notation is a CLI tool and library for signing and verifying OCI images and artifacts. It supports a plugin extension model and can integrate with KMS services like Azure Key Vault and AWS Signer.
Question 11. SBOM (Software Bill of Materials)
What is the primary purpose of SBOM?
- A) Tracks container CPU usage
- B) Provides a list of all components (libraries, dependencies) included in software to support vulnerability management
- C) Monitors network traffic
- D) Manages Kubernetes resource quotas
Answer and Explanation
Answer: B) Provides a list of all components (libraries, dependencies) included in software to support vulnerability management
SBOM is a "bill of materials" for software that documents all included components and their versions. When new CVEs are discovered, SBOMs enable rapid identification of affected software.
Question 12. CycloneDX vs SPDX
What do CycloneDX and SPDX have in common?
- A) Both are container runtimes
- B) Both are SBOM format standards
- C) Both are service mesh implementations
- D) Both are Kubernetes deployment tools
Answer and Explanation
Answer: B) Both are SBOM format standards
CycloneDX (OWASP) and SPDX (Linux Foundation) are both standard formats for creating SBOMs. SPDX focuses on license compliance, while CycloneDX is optimized for security and vulnerability analysis.
Question 13. Admission Controller Overview
What is the correct execution order of Kubernetes Admission Controllers?
- A) Mutating -> Validating -> Object Persistence
- B) Validating -> Mutating -> Object Persistence
- C) Object Persistence -> Mutating -> Validating
- D) Mutating -> Object Persistence -> Validating
Answer and Explanation
Answer: A) Mutating -> Validating -> Object Persistence
After authentication and authorization, Kubernetes API requests first pass through MutatingAdmissionWebhooks to modify resources, then ValidatingAdmissionWebhooks for validation, and finally are persisted to etcd.
Question 14. Kyverno Policy Engine
What differentiates Kyverno from OPA/Gatekeeper?
- A) Uses the Rego language
- B) Defines policies in YAML, providing mutation and generation capabilities in addition to validation
- C) Only works outside Kubernetes
- D) Has no policy auditing capability
Answer and Explanation
Answer: B) Defines policies in YAML, providing mutation and generation capabilities in addition to validation
Kyverno is a Kubernetes-native policy engine that defines policies in YAML and CEL. It supports validate, mutate, generate, and verifyImages rule types.
Question 15. OPA/Gatekeeper
What language is used to define policies in OPA (Open Policy Agent) Gatekeeper?
- A) YAML
- B) JSON
- C) Rego
- D) Python
Answer and Explanation
Answer: C) Rego
OPA is a general-purpose policy engine that uses Rego, a declarative query language, to define policies. Gatekeeper integrates OPA with Kubernetes, with policy logic written in Rego within ConstraintTemplates.
Question 16. Pod Security Standards
What are the three policy levels of Kubernetes Pod Security Standards?
- A) Low, Medium, High
- B) Privileged, Baseline, Restricted
- C) Open, Default, Strict
- D) Allow, Warn, Deny
Answer and Explanation
Answer: B) Privileged, Baseline, Restricted
Pod Security Standards define three levels: Privileged (unrestricted), Baseline (minimal restrictions to prevent known privilege escalation), and Restricted (maximum security applying Pod hardening best practices).
Question 17. Pod Security Admission
What are the three modes used in Pod Security Admission?
- A) allow, block, audit
- B) enforce, audit, warn
- C) accept, reject, log
- D) permit, deny, monitor
Answer and Explanation
Answer: B) enforce, audit, warn
Pod Security Admission supports three modes: enforce (reject violations), audit (record violations in audit logs), and warn (display warning messages for violations). They are applied via namespace labels.
Question 18. PodSecurityPolicy Deprecation
What is the most appropriate reason for removing PodSecurityPolicy (PSP) from Kubernetes?
- A) It was too slow in performance
- B) Complex usage, confusing RBAC bindings, and unpredictable scope of application
- C) It lacked security features
- D) It only supported a single cloud provider
Answer and Explanation
Answer: B) Complex usage, confusing RBAC bindings, and unpredictable scope of application
PSP had unintuitive binding mechanisms through RBAC, and it was difficult to predict which PSP applied to which Pod. It was removed in Kubernetes 1.25, replaced by Pod Security Admission, Kyverno, and OPA/Gatekeeper.
Question 19. Network Policy
Which statement about Kubernetes NetworkPolicy is correct?
- A) Without NetworkPolicy, all traffic is blocked
- B) Without NetworkPolicy, all traffic is allowed; once applied, only explicitly allowed traffic passes
- C) NetworkPolicy only controls inter-node communication
- D) All CNI plugins support NetworkPolicy
Answer and Explanation
Answer: B) Without NetworkPolicy, all traffic is allowed; once applied, only explicitly allowed traffic passes
By default, Kubernetes allows all Pod-to-Pod communication. When NetworkPolicy is applied, only explicitly allowed ingress/egress traffic passes for selected Pods. Note that the CNI plugin must support NetworkPolicy.
Question 20. Secret Management
Which statement about Kubernetes Secret's default storage method is correct?
- A) Encrypted with AES-256 by default in etcd
- B) Only Base64-encoded in etcd by default; EncryptionConfiguration must be configured separately for encryption
- C) Secrets are stored only in memory and never written to disk
- D) Secrets are automatically stored in Vault
Answer and Explanation
Answer: B) Only Base64-encoded in etcd by default; EncryptionConfiguration must be configured separately for encryption
Kubernetes Secrets are stored Base64-encoded in etcd by default. This is not encryption, so anyone with etcd access can read the secrets. For encryption at rest, configure EncryptionConfiguration or use a KMS provider.
Question 21. Image Scanning
Which is NOT a container image vulnerability scanning tool?
- A) Trivy
- B) Grype
- C) Clair
- D) Helm
Answer and Explanation
Answer: D) Helm
Trivy (Aqua Security), Grype (Anchore), and Clair (Quay) are all container image vulnerability scanning tools. Helm is a Kubernetes package manager unrelated to security scanning.
Question 22. RBAC Least Privilege Principle
What is the correct approach when applying the principle of least privilege with RBAC?
- A) Grant cluster-admin role to all ServiceAccounts
- B) Create Roles containing only necessary resources and verbs, and use minimum-scope RoleBindings
- C) Only use ClusterRoles, never namespace Roles
- D) Use wildcards (*) to allow access to all resources
Answer and Explanation
Answer: B) Create Roles containing only necessary resources and verbs, and use minimum-scope RoleBindings
The principle of least privilege means granting only the minimum necessary permissions. Create Roles that allow only specific verbs on specific resources and apply them with namespace-scoped RoleBindings. Avoid wildcard usage and cluster-admin abuse.
Question 23. mTLS (Mutual TLS)
What is the role of mTLS in a service mesh?
- A) Compresses inter-service communication
- B) Both server and client authenticate each other with certificates and encrypt communication
- C) Encrypts DNS queries
- D) Performs load balancing
Answer and Explanation
Answer: B) Both server and client authenticate each other with certificates and encrypt communication
mTLS (mutual TLS) performs bidirectional authentication where both server and client present certificates. Service meshes like Istio and Linkerd automatically apply mTLS between services through sidecar proxies.
Question 24. Audit Logging
Which Kubernetes audit log level records the most detailed information?
- A) None
- B) Metadata
- C) Request
- D) RequestResponse
Answer and Explanation
Answer: D) RequestResponse
Kubernetes audit logging supports four levels: None (no logging), Metadata (request metadata only), Request (metadata + request body), and RequestResponse (metadata + request + response body). RequestResponse is the most detailed.
Question 25. SecurityContext
Which is NOT a configurable item in Pod-level SecurityContext?
- A) runAsUser
- B) fsGroup
- C) networkPolicy
- D) runAsNonRoot
Answer and Explanation
Answer: C) networkPolicy
Pod SecurityContext can configure runAsUser, runAsNonRoot, runAsGroup, fsGroup, supplementalGroups, sysctls, and seccompProfile. NetworkPolicy is a separate Kubernetes resource unrelated to SecurityContext.
Question 26. AppArmor and Seccomp
What is the role of a Seccomp profile?
- A) Controls filesystem access
- B) Filters system calls that a container can use
- C) Restricts network traffic
- D) Limits CPU usage
Answer and Explanation
Answer: B) Filters system calls that a container can use
Seccomp (Secure Computing Mode) filters the system calls a process can make using allow lists or block lists. In Kubernetes, you can apply RuntimeDefault or custom profiles through seccompProfile.
Question 27. Image Policy
How can you enforce running only trusted images in Kubernetes?
- A) Use the latest tag for all images
- B) Apply policies through Admission Controllers (Kyverno, OPA) to only allow signed images
- C) Only pull images from public registries
- D) Set imagePullPolicy to Never
Answer and Explanation
Answer: B) Apply policies through Admission Controllers (Kyverno, OPA) to only allow signed images
Kyverno's verifyImages rules or OPA/Gatekeeper's ConstraintTemplates can enforce that only images with verified cosign or Notation signatures are deployed. This is a key element of supply chain security.
Question 28. ServiceAccount Security
What changed in ServiceAccount token management after Kubernetes 1.24?
- A) ServiceAccount tokens were completely removed
- B) Auto-mounted permanent tokens are no longer created; short-lived tokens via TokenRequest API are recommended
- C) All Pods automatically mount cluster-admin tokens
- D) ServiceAccounts no longer exist
Answer and Explanation
Answer: B) Auto-mounted permanent tokens are no longer created; short-lived tokens via TokenRequest API are recommended
Since Kubernetes 1.24, Secrets are no longer automatically created with ServiceAccounts. Instead, time-limited short-lived tokens issued through the TokenRequest API are recommended, enhancing security.
Question 29. Container Isolation
What security benefit do gVisor and Kata Containers provide?
- A) Network encryption
- B) Reduce container escape risk by not sharing the kernel or adding extra isolation layers
- C) Image signature verification
- D) Enhanced RBAC policies
Answer and Explanation
Answer: B) Reduce container escape risk by not sharing the kernel or adding extra isolation layers
gVisor provides a user-space kernel (application kernel) that intercepts direct system calls to the host kernel. Kata Containers run containers inside lightweight VMs for hardware-level isolation. Both are selected through RuntimeClass.
Question 30. Comprehensive Security Best Practices
Which does NOT align with a Defense in Depth strategy?
- A) Image scanning + signature verification
- B) NetworkPolicy + mTLS
- C) RBAC + Pod Security Standards
- D) Running all workloads as root with privileged mode
Answer and Explanation
Answer: D) Running all workloads as root with privileged mode
Defense in Depth layers multiple security controls so that if one layer fails, others provide protection. It combines image security, network security, access control, and runtime security. Running as root with privileged mode contradicts security best practices.
Summary
These 30 questions are designed for in-depth study of the core KCSA exam domains: Supply Chain Security, Runtime Security, Platform Security, Network Security, and Compliance and Security Frameworks. The actual exam requires understanding not only Kubernetes security mechanisms but also the broader CNCF security ecosystem.