Which redo transport mode and protection mode would you…

D

I think:

A – This is not true! The maximum protection mode requires transport mode SYNC/AFFIRM
B – This is not true! Is possible to have a standby database with SYNC/NOAFFIRM in Maximum availability, but, in the case of a double failure, you can loss data!
C – This is wrong! You can loss data if your environment have a gap and you loss the connectivity with primary database.
D – This is not correct! In this case, possible with either maxavailability and maxprotection mode, the commit occurs only when the data are write to at least one standby database, so, you don’t have data loss. But, this is not the highest level of protection mode possible.
E – This is correct! In this case, possible with either maxavailability and maxprotection mode, the commit occurs only when the data are write to at least one standby database, so, you don’t have data loss. This is the highest level of protection mode possible.

Reference:
https://docs.oracle.com/database/121/SBYDB/protection.htm#SBYDB4744
Oracle® Data Guard – Concepts and Administration 12c Release 1 (12.1) – E48552-07
Performance Versus Protection in Maximum Availability Mode
When you use Maximum Availability mode, it is important to understand the possible results of using the LOG_ARCHIVE_DEST_n attributes SYNC/AFFIRM versus SYNC/NOAFFIRM (FastSync) so that you can make the choice best suited to your needs.
When a transport is performed using SYNC/AFFIRM, the primary performs write operations and waits for acknowledgment that the redo has been transmitted synchronously to the physical standby and written to disk. A SYNC/AFFIRM transport provides an additional protection benefit at the expense of a performance impact caused by the time required to complete the I/O to the standby redo log.
When a transport is performed using SYNC/NOAFFIRM, the primary performs write operations and waits only for acknowledgement that the data has been received on the standby, not that it has been written to disk. The SYNC/NOAFFIRM transport can provide a performance benefit at the expense of potential exposure to data loss in a special case of multiple simultaneous failures.
With those definitions in mind, suppose you experience a catastrophic failure at the primary site at the same time that power is lost at the standby site. Whether data is lost depends on the transport mode being used. In the case of SYNC/AFFIRM, in which there is a check to confirm that data is written to disk on the standby, there would be no data loss because the data would be available on the standby when the system was recovered. In the case of SYNC/NOAFFIRM, in which there is no

Oracle Data Guard 11gR2 Administration Beginner’s Guide
AFFIRM and NOAFFIRM
These attributes control when the destination database acknowledges received redo data. Two options are before and after writing to the standby redo log. The AFFIRM attribute ensures that a redo transport destination will send an acknowledgment after writing it to the standby redo logfiles; NOAFFIRM ensures that the redo transport destination will send an acknowledgment before writing it to the standby redo log. This attribute is used with the SERVICE attribute when specifying remote destinations. To view the attribute configuration, you can use the v$archive_dest view with the AFFIRM column.
If both AFFIRM and NOAFFIRM are not specified, it defaults to AFFIRM when the SYNC attribute is specified and NOAFFIRM when the ASYNC attribute is specified.