SAA-C03 Design Secure Architectures 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.

• ✓

  Use IAM Identity Center permission sets with time-bound access processes and CloudTrail auditing

  Why this is correct

  IAM Identity Center permission sets let you define job-function-based roles (e.g., AdministratorAccess) and assign them to users or groups for a specific session duration or via time-bound assignment processes, such as requesting access for a ticket window. This approach keeps temporary credentials short-lived, limits standing privilege, and integrates with CloudTrail so every federated console or API call is attributed to a specific identity for audited troubleshooting sessions.

• ✗

  Disable CloudTrail during troubleshooting

  Why it's wrong here

  Disabling CloudTrail during troubleshooting removes the audit log that records who made what API call and when, which cripples post-incident analysis and makes it impossible to prove a clean root cause. It also violates security best practices and many compliance frameworks (e.g., PCI-DSS, SOX) that mandate continuous logging, so even though it shortens noisy logs, it unacceptably degrades accountability and investigation capability.

• ✗

  Create shared administrator access keys for the team

  Why it's wrong here

  Shared administrator access keys are long-term, static credentials that lack any identity attribution—everyone using them appears as the same principal, so you cannot determine which developer performed a destructive action or when a key leaked. Because the keys are never rotated and are shared, the blast radius is catastrophic if they are compromised, and there is no mechanism to enforce individual fine-grained permissions or revoke a single person's access, making this an unacceptable security practice.

• ✗

  Attach AdministratorAccess permanently to every developer role

  Why it's wrong here

  Permanently attaching AdministratorAccess to every developer role grants complete, unchanging privileges regardless of task, which directly violates least privilege and creates standing high-risk permissions that expand the attack surface. Any developer or compromised session can immediately perform irreversible actions (e.g., deleting S3 buckets, modifying IAM policies) without additional controls, and because the access is permanent, there is no time bound or need-to-know check.

Go deeper

Related to this question