After deploying to production, S3 events in development environments started invoking the production Lambda functions, causing unwanted executions. The team must stop cross-environment invocations and follow security best practices. Which solution meets these requirements?

Moving development and production into separate AWS accounts provides strong isolation, preventing cross-environment interference, which is a security best practice. A resource policy on each Lambda function, specifically allowing invocations only from S3 buckets within the same account, ensures that S3 events from one environment cannot trigger Lambda functions in another. Updating the production Lambda execution role to read only the production S3 bucket is insufficient because the issue is about invocation of the Lambda, not its read permissions. Adding a resource policy to only the production Lambda is a partial solution; it doesn't address the development environment's potential to invoke production, nor does it provide the robust isolation of separate accounts. Updating the Lambda execution role to allow reading only the S3 bucket in the same account (even with separate accounts) still misses the core problem of invocation permissions, not read permissions.