1. What is the nature and description of the request?
   The existing AAP 2.5 HashiCorp Vault Lookup Credential Type mandates the specification of the HashiCorp Vault secret key. The plugin associated with this credential type does not allow the return of the `data.data` JSON response element to the AAP Credential field value invoking the Lookup. This limitation prevents the retrieval of HashiCorp secrets comprising multiple keys/values.

1. Why does the customer need this? (List the business requirements here)

There is a need to call the HashiCorp Vault database secret engine mount point using HashiCorp Vault approle (Secret ID, Role ID) authentication via the HashiCorp Vault Read API endpoint. This endpoint path is set to a HashiCorp Vault Role with a policy allowing requests for dynamically created, short TTL, MS SQL database login credentials. The response includes values for both the username and password keys for the single MS SQL login. 
 
Using the AAP 2.5 built-in HashiCorp Vault Secret Lookup Credential Type to retrieve the username and password keys necessitates two separate calls to the HashiCorp Vault database secret engine to populate the distinct fields (username and password) of an AAP Credential usable in a Job Template. The HashiCorp Vault database secret engine generates a new DB login for each request. Consequently, the AAP Credential ends up with the username from one dynamically generated DB login and the password from another.
This exposes the approle credentials and compromises the AAP Credential RBAC.

1. How would you like to achieve this? (List the functional requirements here)

This can be avoided if the AAP 2.5 built-in HashiCorp Vault Secret Lookup Credential Type either did not necessitate the key name or allowed the "data" element in the key name to return the entire `data.data` object from the HashiCorp Vault JSON response. The AAP HashiCorp Vault Secret Lookup Credential Type should enable this data object to be passed as an Extra Var. This would eliminate the need to expose the approle secret ID and role ID as Extra Vars to Playbook developers and negate the necessity for a Playbook Task to call HashiCorp Vault.
 
The Playbook tasks could then parse the extra var data object to obtain any number of key/values from the original HashiCorp Vault secret without any direct interaction with HashiCorp Vault, which appears to be the main intention of the current AAP 2.5 built-in HashiCorp Vault Secret Lookup Credential Type.