The answers are 1A, 2B, 3D!
1A
DCSync is how, with the necessary permissions, we can obtain all the users and their NTLM hashes from AD. A long time ago, in a galaxy far, far away, Metasploit modules were often used to do this, some of which executing code on the DC in the process (which should generally be avoided wherever possible). DCSync allows us to get hashes without running any code on the box by impersonating a DC and leveraging the Directory Replication Service Remote Protocol (MS-DRSR), which is the normal way domain controllers replicate information amongst themselves.
Option B is true also, but the extra AD permission aren't necessary and the question asked for the least amount of privileges. Options C and D would allow DCSync because by default these groups have the option A permissions assigned to them, however ANY domain user with the option A privileges could perform a DCSync attack even if they're not Domain Admin or higher.
2B
resolv.conf is the file used to specify the DNS server for many Linux distro's. hosts.equiv contains a list of trusted hosts for the very old and legacy rlogin service, and the netplan file is where Ubunutu 18.04+ (and other distro's) stores your network config (i.e. IP address, mask, gateway etc).
The exports file lets you configure, who, and often from where, can access NFS shares and has a variety of security flags that can configured to lock shares down.
3D
Non-ephemeral keys are generated using a static public key. If the server's private key was compromised, an attacker could attempt to decrypt previous/earlier communications, e.g. attacker captures encrypted traffic between client/server, compromises private key at a later stage and would be able to decrypt all recorded communications.
Ephemeral keys are generated using a unique public key for each session a user initiates. By doing this, the compromise of a server's private key for a given communication means the attacker can't decrypt earlier (or future) comms. Using ephemeral keys results in something referred to as 'Perfect Forward Secrecy' (PFS).
4A - Not a lot to sat here, apart from nope!
4B - There isn't any bespoke encryption solely used for key generation.
4C - Nope. Plenty of obsolete SSLv3 configurations that can use ephemeral keys.