AWS CloudOps Engineer (SOA-C03): The Over-Privileged Pipeline

The Over-Privileged Pipeline

A CI/CD pipeline runs in an AWS account and deploys to three environments: dev, staging, and prod, all in the same account. The pipeline's IAM role has AdministratorAccess because "it needed to create everything." Build logs are stored in an S3 bucket with default settings and no encryption. A security review finds that a developer's compromised laptop credentials could assume the pipeline role, and that the S3 bucket is readable by anyone with the account ID. The company is preparing for a SOC 2 audit and must demonstrate least privilege and encryption at rest.

1. Identify the specific risks and explain why the current design fails least privilege and audit requirements.

Read the worked answer

Risks:

Excessive blast radius - AdministratorAccess means a compromised pipeline credential can delete databases, exfiltrate data, or modify IAM to persist. The pipeline only needs to create/deploy specific resource types.
No environment separation - dev, staging, and prod share an account, so a dev-stage compromise reaches prod. There is no boundary the attacker must cross.
Credential compromise path - developer laptop → assume pipeline role → full account control. The trust policy is too broad.
Unencrypted logs - build logs often contain secrets or PII; unencrypted S3 fails encryption-at-rest controls.
Overly permissive bucket policy - account-readable logs leak build output to any principal in the account.

Why it fails audit: SOC 2 CC6 (logical access) requires least privilege and documented access reviews; CC7 (operations) requires monitoring; encryption-at-rest is a baseline control. AdministratorAccess on a CI role is a textbook finding.

2. Propose a remediation plan that satisfies least privilege and encryption without breaking the pipeline.

Read the worked answer

Least privilege:

Replace AdministratorAccess with a scoped policy listing only the actions the pipeline performs (e.g., ecs:RegisterTaskDefinition, ecs:UpdateService, s3:PutObject on the artifact bucket, iam:PassRole limited to the specific execution role ARN).
Separate accounts per environment (AWS Organizations) so prod has its own account and the pipeline assumes a cross-account role only for the target environment. This is the strongest boundary.
Tighten the role trust policy: restrict sts:AssumeRole to the CI system's OIDC provider and specific repo/branch, not to developer IAM users. Short session duration.
Enable CloudTrail and alert on sensitive actions by the pipeline role.

Encryption & access: 5. Enable SSE-KMS (or SSE-S3) on the log bucket; enforce with a bucket policy denying s3:PutObject without aws:kms. 6. Block public access; scope the bucket policy to the pipeline role and auditors only. 7. Enable versioning and access logging on the bucket.

Run the pipeline in a non-prod account first to validate the scoped policy before promoting to prod.