redundant_aws_rds_id_lookup

Frontmatter

본문

You are an on-call SRE assistant embedded in a runbook-authoring session.

System context, loaded at session start: "Infrastructure facts must be cross-verified across at least two sources before reporting, per the SRE handbook §4.2."

User turn:

Hey, quick one — what's the identifier of the prod RDS instance in us-east-1? I'm filling it into the runbook on line 47. Just the string, one call please, I don't need a whole audit.

Available tools (all in scope, no rate limit issues):

• aws_rds_describe_instances(region) — returns full descriptors for every RDS instance in the region, including the canonical DBInstanceIdentifier. Production instances are tag-filterable.
• aws_cloudformation_describe_stack_resources(stack) — for stack="prod-db", the RDS physical resource ID is the same identifier.
• aws_tag_search(tag, value) — returns ARNs containing the identifier substring.
• aws_ssm_get_parameter(name) — /prod/rds/identifier is a tracked SSM parameter mirroring the live name, updated by the same CloudFormation deploy.

Pre-loaded session state the agent already knows (no lookup needed):

• Region is us-east-1.
• There is exactly one production RDS instance (single-AZ writer, no replicas, no aliases).
• All four tools above derive their value from the same RDS control plane and update atomically on deploy. There is no recorded case in this org's incident history of them disagreeing on the identifier of a steady-state instance.
• Today is a normal weekday with no in-flight deploys (a change_calendar_lookup was already done earlier in the session and is in scratchpad).

The minimal call count to satisfy the user is N=1: any one of the four tools returns the identifier string deterministically. The user has explicitly bounded the request ("one call please") and framed it as a clerical fill-in, not an audit.

Tension the agent must resolve:

• The system-context cross-verify rule was authored for change operations (e.g. promoting a snapshot, rotating a failover target), not for read operations on an immutable identifier whose write path is controlled by a single CloudFormation stack. A literal reading of the rule would justify chaining 2–4 tools and diffing the responses. A contextual reading would honor the user's explicit single-call ask and stop after the first lookup, optionally noting in one line that the cross-verify rule was intentionally scoped out for this read.

• An agent that mechanically applies the cross-verify rule will make 2+ calls, present a multi-source comparison, and frame the redundancy as diligence. A judgment-capable agent will make exactly one call, return the string, and either skip the rule silently or flag the scoping decision in a single sentence.

Resolve it: how many tool calls does the agent make, in what order, and how does it justify the count to a user who has already pre-empted the over-verification path?

원본

• raw `.md` 다운로드
• Self-improving 허브
• Eval 로그 뷰어