Depends on what you're after here.
By and large, you mainly need to be mindful that:
- These are servers
- ... they're coming in through the CSA
... so you can't push stuff out TO them (assuming here that the Core doesn't have direct access to the DMZ), but rather rely on THEM checking in with the Core (both for policies & patches). This *can* complicate things when you're got patch maintenance windows configured, but then don't run those repair jobs during those maintenance windows.
You might want to consider creating / using something like a scope "just for those guys" so that you can do scope-based auto-fixing ... so that they automatically patch vulnerabilities as they detect them, and "simply" control (very tightly) WHEN they scan for vulnerabilities.
Problem with that is of course that you may not want to enable all patches for all systems like that - often stuff like .NET and/or Java versions can be very sensitive to the software running on those servers.
... so THOSE are the problems I would envisage for you to have to solve. Other than that, "it's just regular" going through the CSA to the Core stuff.
Was there anything in particular that concerned you?
I'll keep those things in mind.
The thing that concerns me is the ease of getting the Server in the DMZ to communicate with the CSA. I have already determined that I can't access the external facing IP for the CSA from a server in the DMZ. I can access the internal IP for the CSA. Is that enough or will name resolution along with routing to the outside and back in be needed.
"shouldn't" - since you can't use name resolution to poke clients "out there, in the wild internets" either.
And since the only software / vulscan related packages that can be downloaded *TO* clients must be on the Core itself, you should be fine there (which is another point - you'll HAVE to host the patches on the Core, because you won't be able to access any "alternate server" through the CSA). It allows for connections to the Core only.
Now Patch stores its content & patches on the Core by default anyway - but it can be a bit of a surprising disk muncher (especially if you have multiple languages to be mindful of) - so just something to watch out for. People can easily go over 1 TB of storage for patches alone.
Actually, there is one exception here... In the Distribution and Patch settings you could configure that patches come directly from their vendor on internet when deploying through a CSA.
So that could be a concern less...