Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. Which EKS control-plane log types matter most for security investigations?

   1. Ascheduler and controllerManager
   2. Baudit and authenticator: who called the API, and which IAM identity was mapped
   3. CNone, AWS keeps them
   4. DOnly api
   Show answer

   B. Audit logs record every API request; authenticator logs show how IAM identities were authenticated. Both are off until you enable them.

   From lesson 11 · Observability: Prometheus, Grafana & CloudWatch

2. Q2. What's the main trade-off between self-run Prometheus and Amazon Managed Service for Prometheus?

   1. ADifferent query languages
   2. BSelf-run means you operate storage, HA and retention; managed removes that work but is priced per sample ingested and queried
   3. CManaged can't use Grafana
   4. DSelf-run can't alert
   Show answer

   B. Both speak PromQL. The decision is operational effort versus usage-based cost and control.

   From lesson 11 · Observability: Prometheus, Grafana & CloudWatch

3. Q3. Why alert on symptoms (error rate, latency) rather than causes (CPU high)?

   1. ACPU can't be measured
   2. BSymptoms reflect user impact; cause-based alerts fire often without impact and cause alert fatigue
   3. CCauses are more expensive to collect
   4. DPrometheus can't alert on CPU
   Show answer

   B. Page on SLO burn and user-visible symptoms; keep cause metrics on dashboards for diagnosis.

   From lesson 11 · Observability: Prometheus, Grafana & CloudWatch

4. Q4. A surprise CloudWatch bill appears after enabling logging. Most likely cause?

   1. AControl-plane metrics
   2. BShipping every container log line (including debug) to CloudWatch Logs without filtering or retention
   3. Ckubectl top
   4. DEBS snapshots
   Show answer

   B. Log ingestion and storage are priced per GB. Filter noisy logs, set retention on log groups, and consider cheaper tiers or S3 for bulk logs.

   From lesson 11 · Observability: Prometheus, Grafana & CloudWatch

5. Q5. Under the shared-responsibility model on EKS, who patches the worker node OS?

   1. AAWS, always
   2. BYou (on managed node groups you trigger AMI updates; Auto Mode and Fargate shift more of it to AWS)
   3. CNobody
   4. DKubernetes
   Show answer

   B. AWS secures the control plane. With managed node groups you still choose when to roll to new AMIs; Fargate and Auto Mode move node patching to AWS.

   From lesson 12 · Security: KMS, GuardDuty, IMDSv2, Pod Security & network policy

6. Q6. What does the restricted Pod Security Standard block?

   1. AAll pods
   2. BPrivileged containers, host namespaces and paths, running as root, privilege escalation, and extra capabilities
   3. COnly pods without limits
   4. DPods from ECR
   Show answer

   B. restricted is the hardened profile. Enforce it per namespace with a label; use baseline or exemptions only where a component genuinely needs more.

   From lesson 12 · Security: KMS, GuardDuty, IMDSv2, Pod Security & network policy

7. Q7. Where should application secrets come from?

   1. AEnvironment variables in the Deployment YAML in Git
   2. BAWS Secrets Manager or Parameter Store, synced into the cluster (e.g. External Secrets Operator) or read by the app with its own pod role
   3. CThe node role
   4. DA ConfigMap
   Show answer

   B. Keep secrets out of Git and out of manifests. The source of truth lives in a managed secret store with access controlled by IAM and audited by CloudTrail.

   From lesson 12 · Security: KMS, GuardDuty, IMDSv2, Pod Security & network policy

8. Q8. What does GuardDuty add for EKS?

   1. AEncryption
   2. BThreat detection from EKS audit logs and, with runtime monitoring, from process and network activity on nodes
   3. CAutoscaling
   4. DImage signing
   Show answer

   B. GuardDuty flags things like anonymous API access, known-malicious IPs, crypto-mining and suspicious container behaviour.

   From lesson 12 · Security: KMS, GuardDuty, IMDSv2, Pod Security & network policy

