✳ Practice range / Cloud shared responsibility and least privilege / 12 min

Whose mistake is on the screenshot?

Two simulated cloud console exhibits from Meridian Space & Robotics reveal an exposed object-storage prefix and an over-privileged workload role. Identify who owns each failure under shared responsibility, choose the first fix, and specify the positive and negative verification evidence.

YOUR CASE FILE

The synthetic tabletop identifier is CLOUD-044.
Meridian Space & Robotics (chronos.orbital) is a fictional aerospace enterprise.
This exercise touches no live cloud account, and every console exhibit below is marked SIMULATED.

Case A is an object-storage bucket.
The bucket name is chronos-telemetry-exports.
The prefix is customer-exports/.
The bucket policy grants s3:GetObject to Principal *.
Block public access is set to Off.

Case B is an IAM workload role.
The role name is analytics-export-worker.
The attached policy grants Action * on Resource *.
An automated nightly batch job assumes this machine role.
Human console MFA prompts do not apply when the batch job assumes the role.

The batch job only needs read access to objects under batch-input/.
The job must never delete objects, modify IAM or bucket policies, or read other prefixes.

Your review record must name the responsible owner, the immediate configuration fix, and the verification evidence (including the unauthorized calls that must now fail).

Download the synthetic case ↓

SIMULATEDAWS-like object store

Case A · customer-exports/ is world-readable

Account: Meridian Space & Robotics (chronos.orbital, fiction)
Bucket: chronos-telemetry-exports
Prefix: customer-exports/Public prefix
Statement: Allow s3:GetObjectCustomer policy
Principal: *Anyone
Block public access: OffCustomer setting

Granting world-readable GetObject access on customer-exports/ is a customer configuration and data-governance failure, not a flaw in the cloud provider’s physical data centers.

SIMULATEDAWS-like identity console

Case B · analytics-export-worker can do anything

Role: analytics-export-worker
Trusted by: Batch job (machine identity)
Action: *Data-plane wildcard
Resource: *No resource boundary
Job needs: Read under batch-input/ onlyThe whole job
Human MFA: On for console usersDoes not apply to this role

Enforcing MFA on human workforce logins does not constrain a machine role assumed by a batch worker. Proving least privilege requires both positive tests (the required read succeeds) and negative tests (unauthorized reads, deletes, and policy edits are denied).

Complete this responsibility matrix as you work through the two console exhibits.
Case	Owner	First fix	Verification
A · public object store	Open	Open	Open
B · over-permissive role	Open	Open	Open

Your answers stay in this browser. This exercise uses fictional data and makes no changes to any system.

Step 1 of 4

Case A shows public GetObject access on customer-exports/. Under the cloud shared-responsibility model, who owns this misconfiguration?

CASE REFLECTION

Result and takeaway

first decisions matched the scenario’s best-supported answer.

In public cloud environments, bucket exposure and wildcard workload roles are customer-owned failures. Shrink the policy to the exact prefix and action required, and prove the boundary with both passing allowed calls and logged denied calls.

Completed shared-responsibility record for Meridian Space & Robotics (simulated).
Case	Owner	First fix	Verification
A · public GetObject	Customer: configuration, identity, and data	Enable Block Public Access and remove Principal * from customer-exports/	Policy diff plus Block Public Access enabled and a cleared access-analyzer finding.
B · Action * / Resource *	Customer: the workload role	Replace the wildcard policy with read-only access scoped to batch-input/ only	Policy diff plus test evidence: the batch-input/ read succeeds, while Delete, policy change, and a read outside batch-input/ are denied and logged under analytics-export-worker.

Another case ↗