Fix
deploy's Lambda execution role policy split logs:CreateLogGroup onto a bare log-group ARN, separate from logs:CreateLogStream/logs:PutLogEvents on a :*-suffixed resource, based on AWS's commonly-documented Lambda execution role convention. Deployed to a real AWS account for the first time: CloudTrail showed every scheduled invocation's CreateLogGroup call failing with AccessDenied, because the actual resource ARN this Lambda runtime requests permission against is a third form neither statement covered (.../log-group:/aws/lambda/<fn>:log-stream:, no wildcard). The function still ran successfully either way — CloudWatch Logs failures don't fail a Lambda invocation — but produced zero retrievable logs for every run.
All three log actions are now granted together on a single :*-suffixed resource, since a wildcard covers every suffix variant. Confirmed against a live deployment: after applying the corrected policy, a manual invoke successfully created the log group and wrote real log output, where prior scheduled invocations had silently failed to create it at all.
This is a class of bug that mocked-AWS unit tests can't catch — moto doesn't enforce ARN-suffix-exact resource matching the way real AWS's Lambda runtime does. If you deployed spf53 with a prior version, you may want to check whether your function's CloudWatch log group actually exists and is receiving events.