SCS-C02 Management and Security Governance Practice Question

Exhibit

Refer to the exhibit.

$ aws iam get-account-authorization-details
{
    "UserDetailList": [
        {
            "UserName": "admin",
            "AttachedManagedPolicies": [
                {
                    "PolicyName": "AdministratorAccess",
                    "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
                }
            ]
        },
        {
            "UserName": "svc-account",
            "AttachedManagedPolicies": [
                {
                    "PolicyName": "ReadOnlyAccess",
                    "PolicyArn": "arn:aws:iam::aws:policy/ReadOnlyAccess"
                }
            ]
        }
    ],
    "GroupDetailList": [],
    "Policies": [
        {
            "PolicyName": "CustomReadOnly",
            "PolicyId": "ANPA...",
            "AttachmentCount": 1,
            "PolicyVersionList": [
                {
                    "Document": {
                        "Version": "2012-10-17",
                        "Statement": [
                            {
                                "Effect": "Allow",
                                "Action": ["ec2:Describe*", "s3:Get*"],
                                "Resource": "*"
                            }
                        ]
                    }
                }
            ]
        }
    ]
}

A security engineer runs the get-account-authorization-details command and sees the exhibit output. The engineer wants to ensure that the 'admin' user does not have administrative access. Which steps should be taken?

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Detach the AdministratorAccess policy from the 'admin' user and attach a custom policy with read-only permissions.

The 'admin' user has the AdministratorAccess policy attached, granting full administrative rights. To remove administrative access, the engineer should detach this policy and attach a custom policy with read-only permissions (Option C). Option A is unnecessary because deleting the user is not required; detaching the policy is sufficient. Option B is incorrect because modifying the AdministratorAccess policy to deny all actions would still leave the policy attached, potentially causing confusion or unintended effects; better to detach it. Option D is wrong because attaching a permissions boundary does not remove the existing AdministratorAccess policy; the user would still have administrative access via that policy.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Delete the 'admin' user and create a new user with limited permissions.
Why it's wrong here
Deleting the IAM user and recreating a new user with limited permissions is an unnecessarily destructive and disruptive action. It removes the user's credentials, MFA devices, access keys, and any other attached policies, and it does not address the root cause: the AdministratorAccess policy is still attached to the original principal. The same least-privilege result can be achieved by simply detaching or replacing the policy on the existing user, preserving all other user attributes. Deleting the user also risks breaking any processes, scripts, or roles that reference that user's ARN.
✗
Modify the AdministratorAccess policy to deny all actions.
Why it's wrong here
AdministratorAccess is an AWS managed policy, and AWS does not allow customers to modify or edit managed policies — you can only create customer managed policies or attach/detach AWS managed ones. Even if modification were possible, rewriting it to deny all actions would be a global change affecting every principal that has the policy attached, and it would not be scoped to the 'admin' user. A proper fix is to replace the attached policy with a customer managed read-only policy, not to alter an AWS provided policy that other users or roles may depend on.
✓
Detach the AdministratorAccess policy from the 'admin' user and attach a custom policy with read-only permissions.
Why this is correct
Detaching the AdministratorAccess policy from the 'admin' user directly removes the administrative privilege, while attaching a custom read-only policy grants only the permissions needed for the user's job — a least-privilege approach. The user keeps its IAM identity, credentials, MFA, and other configuration, making this the minimal, reversible change. This should be combined with a review of the custom policy's actions and resources to ensure it truly limits access to read-only APIs.
✗
Attach a permissions boundary that denies all actions.
Why it's wrong here
A permissions boundary is a guardrail that defines the maximum permissions a principal can receive, but it does not remove or replace the existing AdministratorAccess policy attached to the user. If the boundary is later detached or changed, the user's full administrator access would be restored, so this is not a durable remediation. Moreover, a boundary that denies all actions would effectively lock out the user rather than grant them read-only access, which is not the stated goal. The correct approach is to remove the excessive policy, not to layer conflicting policies on top of it.

Go deeper

SCS-C02 Management and Security Governance Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question