In an AWS CDK app, what does calling bucket.grantRead(myFunction) actually put into the synthesized CloudFormation template, and why is that preferred over hand-writing the policy document?

## What a grant call is Grant methods are the clearest reason to prefer an L2 construct over the generated L1 underneath it. They are ordinary methods on the resource construct — `bucket.grantRead`, `bucket.grantPut`, `queue.grantConsumeMessages`, `table.grantReadWriteData` — and they take a grantee: anything implementing `iam.IGrantable`, which in practice means a Lambda function, an ECS task definition's task role, a role, or a user. The call happens at synth time, in your program, and its only effect is on the template that gets emitted. ## What lands in the template For `bucket.grantRead(fn)` where both live in the same stack, the statement lands on the **grantee's** identity policy — the inline policy of the function's execution role — not on the bucket. Two details matter and both are things hand-written policies get wrong. First, the action set is a family, not a single action: the read grant covers the `s3:GetObject*`, `s3:GetBucket*` and `s3:List*` shapes. That is broader than `s3:GetObject` alone and narrower than `s3:*`, and it is deliberately the set a reader actually needs. Second, the resource is expressed twice. Object-level actions apply to `arn:aws:s3:::bucket-name/*` while bucket-level actions apply to `arn:aws:s3:::bucket-name`. A policy that lists only one of the two produces the classic "I can get objects but cannot list the bucket" ticket. The grant emits both, and the ARNs are generated references to the bucket construct rather than strings you typed, so they stay correct when the physical name is auto-generated. ## Encryption keys ride along If the bucket construct in your app owns a KMS key — for example because you asked for `BucketEncryption.KMS`, so the CDK created the key — then the read grant also adds the decrypt permission on that key. This is the single most valuable thing the helper does, because a hand-written S3 policy that looks perfectly correct still yields `AccessDenied` at runtime when the object is encrypted with a customer managed key and the caller has no key permission. ## Same stack, other stack, other account Grants are not blindly "add to the role". For resources that support a resource policy, the CDK decides where the statement belongs: for a principal it can reach, the identity policy is enough; where the grantee is an account or a principal outside the app's control, it can add the statement to the resource's own policy instead. This is why the same one-line call behaves sensibly in more than one topology — and why you should read the diff rather than assume. ## Imported resources are the sharp edge The common production surprise is granting on an imported resource. `s3.Bucket.fromBucketName(this, 'Existing', 'my-bucket')` gives you a bucket object whose only knowledge is a name. The CDK will still write the S3 actions onto the grantee's role, but it does not know the bucket is encrypted with a customer managed key, so no decrypt permission is added — and the deploy succeeds while the function fails at runtime. Similarly, the CDK does not own that bucket's policy, so it cannot modify it; a cross-account grant on an imported bucket is a no-op on the bucket side. The fix is to import with the attributes the grant needs, using `fromBucketAttributes` and passing the `encryptionKey`, so the grant has something to grant on. ```ts const bucket = s3.Bucket.fromBucketAttributes(this, 'Existing', { bucketArn: 'arn:aws:s3:::my-bucket', encryptionKey: kms.Key.fromKeyArn(this, 'Key', keyArn), }); bucket.grantRead(fn); ``` ## What grants do not do They are not a compliance control. A grant produces the permissions the construct author considered appropriate for that verb, which is usually tighter than what a human would paste but is not minimal — the action wildcards mean a `grantRead` covers more than one API call. They do not replace reviewing the synthesized policy, and on a security-sensitive resource it is entirely reasonable to skip the helper and write the statement explicitly with `addToRolePolicy`. The argument for the helper is consistency and the parts you would forget, not perfection. ## Why an interviewer asks this Because the answer separates people who have used CDK from people who have read about it. Anyone can say "it grants read". The signal is in knowing the statement goes on the grantee, that two ARN forms are emitted, that the key permission comes along only when the app knows about the key, and that imported resources are where all three of those quietly stop being true.