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.

• ✗

  Disable CloudTrail during troubleshooting

  Why it's wrong here

  Disabling CloudTrail during troubleshooting removes the audit trail that records API calls, user identities, and resource changes, making root-cause analysis and security investigations impossible. CloudTrail is a detective control that should remain enabled precisely when issues arise, since its logs provide the timeline needed to correlate events and identify misconfigurations or unauthorized actions. Temporarily disabling it also leaves a gap in compliance evidence, undermining any later attempt to prove what occurred.

• ✗

  Attach AdministratorAccess permanently to every developer role

  Why it's wrong here

  Permanently attaching AdministratorAccess to every developer role grants full, standing administrative privileges, which violates least privilege and drastically increases blast radius if a developer's credentials are compromised. Developers typically need only scoped permissions to specific services or resource tags, so broad access also masks misconfigurations and makes it harder to enforce separation of duties. This approach eliminates the need for temporary elevation but at the cost of persistent, unmonitored high-risk permissions across the entire team.

• ✓

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

  Why this is correct

  IAM Identity Center permission sets allow you to assign role-based permissions (e.g., AdministratorAccess) to users or groups for a defined session duration, often combined with temporary elevation workflows that require approval and expire automatically. By coupling these time-bound assignments with CloudTrail auditing, every privileged action is attributable to a specific federated user and can be reviewed for anomalies. This reduces standing privilege, supports just-in-time access, and gives the team the temporary administrative power they need without permanently widening the security posture.

• ✗

  Create shared administrator access keys for the team

  Why it's wrong here

  Creating shared administrator access keys for the team removes individual accountability because multiple developers can silently use the same credentials, making it impossible to determine who performed a destructive action. Long-term access keys are a primary target for exfiltration; if one is exposed, an attacker gains persistent administrative access, and rotating the key would disrupt every developer relying on it. This directly contradicts temporary access needs and auditing requirements, so it is both a security and an operational anti-pattern.

Go deeper

Related to this question