9. Q9. What's the right order for an EKS upgrade?

   1. ANodes, then control plane
   2. BControl plane, then add-ons, then nodes, one minor version at a time
   3. CAll at once
   4. DAdd-ons only
   Show answer

   B. Nodes must never be newer than the control plane, and add-ons must match the new version. Upgrades go one minor at a time.

   From lesson 13 · Upgrades & add-ons

10. Q10. How does Karpenter roll nodes onto a new AMI or version?

    1. AIt doesn't
    2. BThrough drift: when the NodeClass AMI selection changes, nodes no longer match and are replaced gradually within disruption budgets
    3. CBy rebooting nodes in place
    4. DOnly on Spot interruption
    Show answer

    B. Change the AMI selection (or let a pinned alias move), and drift replaces nodes respecting PDBs and disruption budgets.

    From lesson 13 · Upgrades & add-ons

11. Q11. When is a blue/green cluster upgrade worth the extra effort?

    1. AAlways
    2. BFor risky jumps (several versions behind, CNI changes, major redesigns) where an easy rollback matters more than cost and effort
    3. CNever
    4. DOnly for dev
    Show answer

    B. A new cluster built from code, with traffic shifted gradually, gives a clean rollback path. In-place is simpler for routine minor upgrades.

    From lesson 13 · Upgrades & add-ons

12. Q12. Someone ran 'terraform destroy' in the wrong workspace, and the state now shows nothing, but the resources were only partly deleted. First step?

    1. ARun apply immediately
    2. BStop all runs, back up the current state, inspect what actually exists in AWS, then restore or re-import deliberately
    3. CDelete the bucket
    4. DRecreate the account
    Show answer

    B. Acting fast without understanding can make it worse. Freeze changes, preserve evidence, compare state with reality, then recover.

    From lesson 14 · Disaster recovery

13. Q13. Why does versioning on the state bucket matter?

    1. AIt's cheaper
    2. BEvery state write creates a version, so a corrupted or wrong state can be rolled back to a known-good one
    3. CIt encrypts the state
    4. DIt speeds up plans
    Show answer

    B. Versioning is the undo button for state. Combine it with locking and restricted access.

    From lesson 14 · Disaster recovery

14. Q14. What lets you rebuild an EKS cluster's workloads quickly after losing the cluster?

    1. AScreenshots
    2. BCluster and platform defined in Terraform, apps in GitOps, data in backups (Velero, database backups) and secrets in a secret manager
    3. CAn etcd snapshot of the managed control plane
    4. DNothing
    Show answer

    B. EKS doesn't give you etcd snapshots; your recovery path is declarative code plus data backups.

    From lesson 14 · Disaster recovery

15. Q15. How does kubectl authenticate to EKS after `aws eks update-kubeconfig`?

    1. AWith a static password
    2. BThe kubeconfig runs an exec plugin (`aws eks get-token`) that turns your current AWS credentials into a short-lived token; EKS maps your IAM identity to permissions via access entries
    3. CWith the node's SSH key
    4. DWith a certificate you must renew yearly
    Show answer

    B. No long-lived secrets in the kubeconfig; access follows your IAM session.

    From lesson 15 · The flow: laptop → cluster → app

16. Q16. In the CI/CD way of working, who writes to production?

    1. AEvery engineer with kubectl
    2. BPipelines (Terraform via OIDC roles, Argo CD from the GitOps repo); humans mostly read, with break-glass for emergencies
    3. CNobody
    4. DOnly the cluster creator
    Show answer

    B. Changes become reviewed, logged and repeatable.

    From lesson 15 · The flow: laptop → cluster → app

17. Q17. Why push images by digest and deploy the digest?

    1. ADigests are shorter
    2. BThe digest identifies exact bytes; tags can move, so deploying digests makes releases and rollbacks exact
    3. CECR requires it
    4. DFor faster pulls
    Show answer

    B. See GitHub Actions — Level by Level, lesson 07.

    From lesson 15 · The flow: laptop → cluster → app