From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

The configuration cache entry is tied to the tasks that are going to be executed (or probably the ones requested to run, not fully sure).
That also is important.
Theoretically - even though it is bad practice - you could have something like
```tasks.taskB {
    tasks.taskA {
        taskAProperty = "A"
    }
}```
where `taskA` is only configured if `taskB` is configured. So if you execute `taskA` without `taskB` it is configured differently.

Also the whole configuration phase including init script, settings scripts, and so on is all skipped and the task state restored from cache and immediately executed.

So a CC entry as a whole can only be reused for the same set of tasks that is going to be executed.

I thought every task is configured irrespective of which task is going to be executed . If that is true then in the example you shared `taskAProperty` will get configured irrespective of whether `taskB` gets executed or not , especially because setting taskAProperty is not inside taskB's action. 

Maybe my understanding of configuration phase is flawed .

If all tasks are configured, then you broke <https://docs.gradle.org/current/userguide/task_configuration_avoidance.html|task-configuration avoidance> and waste pretty much time on every Gradle execution.
The goal of a good build is, that really only those tasks are configured that are actually going to be executed.
You can easily break this for all tasks when for example doing `tasks.all { ... }` or `dependsOn(tasks.matching { it.name == "abc" })` or some other things, but that could be considered a build bug.

And configuring any task (does not matter whether itself or another task) from the execution phase of a task is bad practice and with configuration cache enabled also not allowed.
With configuration cache all tasks that do not depend on each other are allowed to run in parallel which additionally speeds up the build besides skipping the configuration phase and if one task would be allowed to configure any other one would break this.