SY0-701 Security Architecture Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Create one shared administrator account and rotate its password every week.

  Why it's wrong here

  Sharing one administrator account across multiple admins destroys individual accountability because all actions trace to a generic identity, making non-repudiation impossible. Even weekly password rotation leaves the account with permanent elevated rights, and there is no time-bound approval step to control when administrative access is used. This configuration increases the risk of credential theft, insider misuse, and unauthorized changes, while providing no just-in-time elevation or audit trail linking a specific person to a specific action.

• ✗

  Assign permanent administrator rights through role-based access control and rely on audit logs afterward.

  Why it's wrong here

  Permanently assigning admin rights via RBAC creates standing privilege that remains active even when no administrative task is being performed, enlarging the attack surface and blast radius if the account is compromised. Audit logs are detective controls that only record activity after the fact; they do not proactively prevent an attacker from using those rights or enforce least privilege. Without time-bound elevation or approval workflows, this fails to meet the requirement for temporary privileged access that reduces exposure.

• ✓

  Use privileged access management with separate admin accounts and time-bound elevation approvals.

  Why this is correct

  Privileged access management is designed for this situation. Separate admin accounts preserve accountability, while time-bound elevation reduces standing privilege and limits exposure when the elevated rights are not needed. Approval workflows also support operational control and can be tied to maintenance tickets for traceability.

• ✗

  Move the application behind a federation service so all users can sign in with a single password.

  Why it's wrong here

  Placing the application behind a federation service using SSO, such as SAML or OIDC, improves authentication convenience but does not address authorization granularity or privileged access lifecycle. It still relies on the user's existing account permissions, so there is no separate admin account, no time-limited elevation, and no approval step for sensitive actions. Moreover, a single shared password across federated identities introduces a broader password-related risk and completely bypasses the intended purpose of just-in-time administrative elevation.