Lambda security, Amazon EKS security, and general container security (ECR/ECS/Fargate) — three compute models that share a common security pattern: identity for the workload, isolation of the runtime, and scanning of the artifact before it ever runs. The freshest material here is the IRSA-to-Pod-Identity transition and Lambda SnapStart's two specific, easily-missed security hazards.
This domain tests three things repeatedly: (1) workload identity — do you know the CURRENT recommended mechanism (EKS Pod Identity over IRSA, Lambda execution roles scoped per-function) rather than the older "broad node/instance role for everything" anti-pattern, (2) artifact security — can you distinguish scanning an image AT REST in ECR from scanning a RUNNING container/task, and (3) Lambda's specific SnapStart hazards (stale secrets, repeated uniqueness) which are a newer, frequently-overlooked nuance.
| Domain | Where This Bundle Shows Up |
|---|---|
| Infrastructure Security | The centerpiece — execution roles, Pod Identity/IRSA, network policies, task/pod isolation |
| Identity & Access Management | Workload identity patterns — Lambda execution roles, EKS Pod Identity, ECS task roles, all building on temporary-credential principles from earlier modules |
| Data Protection | Secrets handling in Lambda init/invoke phases, encryption of Fargate ephemeral storage |
| Threat Detection & Incident Response | GuardDuty Runtime Monitoring for EKS/ECS/Fargate, Inspector container-to-workload mapping, image-to-container mapping |
Over-privileged compute identities (broad node roles, unscoped Lambda execution roles); vulnerable or malicious container images reaching production; exposed Kubernetes API servers; stale secrets reused across snapshotted Lambda environments
Scope workload identity tightly per-function/per-pod/per-task, scan every image before and after deployment, and isolate runtimes from each other and from the host
The Compute & Container Security Bundle
Scope a dedicated execution/task/pod role per workload; enable ECR scanning and code signing; use Pod Identity for new EKS workloads; restrict the EKS API server endpoint; enable VPC endpoints for private ECR pulls.
Inspector continuously rescans ECR images and maps them to running containers; GuardDuty Runtime Monitoring watches process/file/network behavior on EC2, ECS, EKS, and Fargate.
Rebuild/redeploy a flagged image, rotate compromised credentials surfaced via runtime findings, tighten an overly broad task/pod role identified via least-privilege review.
Exam appearance probability: HIGH
pods.eks.amazonaws.com service principal), centralized visibility via ListPodIdentityAssociations, faster role changes with NO pod restart required, and native support for session tags enabling ABACtargetRoleArn parameter (alongside the existing roleArn) lets a Pod Identity association automatically chain into a role in a DIFFERENT AWS account — when both are specified, EKS performs the role-chaining automaticallyaws:sourceVpce on the repository policy) means even a compromised IAM credential with pull permissions can't exfiltrate the image from outside your network — a meaningful blast-radius reduction.Requirement → Keywords → Expected Answer → why every distractor fails.
EKS Pod Identity
| Distractor | Why it's wrong |
|---|---|
| IRSA | Requires creating/managing an OIDC provider and embedding the cluster's issuer URL into the role trust policy — more setup overhead than the question calls for |
| Broad node instance role | Grants every pod on the node the same permissions, violating least privilege |
IRSA
| Distractor | Why it's wrong |
|---|---|
| EKS Pod Identity | EKS-specific feature, requiring the EKS Pod Identity Agent add-on and EKS Auth API — does not extend to self-managed Kubernetes |
Move secret retrieval to invocation phase, or add an after-restore runtime hook to refresh it
| Distractor | Why it's wrong |
|---|---|
| Disable Secrets Manager rotation | Removes the security benefit of rotation entirely instead of fixing the actual root cause (the secret being frozen into the snapshot) |
| Increase the function's memory allocation | Unrelated to the snapshot/secret-staleness mechanism causing the symptom |
Inspector image-to-container mapping
| Distractor | Why it's wrong |
|---|---|
| ECR basic/enhanced scanning alone | Tells you the image HAS a vulnerability, not whether/where it's currently deployed and running — that's the mapping capability's specific job |
ECR repository policy with a VPC endpoint condition key (aws:sourceVpce)
| Distractor | Why it's wrong |
|---|---|
| IAM policy restricting ecr:BatchGetImage alone, without the VPC condition | Still allows the pull from anywhere if the credential itself is valid — the VPC source condition is what specifically blocks pulls from outside the network |
SnapStart's security boundary for credentials is at the EXECUTION ENVIRONMENT/SNAPSHOT level, not per-invocation — meaning a vulnerability isn't about the SnapStart feature being insecure per se, but about a developer's INITIALIZATION-PHASE CODE accidentally baking stale or non-unique values into something that gets reused across many invocations.
| Misconception | Reality |
|---|---|
| "IRSA is deprecated now that Pod Identity exists" | False — IRSA remains fully supported and is REQUIRED for non-EKS Kubernetes deployments and older cluster versions; Pod Identity is the recommended choice for NEW EKS-specific workloads, not a forced migration |
| "SnapStart is insecure and shouldn't be used for functions handling secrets" | SnapStart itself isn't insecure — the risk is specific, avoidable developer patterns (retrieving secrets at init-time instead of invoke-time); proper handling fully mitigates both hazards |
| "ECR image scanning covers a container for its entire runtime lifecycle automatically" | Basic at-push scanning is a point-in-time check; enhanced scanning continuously rescans the IMAGE in the registry, but assessing the RUNNING container is a separate Inspector capability |
| "The EKS API server is private by default, like most managed AWS service endpoints" | False — it is PUBLIC by default and must be deliberately restricted |
| "A broad IAM role on the EKS worker node is fine since it's just for infrastructure-level access" | It grants every pod scheduled on that node the same permissions — a major least-privilege violation, not an acceptable infrastructure-only shortcut |
| Comparison | What actually differs |
|---|---|
| EKS Pod Identity vs IRSA | Agent-based, no OIDC provider, simpler trust policy, cross-account role chaining vs OIDC-federation-based, per-cluster issuer setup, required for non-EKS Kubernetes |
| ECR basic scanning vs enhanced scanning | Free, CVE-database point-in-time check vs Inspector-powered, continuous rescanning, broader OS/minimal-base-image support, billed per image |
| ECR scanning vs Inspector running-container assessment vs GuardDuty Runtime Monitoring | Image at rest in the registry vs running container's known vulnerabilities vs running container's BEHAVIORAL/process activity — three distinct layers of the same lifecycle |
| Lambda execution role vs Lambda code signing | Controls what AWS resources the function can access vs controls whether the deployed CODE itself is trusted/verified — permission scope vs code integrity |
| SnapStart init-phase retrieval vs invoke-phase retrieval (for secrets) | Frozen into the snapshot, reused stale across all resumed environments vs fetched fresh on every actual invocation — the single most important SnapStart security decision |
Click card to flip. Mark right or wrong to track score.
SCS-C02 scenario style, Easy → Specialty. Select an answer to reveal the explanation.