A custom HTTP client on a lobby kiosk signing AWS API requests fails with SignatureDoesNotMatch after the kiosk clock drifts. What SigV4 requirement is most likely involved?
Select an answer to reveal the explanation.
Short Explanation
SigV4 is picky about the wall clock—like a parking meter that rejects a sticker from yesterday. Sync the kiosk time, and keep credentials and region straight. Turning off TLS or using the root password is not a signature fix.
Full Explanation
SigV4 request signing incorporates a timestamp and a credential scope that includes region and service. When a lobby kiosk clock drifts beyond acceptable skew, AWS returns SignatureDoesNotMatch even though the access key material itself may be correct. Fix clock synchronization with NTP on the kiosk, confirm the custom HTTP client builds the canonical request and string-to-sign correctly, and treat chronic drift as an operational defect in public-facing hardware.
AWS APIs do not ignore timestamps; claiming clock skew cannot cause SignatureDoesNotMatch is incorrect. Replacing SigV4 with Basic Auth using the account root password is not a supported authentication model for AWS APIs and is grossly unsafe. Disabling TLS does not skip signature validation—TLS protects the channel while SigV4 authenticates the request independently.
Exam caveat: allowable skew is typically on the order of minutes; wrong time zones, stopped CMOS clocks, and handmade signers that omit x-amz-date are frequent root causes on custom kiosk clients. Operational check: sync the kiosk clock and retry the signed call to confirm success, then intentionally skew a lab device beyond tolerance to reproduce SignatureDoesNotMatch and add monitoring for clock offset on production kiosks.