Describe the bug
The workflow you go through to "update permissions granted to the Lambda function to perform on other resources in your project" does not work - at least not in the way that this piece of documentation implies that it does: https://docs.amplify.aws/cli/function. If you don't choose the create operation, you won't actually be able to access an AppSync api from the lambda.
Amplify CLI Version
4.20.0
To Reproduce

Go through the amplify update function flow as shown in the above image, being sure to choose an operation other than create - read for example.
Also, follow all the other steps outlined in the amplify docs here: https://docs.amplify.aws/cli/function#signing-a-request-from-lambda - except instead of a create mutation, feel free to switch to one that is implied to be available based on the operation you chose (a list query for example).
Then, run the lambda and note that you get back an unauthorized error.
Expected behavior
Lambda's response contains response of the AppSync query.
Desktop (please complete the following information):
Additional context
When going through the permission grant flow, the outcome is the generation of a CloudFormation template in the lambda's directory. This contains a subtree AmplifyResourcesPolicy.Properties.PolicyDocument.Statement.Action, and this is where the problem is. The actions granted by choosing the read in the permission grant flow are appsync:Get* and appsync:List*; update gets you appsync:Update* and delete gets you appsync:Delete*. create on the other hand gives you appsync:Create*, appsync:StartSchemaCreation, and critically appsync:GraphQL.
An examination of the available Actions under the AppSync category in the IAM Policy Simulator reveals the following:

It looks like all the Create, Get, Update, and Delete Actions are meta-actions, which would allow your lambda to manipulate AppSync itself - not _use_ it.
I'm not sure if this is technically a bug, because you may well want a lambda to be able to perform meta-actions on your AppSync instance. But that's definitely not the use case advertised in the amplify docs on functions that I've linked twice in here. Those docs technically work because they recommend choosing the create option in the workflow, but the way the article is written, that looks like an arbitrary choice that shouldn't affect the outcome, and/or it is implied that because the author was using a mutation that did creation, _that's_ why create was chosen.
Workaround
Just choose the create option if you want a lambda to be able to access your AppSync API (and optionally go into the cloudformation template and delete the extraneous Create* and StartSchemaCreation Actions).
Suggested Fix
Update the CLI to include some more language about how the create, read, update, and delete choices relate to meta actions on the AppSync api itself; add a new category named access or call GraphQL endpoint or something; move the Action appsync:GraphQL from create to this new category; update the docs at https://docs.amplify.aws/cli/function
@djsmedes thanks for reporting this issue, we'll look into it.
I can confirm this issue through testing.
_Thank you @djsmedes for the insight on what the Actions like appsync:Get* were actually doing._
Amplify should generate cloudformation to support the CLI like this.
:+1: this if you want me to take a stab at PR'ing for this.
Most helpful comment
I can confirm this issue through testing.
_Thank you @djsmedes for the insight on what the Actions like appsync:Get* were actually doing._
Amplify should generate cloudformation to support the CLI like this.
:+1: this if you want me to take a stab at PR'ing for this.