A strong answer
In a Raft cluster, a leader commits entries under protocol rules that include replication to a majority and term-related constraints. Any two majorities overlap, which helps a later leader discover and preserve committed history. The safety claim depends on Raft's election and log-matching rules; “three copies exist” alone is not a complete proof.
A quorum is also an availability threshold. A three-node cluster can continue committing with two reachable members, but not with only one. During a partition, the majority side can make progress while the minority cannot safely commit new entries. This is the safety and availability trade-off under that failure model, not a statement that all requests always return quickly.
A client timeout still leaves uncertainty about whether its command committed or whether only the reply was lost. The application may need an operation identifier to make retry behavior safe.
Follow-up direction
Draw two competing partitions and explain which can elect a leader, then distinguish replicated from committed and committed from applied.