The DHCP server is not on VLAN 20, so the router interface Vlan20 must use the ip helper-address command to forward DHCP client broadcasts as unicasts to the actual DHCP server at 10.50.0.10. Without a correctly configured helper address, the DHCP messages never leave the local VLAN and clients remain unaddressed. This is the standard fix for a DHCP relay problem.
Why this answer
The SVI for VLAN 20 is forwarding DHCP requests to the wrong helper address. DHCP relay depends on the Layer 3 interface for that VLAN sending client broadcasts to the correct server. Trunks, access ports, and the DHCP pool name on the server are not the first issue shown here.
DHCP snooping can filter DHCP server replies on untrusted ports, but since other VLANs are working and no trust misconfiguration is indicated, the root cause is the incorrect ip helper-address on Vlan20.
Exam trap
A frequent exam trap is assuming that user ports must be trunks or that disabling DHCP snooping will fix DHCP address assignment issues. In reality, user ports should remain in access mode to maintain VLAN membership, and DHCP snooping is unrelated to this specific forwarding problem because the exhibit shows a misconfigured helper address while other VLANs function normally. Another common mistake is thinking that manually configuring a default gateway on clients solves DHCP problems, but DHCP discovery requires proper relay configuration on the Layer 3 interface.
Misconfiguring or omitting the ip helper-address on the VLAN interface causes DHCP requests to fail, which is the core issue here.
Why the other options are wrong
Disabling DHCP snooping is unnecessary because the other VLANs work, and the scenario does not indicate a trust misconfiguration; the real problem is the incorrect helper address on Vlan20.