Amazon platform interview: Write a Python boto3 inventory collector for 200 AWS accounts. How do you handle pagination, STS role assumption, retries, throttling, and partial failure reporting?
Quick Answer
Use STS AssumeRole per account, create regional clients from temporary credentials, consume paginator APIs instead of single calls, configure botocore retries, and process accounts with bounded concurrency. Record per-account success, throttles, access-denied errors, and skipped regions so the inventory is trustworthy even when some accounts fail.
Detailed Answer
Imagine asking 200 branch offices to send you a list of every laptop they own. If you call only the first office, stop after the first page, or hide which offices did not answer, the final spreadsheet looks clean but lies. AWS inventory automation has the same failure mode: the script can produce a file while silently missing accounts, regions, or pages.
The core boto3 pattern is explicit. First call STS AssumeRole into the target account using a role created for inventory. Then build service clients with those temporary credentials and the target region. For list-style APIs, use paginators because many AWS APIs return only a limited page and a continuation token. The boto3 retry guide documents standard and adaptive retry modes, and production collectors should set retry mode and max attempts intentionally rather than relying on unknown environment defaults.
Concurrency must be bounded. A script that fans out 200 accounts times 25 regions times 10 services can create tens of thousands of API calls. Unbounded ThreadPoolExecutor usage will cause throttling, noisy CloudTrail, and sometimes organization-wide guardrail alerts. A mature collector uses a small worker pool, per-service backoff, and clear retry classification: throttling and transient network errors are retried, AccessDenied is recorded as an authorization gap, and validation errors are treated as code or configuration defects.
The output format matters as much as the API calls. Each account-region-service tuple should report status, item count, elapsed time, and error class. That lets platform teams distinguish no resources from no permission. For auditability, include the assumed role ARN, collection timestamp, script version, and schema version in the artifact. Large companies ask this because inventory data drives security posture, cost cleanup, and incident response.
The non-obvious gotcha is eventual consistency. A newly created role, instance, tag, or region opt-in may not appear immediately. Senior candidates mention rerunning collectors, comparing deltas, and designing consumers to tolerate late-arriving data instead of treating one scan as absolute truth.