Boto3 after IAM

Use Python without hiding the AWS context

Boto3 is the AWS SDK for Python. A session supplies configuration and credentials to service clients. A client exposes operations for one service, such as STS identity calls or S3 object requests. The SDK can sign requests and handle protocol details, but IAM still decides whether an operation is allowed.

Use a separate Python virtual environment as taught in the Python module. Install boto3 there with python -m pip install boto3, then record its resolved version in your dependency record. Never embed real access keys in a script. A named profile, SSO session, or runtime role should supply real credentials through the supported provider chain.

Make the first response deterministic and offline

Before using a live account, save identity_stub.py:

import boto3
from botocore.stub import Stubber

client = boto3.client(
    "sts", region_name="us-east-1", endpoint_url="https://sts.us-east-1.amazonaws.com",
    aws_access_key_id="fixture", aws_secret_access_key="fixture",
)
expected = {
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/learning-fixture",
    "UserId": "fixture-user",
}
with Stubber(client) as stub:
    stub.add_response("get_caller_identity", expected, {})
    identity = client.get_caller_identity()
    print(identity["Account"])
    stub.assert_no_pending_responses()

Run python identity_stub.py. Expected output: 123456789012, an invented fixture account. The explicit dummy credentials avoid looking for real credentials, and the activated Stubber intercepts the matching operation rather than sending it to AWS. An unexpected or extra operation fails the stub expectation. This test proves response handling, not access to an account.

Compare with a real read only when you have access

With the previously configured learning SSO profile and an active authorized session, save and run this separate script:

import boto3
from botocore.config import Config

session = boto3.Session(profile_name="learning")
client = session.client(
    "sts", region_name="us-east-1",
    config=Config(connect_timeout=3, read_timeout=5,
                  retries={"mode": "standard", "total_max_attempts": 2}),
)
identity = client.get_caller_identity()
print(identity["Account"])
print(identity["Arn"])

This is a real AWS request to the commercial us-east-1 endpoint. Adapt the Region/partition to your assigned environment. Compare its actual caller with aws sts get-caller-identity --profile learning. If you have no access, keep this step unexecuted; the offline fixture is the available practice.

Connection and read timeouts bound individual waits. The retry configuration limits total attempts for this client; it does not make arbitrary writes safe to repeat. Expired login, missing credentials, service errors, and invalid response assumptions should remain distinguishable. Catch an expected ClientError where you can explain the service error code; do not convert every exception into an empty successful inventory.

Lists may have more than one page

A list API can return a page plus a continuation token. Use its supported paginator when you need the full inventory. For example, a proposed S3 inventory would iterate get_paginator("list_objects_v2").paginate(Bucket=...) and then each page's contents. A waiter instead polls until a modeled condition is met. Pagination collects results; waiting watches a state transition.

Checkpoint: why can the stub pass while the live call fails? The stub supplies a modeled response without authenticating or reaching AWS. Why use explicit credentials only in the stub? Those are nonfunctional fixture values; real requests should use the supported short-lived flow. Next, distinguish a stub from a running local AWS emulator.

References: Boto3 credentials↗, Botocore configuration↗, Stubber↗, and paginators↗.