Salesforce enforces a strict architectural boundary regarding database transactions and external communications. When an Apex trigger executes, it is part of a synchronous database transaction. If the platform allowed a synchronous callout (a web service call) directly from a trigger, the database transaction—including all active record locks—would have to remain open while waiting for the external system to respond. This could lead to severe performance degradation and hit the "Concurrent Request" limit.

Consequently, calling a web service from an Apex trigger (Option C) must be handled asynchronously. A developer must hand off the callout logic to an @future(callout=true) method, a Queueable class, or a Platform Event. This allows the trigger to finish its work and commit the database transaction immediately, while the callout runs in its own separate background process with its own set of governor limits.

Option A is incorrect because a standard synchronous query can retrieve up to 50,000 records. Option B is incorrect because System.scheduleBatch is a synchronous call to initiate a process, even if the process itself runs later. Option D is incorrect because record updates can be handled synchronously in an after insert trigger context.