To best explain the question, we have to know what the difference is between logical corruption and physical corruption.

Logical is data corruption. For example nologging operations are performed on primary with end result no redo to recover standby database. You end up with logical corruption on standby. This can be normal operations during batch jobs / staging tables etc where nologging is used, so if the standby has logical corruption on these tables that is fine, it can be recreated. If a user by mistake update data on primary and it filters through to standby, which is also a form of logical corruption, we cannot control that.

Standby use archive logs to recover the standby database so if the primary is corrupt on a physical blocks then the archive logs will most likely not apply to the standby and stop there, oracle will not allow us to apply any archive log , if its corrupt.

The user can schedule dbverify checks on the database at any time outside the Standby product to add additional checks, or use RMAN scripts to do some validation checks.