The finding
The tooling flagged an IAM policy in a pull request: Resource = "*", marked as
overbroad. On its face that is exactly the kind of thing you want a reviewer to catch — a wildcard
resource in a permissions policy is usually a real problem, and it is the single most common
finding in any IAM linting tool.
It was wrong here. The AWS action in that statement does not support resource-level permissions
at all. For actions like that, "*" is not a shortcut or a lazy default — it is the only
value the service accepts. Narrowing it would not have made the policy safer; it would have made it
invalid.
What I did about it
I checked the service authorization reference for that action rather than arguing with the tool from memory, and confirmed it takes no resource-level scoping. Then I looked at what was actually containing the blast radius — the OIDC trust conditions around the role, which scope who can assume it and from where. That is where the real boundary lived, and it was already tight.
So I dismissed the finding, and I wrote down why. Not “false positive” — the actual reason, in the pull request, so the next person who sees the same flag on the same action does not have to redo the research.
This is the whole argument for keeping a human as the final gate. The tool was not malfunctioning — it applied a good general rule. Knowing that the rule does not apply to this action is the part that has to come from someone who understands the service, and it is not something you can prompt your way to.
The other direction
The same tooling caught something a human review would probably have passed. A change created an
RDS instance in valid, working Terraform — but never explicitly disabled
publicly_accessible, against a standard that required private access. Nothing was
syntactically wrong. The requirement simply was not expressed anywhere in the code, and the default
is not the safe one.
That gap is why my rds-terraform-provisioner skill carries a Gotchas section listing
publicly_accessible defaulting to true when requirements go quiet. I hit it, so I
encoded it. The skill also refuses off-the-shelf modules outright and asks rather than guesses on
anything security-shaped — assume-and-flag is fine for the rest.
What I actually think this is worth
Reviewing work you did not write is an ordinary engineering skill and it is the one that agentic tooling makes load-bearing. The interesting question in an interview is not whether I use these tools. It is whether I can tell you about a time one of them was wrong, what it cost to find out, and what I changed afterwards.
Those are the two cases above: one where it was right and a human would have missed it, one where it was wrong and only knowing the service saved the change.
← Back to components · Resume (PDF) · tatiarazmadze.t@gmail.com