Securing Compute Workloads: EC2, Containers, and Lambda

The instance metadata service at 169.254.169.254 hands out the temporary credentials for an instance's IAM role — which makes it the highest-value target on any EC2 host. With IMDSv1, a single GET request returns credentials, so any server-side request forgery (SSRF) flaw, misconfigured proxy, or open redirect that can coax the application into fetching an internal URL becomes credential theft. This is not hypothetical: it is the mechanism behind some of the most famous cloud breaches, and the exam expects you to name the fix immediately.

IMDSv2 makes metadata access session-oriented. A client must first send a PUT request with the X-aws-ec2-metadata-token-ttl-seconds header to obtain a token, then present that token in the X-aws-ec2-metadata-token header on every read. Typical SSRF primitives can issue simple GETs but cannot send a custom-header PUT, so the attack chain breaks. The default hop limit of 1 adds a second defense: the token-bearing response's TTL prevents it from being forwarded past the instance itself — though containerized workloads using the instance's IMDS need the hop limit raised to 2.

Enforcement is layered. At launch, set HttpTokens=required in the instance's metadata options. Bake the default into images with the AMI's ImdsSupport=v2.0 setting, and set Region-wide instance metadata defaults at the account level. Enforce organizationally with an SCP or IAM condition using ec2:MetadataHttpTokens on RunInstances. Detect drift with AWS Config, and remember the correlated GuardDuty signal: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when an instance role's credentials are used from outside AWS — the smoke that says the metadata service already leaked. Always prefer instance roles over static access keys on hosts; rotation and revocation come free.

Fleet hardening starts before boot. EC2 Image Builder turns AMI creation into a pipeline: a base image, an ordered list of build components (install agents, remove packages, apply CIS or STIG hardening — Amazon publishes managed STIG components), test components that validate the result, and distribution of the finished golden AMI across Regions and accounts. Because the pipeline runs on a schedule or on new-CVE triggers, the golden image stays current instead of decaying into a snowflake, and every instance launched from it inherits the same hardened baseline — including IMDSv2-required metadata defaults and pre-installed SSM and CloudWatch agents.

Running fleets still drift, which is Systems Manager Patch Manager's job: patch baselines define which patch classifications and severities are approved (with optional auto-approval delays), patch groups map baselines to instance tags, and maintenance windows schedule the Scan or Scan and install operations. Compliance state per instance flows into Systems Manager Compliance and on to Security Hub, so "show me every instance missing critical patches" is a query, not an audit project. Pair this with Session Manager and EC2 Instance Connect for administrative access — auditable, IAM-gated shells with no inbound port 22 and no long-lived SSH keys.

Storage defaults close the loop. Enable EBS encryption by default per Region so every new volume and snapshot is KMS-encrypted without per-launch diligence, and build AMIs from encrypted snapshots so the golden image itself is encrypted. Deeper KMS mechanics — key policies, cross-account snapshot sharing — belong to Domain 5; here the exam wants the operational posture: encrypted by default, hardened by pipeline, patched by schedule.

Amazon Inspector is the vulnerability scanner across all three compute form factors, and its defining trait is that it is continual — you enable it (organization-wide via a delegated administrator) and it discovers and assesses resources automatically rather than running one-off assessments.

For EC2, Inspector scans instances managed by Systems Manager — the SSM Agent is the collection path — inventorying packages and comparing them against CVE databases, with an agentless option that assesses EBS snapshots for instances SSM cannot manage. For ECR, enhanced scanning assesses container images on push and then continuously: when a new CVE is published, already-stored images are re-evaluated, so a clean image can legitimately develop critical findings a month later. For Lambda, standard scanning covers dependency vulnerabilities in the function's packages, and code scanning inspects your own function code for embedded secrets and injection-style flaws.

Findings carry an Inspector score — a contextualized severity that adjusts the CVSS base score using environmental factors like network reachability and whether an exploit is available — so a critical CVE on an isolated, unreachable instance ranks below a moderate one on an internet-facing host. Prioritize by that score, not raw CVSS.

The design pattern the exam rewards is the remediation loop: Inspector findings flow to Security Hub for aggregation and to EventBridge for action — trigger Patch Manager to patch the CVE, kick off an Image Builder pipeline to rebuild the golden AMI, notify the owning team, or fail a deployment. Complementing Inspector's static view, GuardDuty Runtime Monitoring watches what workloads actually do at runtime; and in the pipeline itself, Amazon CodeGuru Security and Amazon Q Developer surface code-level vulnerabilities before anything ships.

Every container control downstream depends on trusting what is in the registry, so Amazon ECR is where container security starts. Four controls matter for the exam.

Scanning. ECR offers basic scanning (on push or on demand, OS packages only) and enhanced scanning, which delegates to Amazon Inspector for the on-push plus continuous rescanning behavior described above, covering both OS and programming-language packages. "Images must be re-checked automatically when new CVEs are published" is enhanced scanning, full stop.

Immutable tags. With tag immutability enabled, a tag can never be overwritten to point at a different image. Without it, an attacker (or an accident) can push a new image as myapp:prod, and every task definition referencing that tag silently deploys the replacement — a supply-chain attack that scanning alone does not stop. Immutability forces new content to arrive under new tags, making deployments auditable and pinnable; referencing images by digest is the strictest variant of the same idea.

Repository policies. ECR repositories carry resource-based policies, which is how you grant cross-account pull to workload accounts without creating roles in the registry account — grant ecr:BatchGetImage and ecr:GetDownloadUrlForLayer to the consuming principals, and nothing more. Keep push rights confined to the CI/CD pipeline's role.

