Which THREE are true about using flashback database in a Data Guard environment?

Flashback Database is a critical feature for rapid recovery in a Data Guard environment. It is fully compatible with real-time apply, allowing a physical standby to be quickly reverted to a point-in-time before a logical error (like an accidental table drop) was propagated from the primary. This capability is unaffected by the redo transport path, meaning a physical standby can be flashed back even if it receives its redo from a far sync instance. However, while Flashback Database is the primary method for reinstating a failed primary after a failover to a physical standby, it cannot be used for reinstatement after a failover to a logical standby due to the structural database changes that occur.

A. A Flashback Database operation on the primary is not automatically cascaded to a physical standby. The standby must be flashed back independently.
E. Flashback Database is the recommended method to efficiently reinstate a former primary database as a new standby after a failover to a physical standby.
F. Flashback Database is a physical-level operation and is not automatically propagated to a logical standby, which applies changes at the SQL level.

1. Oracle Database Data Guard Concepts and Administration, 19c - Chapter 13, Using Flashback Database and Restore Points in a Data Guard Environment:

For option D: Section 13.4, "Using Flashback Database for Recovery from Logical Corruptions," states, "You can use Flashback Database on a physical standby database to quickly recover from logical corruptions that have been propagated from the primary database. This is particularly valuable when real-time apply is in use..."

For option B & E: Section 13.6, "Using Flashback Database and Database Open Resetlogs," explicitly states, "You cannot use Flashback Database to return a primary database to a point in time before a failover to a logical standby." Conversely, Section 13.5, "Using Flashback Database After a Failover," describes its use to "convert the original primary database into a physical standby of the new primary database," directly contradicting option E.

2. Oracle Database Data Guard Concepts and Administration, 19c - Chapter 5, Far Sync Instances:

For option C: This chapter describes far sync instances as lightweight instances that only forward redo to other members of the configuration. The physical standby that receives this redo operates normally, including its ability to use local features like Flashback Database. The source of the redo does not alter the standby's capabilities.

3. Oracle Database High Availability Overview, 19c - Chapter 3, Oracle Data Guard:

For options A & F: The documentation describes Flashback Database as a command executed on a specific database (primary or standby). There is no mention of an automatic, cascading operation across the Data Guard configuration. Each database's flashback operation is independent.