SOA-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use a Lambda function to generate temporary credentials from an IAM user.

  Why it's wrong here

  This approach still hinges on the IAM user's long-term access keys: the Lambda function must store or retrieve that user's secret key in order to call STS and produce temporary credentials. It merely moves the problem into a different compute service, leaving the same long-lived secret available to be leaked through environment variables or code. Additionally, the temporary credentials inherit all permissions of the user unless you attach a restrictive policy to the STS call, and you add unnecessary invocation overhead and cost.

• ✗

  Store the AWS access keys in an S3 bucket and have the application download them at startup.

  Why it's wrong here

  Placing static access keys in an S3 object introduces a single point of exposure: if the bucket policy is misconfigured, the object is publicly readable, or the key is revealed through access logs, any party with read access can lift the credentials. The application still needs AWS credentials to download the object, creating a bootstrap dependency, and the keys remain valid indefinitely until manually rotated. This pattern also fails to provide the automatic rotation and least-privilege scoping that an IAM role would offer.

• ✓

  Attach an IAM role with the necessary permissions to the EC2 instance.

  Why this is correct

  Attaching an IAM role to the EC2 instance via an instance profile is the AWS-recommended way to grant AWS API access to applications running on that instance. The AWS SDK and CLI automatically retrieve short-lived credentials from the instance metadata service (IMDSv2) and refresh them before they expire, so no secrets are stored in code, configuration, or environment variables. These credentials carry only the permissions defined in the role, and the role can be updated without changing the instance.

• ✗

  Create an IAM user with programmatic access and store the access keys in the application's environment variables.

  Why it's wrong here

  Storing programmatic access keys in environment variables embeds long-term credentials in the runtime environment, which can be exposed by debugging tools, container inspection, or .env files that are accidentally committed to a repository. The keys are not rotated automatically and remain active even after the EC2 instance is terminated, creating an ongoing security liability. This also typically uses a single IAM user whose broad permissions violate least privilege, whereas an instance role would restrict access to only the required actions.

Go deeper

Related to this question