The instance metadata service explained

WHAT THIS TESTS The interviewer wants to see that you build cloud-aware applications that discover context and fetch credentials dynamically rather than hardcoding them.

A GOOD ANSWER COVERS Describe the metadata service as a special link-local HTTP endpoint, on AWS at 169.254.169.254, reachable only from within the instance. It returns metadata about the instance itself: its ID, type, region and availability zone, private and public IPs, attached network interfaces, and the user-data script supplied at launch. Most importantly, when an IAM role is attached, the service vends temporary, automatically rotated credentials that the SDK retrieves transparently. Applications use this to self-configure based on region or AZ, to discover their identity for logging and service registration, and to authenticate to other cloud services without any stored secret. Azure and GCP expose equivalent metadata endpoints.

COMMON WRONG ANSWERS Thinking you must bake static access keys into the AMI or environment. Believing the endpoint is reachable from outside the instance. Ignoring security hardening, leaving the v1 endpoint open to server-side request forgery, where a compromised app proxies a request and steals role credentials.

LIKELY FOLLOW-UPS How does IMDSv2 mitigate SSRF with session tokens and hop limits. How are role credentials rotated and how does the SDK find them. What goes in user-data versus metadata. How do equivalents work on Azure and GCP.

ONE CONCRETE EXAMPLE A service launched with an IAM role granting read access to a config bucket starts up, and its SDK silently calls the metadata service to obtain temporary credentials, then reads its configuration from the bucket. The app also queries the service for its availability zone to register itself with the correct regional shard, all without a single hardcoded key, and the operator enforces IMDSv2 so a vulnerable dependency cannot exfiltrate those credentials.