SCS-C02 Identity and Access Management 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.

• ✗

  Store AWS credentials in the Lambda function code.

  Why it's wrong here

  Embedding AWS credentials (access key ID and secret access key) directly in Lambda function code is a severe anti-pattern. These long-lived credentials can be exposed through code reviews, version control history, or logs, and if compromised they provide persistent access outside the temporary credential model. Lambda should instead assume an execution role, which provides automatically rotated temporary credentials scoped to the function's required permissions, eliminating the need to store any secrets in code.

• ✗

  Attach a resource-based policy to the Lambda function.

  Why it's wrong here

  A resource-based policy attached to a Lambda function controls which external principals (accounts, users, or services) are allowed to invoke the function. It does not grant the function itself permission to call other AWS services such as CloudWatch Logs. To allow the function to write logs, you must use the function's execution role—an identity-based policy—because that is the mechanism by which Lambda obtains the credentials used for outbound API calls.

• ✓

  Create an IAM role with the necessary CloudWatch Logs permissions and assign it as the Lambda function's execution role.

  Why this is correct

  Create an IAM execution role granting the Lambda function the minimal CloudWatch Logs permissions required (e.g., logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents) and attach that role to the function via the function's configuration. This identity-based policy defines what the function can do as its authorized identity, allowing it to write logs securely. Following least privilege here is correct because the role grants only the specific log-writing actions, not broader access.

• ✗

  Attach the AdministratorAccess managed policy to the Lambda function's execution role.

  Why it's wrong here

  Attaching AdministratorAccess to the Lambda function's execution role grants full administrative rights across all AWS services, which is far beyond the single purpose of writing logs to CloudWatch. This violates the principle of least privilege and dramatically increases the blast radius if the function is compromised, since the attacker could leverage those credentials to delete resources or modify IAM. The correct scope is a custom policy allowing only the CloudWatch Logs actions needed for log stream creation and log event submission.

Go deeper

Related to this question