Is hard real time possible with Ethernet technology?
You need to distinguish the two technologies collectively named "Ethernet" that is a misunderstanding at least from the normative point of view:

1) Ethernet itself, as a set of various Physical layer protocols standardized in IEEE Std. 802.3 not so far given the same name as the technology it described from its beginning;

and

2) 802.1 Bridging, also referred to as Switching, mostly known for working over IEEE 802.3-compatible PHYs (Ethernet), as a set of some Data Link layer protocols, among others most known are IEEE 802.1Q and IEEE 802.1D, described in the series of IEEE Std. 802.1-related publications.

For example, 802.1 Bridging works well too over Wi-Fi (IEEE 802.11) and  other non-IEEE 802.3 Physical layers.  IEEE Std. 802 explains on this:



Also, you need to distinguish the scope where you plan/need/must to use "Ethernet" effectively enough to reach the goal of your hard real time scenario:

A) a terminal device connected to the network, who has at least one, networking-dependent hard real time task in its responsibility;

and

B) a "bus" itself, i.e. the packet-switching infrastructure responsible for establishing the network for a hard real time tasking.

Therefore,


yes, it is possible to use Ethernet (see 1) in a hard real time task both on a terminal device side (see A) and as the data transmission technology on the physical layer of the networking infrastructure (see B);


meanwhile


various means exist to make "Ethernet" effective/suitable for hard real time tasking, as in the networking=packet-switching, where besides the  mentioned IEEE 802.1D and 802.1Q (see 2) other bridging-related and/or bridging-restricting protocols compatible (such as IEC 61850) and/or totally/partly incompatible (such as PROFINET) with IEEE 802.1-bridging are used, likewise as in a terminal device design, where to achieve a fast reaction and/or nice timing various means are also taken, among others popular today are asymmetric multiprocessing with a dedicated (like Arm's LITTLE.big approach) and/or specialized (like Texas Instr.'s PRUSS) processing core, and specific software based on accurate (like in FreeRTOS) and/or low-level (like in RT Linux) task scheduling.