Policy as Code

A policy document grants s3:Get* on one bucket, and a reviewer approves it in a few seconds because it obviously only allows reading. Some months later somebody notices that the wildcard also matched an action nobody had in mind when they wrote it, and that the resource pattern covered rather more than the one bucket. Nothing was maliciously written and nothing was obviously wrong on the page. The gap was between what the document says and what the evaluator does — and the only reliable way to close it is to be able to evaluate the document yourself.

That is what this track builds. You will implement policy evaluation the way a real engine does it: gather every statement that could apply, expand the wildcards to see what they genuinely match, and combine the results under the rule that makes the whole scheme predictable — an explicit deny beats any allow, anywhere, and if nothing matched at all, the answer is deny. Once you have written that evaluator, a policy stops being prose you interpret hopefully and becomes input to a function whose output you can check.

The second half is the harder engineering problem: reducing an over-broad grant to what is actually needed. Least privilege is easy to endorse and awkward to practise, because the honest starting point is usually a permission set that works, and nobody wants to be the person whose tightening broke production at two in the morning. You will take an over-broad policy and a record of the operations that are genuinely performed, and narrow the grant until it still permits all of them and nothing more — which is the real skill, and it is mechanical once you can evaluate the result rather than guess at it.