Encryption. Repositories encrypt images at rest with AES-256 or KMS; choose a customer managed key when you need key-level access control and CloudTrail visibility of decryption. Round out hygiene with lifecycle policies that expire stale images — an unscanned, forgotten image from two years ago is exactly what gets redeployed in an incident. Image signing and verification exist at mention level (Signer with Notation); know they address provenance, not vulnerabilities.

The most reliably tested distinction in container security is the two roles attached to an ECS task — because they answer different questions:

The trap: secrets referenced in the task definition's secrets block — injected as environment variables from Secrets Manager or SSM Parameter Store at startup — are fetched by the execution role. Secrets fetched by application code at runtime use the task role (delivered via the container credentials endpoint, per-task, so co-located tasks never share credentials). Granting the wrong role is the classic broken deployment, walked through in the final section.

Fargate hardens the substrate: each task runs in its own isolated environment with a dedicated kernel — no shared host to escape to, no privileged containers, no host-path mounts, and AWS patches the underlying infrastructure. Within any task, set readonlyRootFilesystem in the container definition so a compromised process cannot modify its own filesystem, drop non-root users in the image, and keep containers from running with elevated Linux capabilities.

EKS security at specialty level reduces to three controls; deep Kubernetes administration is out of scope, but these are fair game.

Least-privilege pod identity. The anti-pattern is giving the node's instance role every permission any pod might need — every pod on the node then holds the union. The fix is per-pod credentials: IAM Roles for Service Accounts (IRSA) associates an IAM role with a Kubernetes service account through the cluster's OIDC identity provider — pods assume the role with sts:AssumeRoleWithWebIdentity using a projected service account token, and the role's trust policy names the specific service account. The newer EKS Pod Identity feature reaches the same goal with less setup: an EKS-run agent and a direct association between role and service account, no per-cluster OIDC provider registration. Either way, the exam answer to "one pod needs S3 access, others must not have it" is pod-level identity, never node-role inflation. Blocking pods from the node's instance metadata (or enforcing IMDSv2 with hop limit 1) closes the fallback path to node credentials.

Control-plane audit logs. EKS can ship five control-plane log types to CloudWatch Logs — api, audit, authenticator, controllerManager, and scheduler. They are off by default; the audit and authenticator streams are the ones that answer "who did what to the cluster," and GuardDuty's EKS audit log monitoring consumes this activity for threat detection.

Private endpoint. The cluster API server endpoint is public by default. Disable public access (or restrict it to allowlisted CIDRs) and enable the private endpoint so kubectl and node-to-control-plane traffic stay inside the VPC — an internet-reachable API server is an unnecessary attack surface even with authentication in front of it.

Lambda has two independent permission surfaces, and questions turn on which one is broken. The execution role governs what the function can do — assumed by the service at invocation, its credentials handed to your code. Least privilege means one role per function, not a shared "lambda-role" with accreted permissions; a function that reads one DynamoDB table should hold exactly that.

The resource-based policy governs who may invoke the function. When S3, SNS, or EventBridge invokes a function, the service principal (for example s3.amazonaws.com) must be granted lambda:InvokeFunction in the function's policy. That grant creates the confused-deputy risk: any S3 bucket — including one in a stranger's account — could otherwise trigger your function through the trusted service. The fix is scoping the grant with aws:SourceArn (the specific bucket ARN) and aws:SourceAccount, so the service may only pass through invocations originating from your resource. This pattern generalizes to every service-to-service resource policy on the exam.

VPC attachment is about egress, not ingress. Attaching a function to a VPC controls where its outbound traffic goes (via Hyperplane-managed ENIs) and lets it reach private resources like RDS — but it removes default internet access (add a NAT gateway or VPC endpoints) and does not change who can invoke the function; invocation always flows through the Lambda API and IAM. Environment variables are encrypted at rest with KMS — use a customer managed key for auditable access control, but prefer Secrets Manager for actual secrets so rotation exists. At mention level: code signing with AWS Signer lets Lambda reject unsigned or modified deployment packages, and GuardDuty Lambda Protection surfaces findings such as CryptoCurrency:Lambda/BitcoinTool.B when a hijacked function starts mining.

Instance unreachable by SSM. An instance missing from Fleet Manager (so Session Manager, Patch Manager, and Inspector's SSM-based scanning all fail) has one of three causes: the SSM Agent is not running; the instance profile lacks the AmazonSSMManagedInstanceCore permissions; or there is no network path to the SSM endpoints. For private subnets, that path means interface VPC endpoints for ssm, ssmmessages, and ec2messages (or NAT egress). Check agent, role, path — in that order.

Inspector not scanning an instance. Usually the same root cause: Inspector's EC2 scanning rides on SSM management, so an unmanaged instance is invisible to it. Fix SSM coverage first; agentless snapshot-based assessment is the fallback for hosts that cannot run the agent.

Scenario: the task that cannot read its secret. A new ECS service's tasks stop immediately with ResourceInitializationError: unable to pull secrets or registry auth. Walk it: the failure is at startup, so this is execution-role territory, not the task role. Check, in order: (1) the execution role grants secretsmanager:GetSecretValue on the specific secret ARN referenced in the task definition's secrets block — and kms:Decrypt on the key if the secret uses a customer managed key; (2) the same role can pull the image (ecr:GetAuthorizationToken plus the pull actions, and the cross-account repository policy if ECR lives elsewhere); (3) tasks in private subnets can reach Secrets Manager and ECR — interface endpoints for secretsmanager, ecr.api, and ecr.dkr, plus the S3 gateway endpoint ECR needs for image layers. The distractor answer adds the permission to the task role; startup failures make that wrong every time.

Lambda AccessDenied on invoke. The caller is refused before the function runs, so inspect the resource-based policy: the invoking service or account needs lambda:InvokeFunction, with aws:SourceArn matching the actual triggering resource. The execution role is irrelevant to who may invoke.