Borrowing from the other answers & comments coz I agree with them:
Deflect = Not-the-same-as reflect back to the attacker.
The common practice that comes to mind in this context is this:
Your assets can be protected using deflection to a honeypot.
...the armor is between the targets body and the bullet and the bullet
has to go through the armor.
I can't think of many situations where a honeypot sits in between the attacker and the assets under protection. That is usually the role of a firewall (network firewall or a web application firewall of some sort).
Honeypots in practice - how they protect by distracting.
It can be a low interaction honeypot (the most common case because it is easier to setup and maintain) that is placed in such a manner that deflects the attention of the attacker by appearing to be easy to hack and sets up protection for main assets.
e.g., To protect x.yourasset.com, you could setup x-be.yourasset.com and x-private.yourasset.com as honeypots where no legit customer should normally connect to. When someone connects to them, you use some form of scripted automation that bans them from reaching *.yourasset.com. Here the ban-trigger is simply connecting to the honeypot. No deep interaction is needed.
An intermediate interaction honeypot (again fairly common) would allow an attacker to connect and give them an infinite-looped path e.g, allow SSH connect with a non-existent account and password; then present a fictional file system with never ending directories to traverse. This wastes attacker time and may or may not directly help your asset-security unless you also use this with some form of banning.
In both the above cases, the honeypot is not "placed in front of" the asset.
Another possibility is to use high interaction honeypots (uncommon). This takes some effort to setup and manage. Here, you let the user interact with your main asset, but if you see anything unusual at all, switch the session to the honeypot.
e.g. Your web-form could have legitimate sounding hidden fields (e.g., spl-discount, secret-auth) that normal flow would never populate. On your server you first check those fields and if they're populated you send a redirect to a honeypot. You could also do this using something like the OWASP AppSensor project.
- that looks like a normal successful submission - "thank you... processing..."
- that takes several seconds for each screen update and wastes more time - "thank you for your patience..."
- that could keep asking for more info - "we only need some more information before we complete processing" "we sent you an additional security code to your email address ... please enter it to verify your account for additional security" (of course you may not have sent any code at all)
- and finally blows it off with something like "we're sorry, please try again later".
This may or may not be combined with banning but it helps in many ways, including data collection about the attacker and their TTPs (Tools, Techniques and Procedures) - that will come handy in other defensive measures.