I think you need to be more specific about what you mean by "What happens if Alice explicitly does not trust C." Alice, and only Alice, has decided not to trust C, or A has revoked C's certificate?
My understanding of Alice's (abstract) process is:
// find a signature that she can verify
1. Alice will see that
cert_Doris is signed by
cert_C and ask "do I have a verification key for
cert_C?" .... No.
cert_C is signed by
cert_A, "do I have a verification key for
cert_A?" ... Yes.
// then go back down the chain actually performing verifications
3. Does the signature on
cert_A check out, and is the certificate valid (ie not revoked)? ... Yes
4. Does the signature on
cert_C check out, and is the certificate valid (ie not revoked)? ... Yes
5. Does the signature on
cert_Doris check out, and is the certificate valid (ie not revoked)? ... Yes
6. Now Alice trusts Doris because they have a common anchor of trust.
The details of this process will obviously depend on which PKI software your organization uses.
As @MaartenBodewes points out: notice that this process does not require Alice to be connected to A, in fact, that process would work fine for Eric who doesn't even have certificates himself, as long as he has decided to trust A. (This is how certificate pinning in browsers works, since TLS clients typically don't have certificates, they are like Eric.)
What happens if Alice explicitly does not trust C.
It's entirely possible that your PKI software will allow Alice (or any of the CAs above Alice) to blacklist a specific user, or a specific CA, without globally revoking their certificate, though I've never actually heard of a PKI which offers that.
Does Alice need to have a certificate of D, B and C as well?
Technically no, having the verification key for A is cryptographically sufficient, though for large organizations, like a government, with many many departmental CAs and users, doing a full search every time can be very slow, so Alice may locally cache certificates once she's deemed them trustworthy so that future searches are faster. This could lead to security problems if revocation is not checked all the way back to the root each time. That's up to the specific software, and the organization's policies to decide if that risk is worth the inconvenience of slow searches.