While preparing for the AWS SAA-C03, many candidates get tripped up by least privilege access patterns. In the real world, this boils down to balancing secure, minimal-permission access versus operational simplicity and cost. Let’s drill into a simulated scenario.
The Scenario #
NimbusSoft is developing a SaaS application hosted on AWS. The engineering team uses Amazon CloudWatch dashboards to monitor key application metrics.
The Product Owner, who frequently needs to review these metrics, does not have an AWS account. The NimbusSoft cloud architect must enable the Product Owner to access the dashboard securely, following the principle of least privilege.
Key Requirements #
Provide the Product Owner with a way to view the CloudWatch dashboard regularly without granting full AWS console access or creating excessive operational overhead.
The Options #
- A) Create a general IAM user with ViewOnlyAccess, share login credentials with the Product Owner, and have them manually navigate or search the CloudWatch console for the dashboard.
- B) Create a dedicated IAM user for the Product Owner, attach the AWS-managed CloudWatchReadOnlyAccess policy to this user, share the new login credentials, and provide the dashboard URL.
- C) Share the CloudWatch dashboard directly from the CloudWatch console by entering the Product Owner’s email address and providing a shared link to the dashboard.
- D) Deploy a bastion host in a public subnet; when dashboard access is needed, start the server, share RDP credentials with the Product Owner, and open the dashboard URL inside the bastion host’s browser configured with cached AWS credentials.
Correct Answer #
Option C.
The Architect’s Analysis #
Correct Answer #
Option C
Step-by-Step Winning Logic #
Option C provides a direct sharing feature inside CloudWatch dashboards designed for this exact use case: sharing dashboard views with non-AWS users securely. By generating a sharing link tied to the dashboard, it enforces minimal permissions — the Product Owner can only view the dashboard, not modify or access other AWS resources.
This approach avoids proliferating IAM users, which can increase operational overhead and security risk, and removes the need for credential sharing or extra infrastructure like bastion hosts, which adds cost and complexity. It is also fully supported by AWS without additional ongoing management expense.
The Traps (Distractor Analysis) #
- Why not A? Giving ViewOnly console access allows navigational freedom and potential to view other sensitive data beyond the dashboard, breaking the principle of least privilege and increasing attack surface.
- Why not B? Creating an IAM user for the Product Owner violates least privilege principles by granting console access beyond just dashboard viewing, risking over-permission and credential management overhead.
- Why not D? The bastion host solution is operationally expensive, complex to maintain, and burdensome to start servers and share RDP credentials each time. It also increases costs without added security benefits.
The Architect Blueprint #
Mermaid Diagram illustrating Option A architecture flow.
Diagram Note: The Product Owner accesses the CloudWatch dashboard through a secure, shareable URL granting read-only view on application metrics without AWS account credentials.
Real-World Practitioner Insight #
Exam Rule #
For the exam, always choose CloudWatch dashboard sharing links when you need to provide dashboard access to non-AWS users with least privilege.
Real World #
In production, we often pair this with internal dashboard tools or embed graphs externally via authorized API calls for better user experience. If full AWS account access is ever required, federation or SSO with restrictive permissions can be considered but increases complexity and cost.