Created role and stack in the same account. Otherwise lambda.Function.grantInvoke fails as it assumes that function is imported (from a different account). See

Also, grantInvoke method creates permission on Lambda function itself (updates resource policy) if the role is in the different account. See

In the code we prepared this had a lot more beef.

1. You use one role named 'SchedulesRole' for all targets in the current stack. The more targets there are the less "least privilege' this will get. Personally I think one role per target makes more sense then one role per stack.
2. The code we started with had Stack.of(schedule) and then stack.node.tryFindChild(id) in stead of scope.node.tryFindChild. If you find the role for a target it is fine.

3. Why do we not also narrow down of the use of the role to "aws:SourceArn" "aws:SourceAccount"

I originally preferred this implementation inspired by events.target (

@Jacco I have removed condition for checking sourceArn as it created a circular dependency between schedule -> target -> role -> schedule.

In your original prototype it was implemented as:

 const scheduleArn = Arn.format({
    service: 'scheduler',
    resourceName: `${schedule.group.groupName}/${schedule.scheduleName}`,
    resource: 'schedule'
  }, Stack.of(schedule));
  const principal = new iam.PrincipalWithConditions(new iam.ServicePrincipal('scheduler.amazonaws.com'), {
    'StringEquals': {
        "aws:SourceArn": scheduleArn,
        "aws:SourceAccount": schedule.env.account,
    }
  })

It didn't create a dependency cycle in your code, as now the scheduleName is a reference to the CFN resource instead of just a string:

    this.scheduleName = this.getResourceNameAttribute(resource.ref);

@Jacco similarly, there was an option to create a condition for sourceArn here. But it would create a dependency cycle between target and schedule.

Had to specify environment here, otherwise schedule creation failed with an error that target and schedule should be in the same region / account. That's because we consider target and schedule to be in different accounts if one of their accounts is unresolved.

See sameEnvDimension implementation.

Let me know if that's a problem

TIL as well, but take a look at this file here

tl;dr: cross env tests need to use 234567890123