Please don’t do that, use a Script step instead and git clone the config repo there. More info about why you should not use the Git Clone step for any other repo, only for the main one can be found at: Can a bitrise "build" be triggered from more than one repository? - #4 by viktorbenei - or, alternatively, add the second repo as a submodule to the main repo, that will be handled automatically by the Git Clone step.
Other than that, the same thing applies for this solution what’s described at Managing an app's bitrise.yml file - Bitrise Docs
Define a “wrapper” build config on bitrise.io, which defines how and from where your bitrise.yml will be retrieved.
So, it doesn’t matter where you store the “build config bitrise.yml”, you can store it anywhere, just make sure that it’s downloaded/available before you’d run bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" on it.
One more thing, the simple bitrise run "${BITRISE_TRIGGERED_WORKFLOW_ID}" call only only works if you download/make the bitrise.yml available at the root of the repository (technically it have to be at the “current working directory”, which is by default the root of the repository, but can be changed with e.g. the Change Working Directory … step). You’re of course free to download it anywhere else, in that case you just have to specify where it’s located with the --config flag:
bitrise run --config /path/to/bitrise.yml "${BITRISE_TRIGGERED_WORKFLOW_ID}"