This is an old one but for future reference.
The first one is required in order to bring up the service initially (while creating your pre-configured cluster).
You can consider the second one as an option to update your service (deploy a new version of the image) over the initial one during your GitHub Actions deployment (as you can change the image id and basically everything that you have as a configuration option in the task definition).
With regard to terraform you can add a lifecycle rule to ignore any changes to the pre-configured image_id with something like this in the aws_ecs_service:
lifecycle {
ignore_changes = [task_definiton]
}
There is quite an old issue in the terraform-provider-aws project with regard to how it handles task definition changes. Take a look at this comment for a possible workaround for your use case (blog post on topic from the comment author).
Down below you can see another comment linking a ready-to-go Github Actions solution with a terraform code example.