# Prove that the worker cannot delete its source data

Positive tests establish functionality. Deliberate denial tests establish the boundaries that make a service identity useful.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Prepare safe resources and the real identity path

Create synthetic input and output resources in an isolated test environment. Deploy the workload through the same identity mechanism used in production, with environment-specific scope.

Confirm which principal the runtime is actually using. A local test can accidentally succeed through a developer's broad credentials while the intended service role is never exercised.

Run the normal read-and-write workflow first so later denials are not confused with a broken credential setup.

## Attempt a small set of prohibited operations

Try reading outside the approved input scope, deleting the synthetic source and changing an unrelated configuration. Expect explicit denial under the provider's documented behaviour.

Use harmless test targets and avoid destructive experiments on production data. The test's purpose is to verify policy evaluation, not create a realistic incident.

Record the action, resource and decision. A generic failure is insufficient if it occurred because the resource did not exist rather than because access was denied.

## Test the trust boundary separately

Attempt to obtain the workload identity from an unintended test caller. A narrow permission policy is still exposed if another service can assume the role without authorisation.

Check relevant environment, repository or service conditions in the chosen federation mechanism. Use the platform's supported tools rather than crafting an ad hoc credential exchange.

Also test that the legitimate deployment continues to obtain credentials after renewal. Temporary access must remain both bounded and operational.

## Exercise uncommon recovery paths

Cause a partial output failure and run cleanup or retry. Verify that the required recovery action succeeds without granting unrelated administration permissions.

For a synthetic month-end path, the worker may read an additional approved partition that ordinary daily tests never touch. Include it explicitly in fixtures instead of assuming recent access logs cover the whole job.

Review any failure against the operation matrix and effective policy context. A passing suite demonstrates the intended allow and deny cases for the tested environment, while remaining coverage gaps should stay visible.

## Sources

- [AWS: IAM security best practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)
- [AWS: policy generation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)