If/when should playbooks manage concerns across multiple hosts / groups?

[Andrew Feller]

Scenario: Application A needs 1) SSH access to Application B hosts and 2) database privileges to database on Database C hosts.

Solution 1: Application A's SSH access and database privileges managed with Application B and Database C playbooks

playbooks/a.yml
---
- hosts: a
  tasks:
    ...

playbooks/b.yml
---
- hosts: b
  tasks:
    - authorized_key: ...
    ...

playbooks/c.yml
---
- hosts: c
  tasks:
    - mysql_user: ...
    ...

This approach has security more in mind as different application / database owners would only have access to their hosts and thus are responsible for granting access.  The major downside is that playbooks for Application B and Database C must be performed before Application A can.

Solution 2: Application A's SSH access and database privileges managed with Application A playbook separate from Application B and Database C playbooks

playbooks/a.yml
---
- hosts: b
  tasks:
    - authorized_key: ...

- hosts: c
  tasks:
    - mysql_user: ...

- hosts: a
  tasks:
    ...

playbooks/b.yml
---
- hosts: b
  tasks:
    ...

playbooks/c.yml
---
- hosts: c
  tasks:    ...

This approach grants Application A access to the tangential resources it needs before installing and running the service at the cost of organizing Application B and Database C concerns.  This also assumes whoever is running Ansible has the ability to manage Application B and Database C hosts, which may not be the case.

Appreciate any insights and experiences you would share,
Andy