Why do we need grantReadWriteData when I already attach a role to my lambda allowing all dynamoDB action?

I am looking at a sample project, it defines a lambda that has a role that allow it to do anything to the dynamoDB goals table

    const dynamoDbRole = new iam.Role(this, 'DynamoDbRole', {
      assumedBy: new iam.ServicePrincipal('lambda.amazonaws.com'),
    });

    const goalsPolicy = new Policy(this, 'GoalsPolicy', {
      policyName: 'GoalsPolicy',
      roles: [dynamoDbRole],
      statements: [
        new iam.PolicyStatement({
          effect: iam.Effect.ALLOW,
          actions: ['dynamodb:*'],
          resources: [goalsTable.tableArn],
        })
      ]
    });


     const functionUpdateGoal = new lambda.Function(this, 'FunctionUpdateGoal', {
      functionName: `${this.ProjectName}-UpdateGoal`,
      runtime: lambda.Runtime.NODEJS_12_X,
      description: 'Update goal for user id',
      handler: 'UpdateGoal.handler',
      memorySize: 256,
      timeout: cdk.Duration.seconds(120),
      role: dynamoDbRole,
      environment: { TABLE_NAME: goalsTable.tableName },
      code: lambda.Code.fromAsset(path.dirname('../functions/UpdateGoal.js')),
    });

But I also see

goalsTable.grantReadWriteData(functionUpdateGoal);

under it. I am confused as to why we need this line, isn't it sufficient to attach the role to the function to let it operate on the goals table? why do we need to also let the table grant the read and write? Why do we need to do it both ways in this case? Is it always like that when we grant right to resources?

No, only a single way is required. Using a role allows you to have more fine grained permission levels, whereas grantReadWriteData allows you to create a policy in a single line of code which is effective for almost most use-cases.