Amazon EKS — Security Practice Questions
Test your understanding of EKS security — IAM, RBAC, IRSA, Pod Identity, secrets, and pod security.
Question 1
What is the correct order of the EKS authentication flow?
A) kubectl → RBAC → IAM Authenticator → STS
B) kubectl → STS token → API server → IAM Authenticator → RBAC
C) kubectl → API server → STS → RBAC → IAM Authenticator
D) kubectl → IAM Authenticator → API server → RBAC → STS
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Incorrect order — RBAC comes after authentication, not before |
| B | kubectl gets a pre-signed STS token, sends it to API server, API server validates via IAM Authenticator, then applies RBAC |
| C | STS validation happens via IAM Authenticator, not directly by the API server |
| D | IAM Authenticator is called by the API server, not by kubectl directly |
Question 2
Which approach is recommended for granting pods access to AWS services?
A) Attach IAM policies to the EC2 node instance profile
B) Store AWS credentials as Kubernetes Secrets
C) Use IRSA or EKS Pod Identity
D) Use environment variables with access keys
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Over-privileges all pods on the node — violates least privilege |
| B | Static credentials that don’t rotate automatically — security risk |
| C | IRSA and Pod Identity provide per-pod temporary credentials scoped to specific ServiceAccounts |
| D | Hardcoded credentials — worst practice for security |
Question 3
What does IRSA use to obtain temporary AWS credentials?
A) EC2 Instance Metadata Service (IMDS)
B) STS AssumeRole
C) STS AssumeRoleWithWebIdentity via OIDC
D) IAM access keys stored in the ServiceAccount
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | IMDS provides node-level credentials, not pod-level (that’s the old approach) |
| B | AssumeRole is for role chaining — IRSA uses the web identity variant |
| C | IRSA uses the cluster’s OIDC provider to call STS AssumeRoleWithWebIdentity, getting pod-specific temporary credentials |
| D | No access keys are stored — IRSA uses OIDC tokens projected into the pod |
Question 4
What advantage does EKS Pod Identity have over IRSA?
A) Better performance for AWS API calls
B) No OIDC provider required, simpler trust policies
C) Works without a ServiceAccount
D) Supports more AWS services
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | Both use STS for credentials — same API call performance |
| B | Pod Identity eliminates OIDC provider setup and uses a simple trust policy (pods.eks.amazonaws.com), and associations are managed via EKS API |
| C | Pod Identity still requires a ServiceAccount — the association maps role to ServiceAccount |
| D | Both grant the same IAM permissions — AWS service access is determined by the IAM policy, not the credential mechanism |
Question 5
Which EKS Access Policy provides read-only access across the entire cluster?
A) AmazonEKSViewPolicy
B) AmazonEKSAdminViewPolicy
C) AmazonEKSEditPolicy
D) AmazonEKSClusterAdminPolicy
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | AmazonEKSViewPolicy is namespace-scoped — not cluster-wide |
| B | AmazonEKSAdminViewPolicy provides read-only access across the entire cluster (cluster scope) |
| C | AmazonEKSEditPolicy allows create/update/delete — not read-only |
| D | AmazonEKSClusterAdminPolicy is full admin — far beyond read-only |
Question 6
What happens to KMS-encrypted Kubernetes Secrets when the KMS key is deleted?
A) Secrets revert to base64 encoding
B) Secrets remain accessible from the cached decryption
C) Secrets become permanently inaccessible
D) EKS automatically re-encrypts with a new key
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Secrets don’t revert — they’re encrypted at rest with the KMS key |
| B | etcd caches are temporary — after restart or compaction, the key is needed |
| C | If the KMS key is deleted (after the 7-30 day waiting period), all Secrets encrypted with it become permanently unreadable |
| D | EKS does not automatically re-encrypt — the operator must manage key lifecycle |
Question 7
Which Pod Security Standard level should production workloads use as a minimum?
A) Privileged
B) Baseline
C) Restricted
D) Custom
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Privileged allows all capabilities — only for system components like CNI plugins |
| B | Baseline prevents known escalations but allows running as root — not strict enough for production |
| C | Restricted enforces non-root, drops all capabilities, requires seccomp profile — the target for production workloads |
| D | Custom is not a PSS level — the three levels are Privileged, Baseline, and Restricted |
Question 8
What does the External Secrets Operator (ESO) do?
A) Encrypts Kubernetes Secrets at rest
B) Syncs secrets from external stores into Kubernetes Secrets
C) Mounts secrets as files in pods via CSI driver
D) Provides pod-level AWS credentials
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | KMS envelope encryption handles at-rest encryption, not ESO |
| B | ESO syncs secrets from external stores (AWS Secrets Manager, Vault, etc.) into native Kubernetes Secret objects |
| C | CSI-based mounting is done by the Secrets Store CSI Driver + ASCP, not ESO |
| D | IRSA and Pod Identity provide pod-level credentials, not ESO |
Question 9
In the EKS authentication mode API_AND_CONFIG_MAP, which takes precedence when both an access entry and aws-auth mapping exist for the same IAM principal?
A) aws-auth ConfigMap always takes precedence
B) Access entry always takes precedence
C) The most recently created one takes precedence
D) Both are evaluated and the more permissive wins
Show Answer
Correct Answer: B
| Option | Explanation |
|---|---|
| A | aws-auth is the legacy mechanism — access entries take precedence when both exist |
| B | When both mechanisms are enabled, access entries take precedence over aws-auth ConfigMap for the same principal |
| C | Precedence is not based on creation time — it’s API over ConfigMap |
| D | They don’t merge — access entry wins, aws-auth mapping is effectively ignored for that principal |
Question 10
Which tool detects runtime threats like reverse shells in EKS pods?
A) Kyverno
B) OPA Gatekeeper
C) Amazon GuardDuty EKS Runtime Monitoring
D) AWS Config
Show Answer
Correct Answer: C
| Option | Explanation |
|---|---|
| A | Kyverno is an admission controller — validates/mutates at deploy time, not runtime |
| B | Gatekeeper is also admission-time — doesn’t detect runtime threats |
| C | GuardDuty EKS Runtime Monitoring uses a DaemonSet agent to detect runtime threats like reverse shells, crypto mining, and suspicious file access |
| D | AWS Config checks resource configuration compliance — not runtime threat detection |
