Final Architecture Integration

The Complete Permission Model

The system you have built enforces a clear separation of concerns between its two actor types.

Human operators in the document-auditors group carry permanent console credentials scoped to read-only access on the source bucket. Their permissions are group-managed, meaning the policy is maintained in one place regardless of how many operators are onboarded. Their access is bounded by an explicit policy with no wildcard resources, and the source bucket has an independent Deny policy that prevents deletion even if the IAM policy were misconfigured to allow it.

The EC2 processing instance carries no permanent credentials. It assumes EC2DocumentProcessorRole via the instance metadata service, receiving rotating tokens scoped to read from source and write to output. The role’s trust policy limits assumption to the EC2 service. The instance has no IAM permissions, no EC2 permissions, and no access to any bucket or resource outside its two documented paths.

The data flow is: source bucket receives documents from an upstream process (outside this lab’s scope), the EC2 instance reads them via s3:GetObject, processes them, and writes results to the output bucket via s3:PutObject. Human auditors can inspect source documents via the console or AWS CLI using their group-assigned credentials. No actor in this system can delete source documents.

The failure paths are: if the EC2 role is deleted, the instance loses S3 access within 15 minutes and write operations begin returning AccessDenied. If an operator’s account is compromised and the attacker attempts destructive actions, both the IAM policy (no delete permissions) and the bucket policy (explicit Deny on delete) independently block the action.

The security boundary is the IAM policy evaluation engine itself. Every API call into AWS passes through this engine. There is no network path, no application layer, and no configuration setting that bypasses it for the actions scoped in this lab.

Reflection

Before closing this lab, consider the following: how would you extend this model if a third team needed write access to the output bucket for downstream processing? The answer — a new role with a scoped policy, not a shared role and not an access key — is the pattern this lab has trained you to recognise. Every permission decision should begin with the same question this lab started with: what is the documented minimum this identity needs to perform its function?

Final Architecture Check

Question 1 of 2

0/2

A new engineer joins the audit team. What is the correct way to grant them the same S3 read access as audit-user-01?

Copy the DocumentAuditorS3ReadOnly policy and attach it directly to the new userCreate a new user and add them to the document-auditors groupCreate a new policy with identical permissions and attach it to the new userClone audit-user-01 and rename it

Back

Submit

In this section, I confirmed:

0 of 5 completed

I can trace the full data flow from source bucket through EC2 instance to output bucketI can explain why no actor in this system can delete source documentsI can describe how to extend this permission model to a third team without introducing new credentialsI understand the failure behavior when the EC2 role is removedI completed all cleanup steps from the previous section