That looks like it might be a Law of Demeter violation. The problem has nothing to do with dependencies.
The issue is reaching past objects and violating their abstraction. This is an issue because if even one client writes code like:
container.DependencyA.DependencyAA.Method() then that whole chain is set in stone. You have no freedom to build it any other way. If the client had referred to it as
depAA.Method() then we'd have some flexibility.
Now this isn't to say that you never want to see a chains of dots. After all the Law of Demeter is not a dot counting exercise. Long dot chains are fine when you've been promised that the path will always hold true. For example Java8 streams have you dotting together wonderfully long chains. That's OK because those chains are expected. You have been promised that they won't change.
The problem is when client authors go delving into the code base and stitch together whatever paths happen to work. Now this carefully decoupled code base is bound together in a ball of mud because someone kept reaching for what they needed rather than simply asking for it to be handed to them.
The idea is that it's better for each object to have a few friends that it knows how to talk to. Those friends have friends they know how to talk to. If you talk to your friends friends soon you have to know how to talk to everyone. That's bad if we ever want to be able to implement a change because everything ends up being impacted by the change. Value not knowing to much.
Use facades, abstraction, and dependency injection to keep clients from knowing how your object graph is wired together and you retain the freedom to wire it together as you see fit.
If you must allow for chains then be sure to decouple the chain from the implementation underneath. These are called internal Domain Specific Languages (iDSL). They are very powerful but take a lot of work to set up. The allowed chains form the mini language. Be sure you can swap out the implementation behind the chain.