Something weird is going wrong. When you rotate the parent, it does rotate all of its children. Which indicates that the thing you’re spawning is not actually being made a child of the desired parent. This is why I asked up there if you were certain that parentPos actually had been assigned, because if you’d accidentally left it null, you’d get a parentless object spawned as you were seeing. However, you’re accessing parentPos’s position in this new code and not getting an exception, so clearly it’s not null. That’s a contradiction - let’s see if we can figure out what it is.
That instantiate call is currently full of stuff you’ve added to try and compensate for whatever this weird wrong thing is, so let’s get that back to a simple version that isn’t trying to fix problems elsewhere:
var spawned = Instantiate(obj, parentPos);
spawned.transform.localPosition = new Vector3(0f, 4f, 2f);
This will create your object, make it a child of the parentPos, set it at that parent’s (0,4,2) relative position. And when you later rotate that parent, the child will rotate with it.
Note: I separated the position setting into a new line because Instantiate has some confusing, but documented, behavior with regard to world vs local space in the all-parameter override: “If the position and rotation are specified, they are used as the object’s position and rotation in world space.” This is, tbh, weird - I think any experienced dev would expect that to be local space by default. In practice, that particular override is hardly ever used - since I was under the wrong impression about what space it was in I clearly have never used that override, and I’ve been using Unity 16 years. Usually you want to either instantiate under a parent (and therefore will want the position to be relative to that parent), or instantiate at a particular place in worldspace (not caring what the parent is), but almost never both. In your scenario, you care about the object’s parentage and its local position, but not its world position. So we end up with setting local position after spawning.
This wrong assumption - that the position and rotation supplied in this method would be in the parent’s local space - was I think shared by both you and me in the first couple of comments up there, and probably explains the original question. However it would not explain why the spawned object isn’t moving/rotating with the parent.
So anyway - after you have that code, run it and see what happens. Check where the object spawned in the Hierarchy window - is it a child of the parent you expected? It should be, but I have a sneaking suspicion that it isn’t. If it isn’t, then you may have some other script on the object being spawned setting its own parent to null, or something like that.
If it is correctly parented, then check to see if the child moves when the parent object moves. If so, problem solved? If not, then maybe there’s some code running on the child object forcibly setting transform.position and/or transform.rotation, which will overwrite movement it inherits from its parent.