Lambda is denied GetSecretValue although IAM Policy Simulator allows it

Hello.

Is the ARN of the secret you are trying to access correct?
Try checking the ARN using the following command.
Also, try temporarily changing "Resource" to an asterisk in your IAM policy to see if the request succeeds.

aws secretsmanager describe-secret --secret-id gappa/production/sp-api 

By the way, have you checked the GetSecretValue logs in CloudTrail?
These logs sometimes contain more detailed information about the cause of the error.
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-a-trail-using-the-console-first-time.html

Hello! Thank you for your reply! Update: I verified the points mentioned in the answers.

1. The secret ARN is correct: arn:aws:secretsmanager:eu-west-1:301286002792:secret:gappa/production/sp-api-PKJQIE

2. The secret uses the AWS managed key aws/secretsmanager, not a customer-managed KMS key.

3. The Lambda execution role has this identity-based permission: secretsmanager:GetSecretValue on: arn:aws:secretsmanager:eu-west-1:301286002792:secret:gappa/production/sp-api-PKJQIE*

4. The secret resource policy also explicitly allows the role: arn:aws:iam::301286002792:role/gappa-agent-production-runtime

IAM Policy Simulator returns Allowed, but the Lambda runtime still returns: AccessDeniedException ... because no identity-based policy allows the secretsmanager:GetSecretValue action

Could this be related to the Lambda execution environment, a stale execution-role session, or an account-level policy evaluation issue? Please advise which CloudTrail event details would help investigate this discrepancy.

The IAM Policy Simulator returned Allowed because it evaluated only the identity-based policy — it does not automatically load the Secrets Manager resource-based policy, so any Deny in that policy is invisible to the simulator. That is the documented reason for the divergence.

Three things to check, in order:

Run this first and compare the real ARN suffix against the PKJQIE in your inline policy wildcard:

aws secretsmanager describe-secret --secret-id gappa/production/sp-api --region eu-west-1 --query ARN

If the suffix differs, that is the root cause — the wildcard does not resolve to the real secret ARN.

Then pull the resource-based policy and check for any Effect Deny or Condition block:

aws secretsmanager get-resource-policy --secret-id <full ARN from above> --region eu-west-1

An explicit Deny in that policy overrides the identity-based Allow at runtime even though the simulator missed it.

Finally confirm the KMS key type. If it is a customer-managed key the role also needs kms:Decrypt on that key — though the error message you are seeing ("no identity-based policy allows") points more toward the ARN mismatch or resource-policy Deny than a KMS gap.

The updates you posted (ARN confirmed, AWS managed key confirmed, resource policy allowing the role) point toward a session-level issue — either stale credentials in a warm Lambda container (check userIdentity.sessionContext.attributes.creationDate in CloudTrail) or a session policy scoping down the assumed-role session at runtime. The IAM Policy Simulator evaluates the role's attached policies, not the live session, so if credentials predate a recent policy change or if the Lambda service applied a session policy at AssumeRole time, the simulator would still say Allowed while runtime denies. Force a cold start by deploying a trivial change to the function and retest — that is the fastest 5-minute check.

I ran the Lambda test again after verifying both policies.

The test event was:

{
  "action": "sp_api_lwa_health_check"
}

The Lambda still returns the same error:

AccessDeniedException: ... is not authorized to perform secretsmanager:GetSecretValue ... because no identity-based policy allows the secretsmanager:GetSecretValue action

The actual secret ARN, the inline IAM policy, and the Secrets Manager resource policy all match. The secret uses the AWS managed key aws/secretsmanager, and there is no explicit Deny in the resource policy.

The default Hello World test succeeds, so the Lambda function itself runs correctly. The failure occurs only when the function calls Secrets Manager.

Could you please advise how to inspect the corresponding CloudTrail GetSecretValue event or determine why the live Lambda session does not see the attached identity-based policy?

I also verified the actual inline policy using AWS CLI. The policy is attached to the role and contains:

{
  "Action": "secretsmanager:GetSecretValue",
  "Effect": "Allow",
  "Resource": "arn:aws:secretsmanager:eu-west-1:301286002792:secret:gappa/production/sp-api-PKJQIE*"
}

CloudTrail confirms that the request is made by the expected Lambda assumed role:

arn:aws:sts::301286002792:assumed-role/gappa-agent-production-runtime/gappa-agent-production-baseline

The CloudTrail event is a real secretsmanager:GetSecretValue call in eu-west-1, and it returns AccessDenied.

The secret ARN, inline policy, resource policy, region, and KMS key have all been verified. The default Lambda test succeeds, while only the Secrets Manager call fails.

At this point, could you please advise whether this indicates an IAM policy evaluation or account-level issue that requires AWS investigation?

Please help I tested the Lambda function again using the following event:

{
  "action": "sp_api_lwa_health_check"
}

The function still fails with the same AccessDeniedException for secretsmanager:GetSecretValue.

I also verified the actual inline policy with AWS CLI. The policy is attached to gappa-agent-production-runtime and contains:

{
  "Action": "secretsmanager:GetSecretValue",
  "Effect": "Allow",
  "Resource": "arn:aws:secretsmanager:eu-west-1:301286002792:secret:gappa/production/sp-api-PKJQIE*"
}

The following items have been verified:

• The Lambda uses the expected execution role.
• The secret ARN is correct.
• The IAM policy is actually attached to the role.
• The Secrets Manager resource policy allows the same role.
• The secret uses the AWS managed KMS key aws/secretsmanager.
• CloudTrail confirms that the real Lambda session makes the GetSecretValue request and receives AccessDenied.
• The default Lambda test succeeds; only the Secrets Manager call fails.

I have attached a screenshot of the latest Lambda error. No secret values or credentials are included.

Could you please advise what else could cause this authorization failure, or whether this requires investigation of the account-level IAM policy evaluation?