Thanks Balonik - I appreciate your input …
In our case, Ops would like to devolve the keying of sudo rules such that Devs can build their own applications in pre-prod then Ops review the applications (and sudo config) before Prod build-out. Ops would also like to approve or at least monitor the sudo rules that the Devs program in their branches to ensure they are aware of the security being applied on our estate. The main reasons for the requirement are velocity (time to market) for our business and convenience (avoid ticketing system) for Dev and Ops.
This requirement is an edge case for us - the config management code that Dev and Ops own is indeed typically kept in separate repositories as you expect. Essentially, I am trying to make the most of the set-up we have in place which is not ideal for this particular purpose.
I take your point regarding the lint in the pipeline. On the upside on that front, we can detect who changed what file via Git and so periodic checks would implicitly highlight any amendments to pipelines in feature/dev branches (which are subject to merge request before becoming Production / Master).
Fundamentally, I accept that we would be bending Gitlab out of normal shape & practise for the reasons highlighted and I could include that stipulation when I propose the custom lint option. Your approach of Ops managing the sudo rules (with all branched protected) in their repo is the natural solution but introduces delay and procedural complexity. Giving Devs access to adjust only the sudo files in the Ops repo is another option.
Overall, this conversation gives me enough food for thought, so thanks to you and snim2 for helping.