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 AWS Systems Manager Session Manager, enabling the required SSM permissions in the instance profile and restricting access to engineers via IAM.

  Why this is correct

  Session Manager avoids inbound SSH from the internet by initiating interactive sessions through Systems Manager. The instance profile must allow SSM actions like StartSession, and engineers’ IAM permissions restrict who can connect. This is a commonly recommended bastion-free alternative that improves security and reduces exposed network paths.

• ✗

  Keep the bastion host but move it into a private subnet; engineers can connect by using a corporate VPN into the VPC.

  Why it's wrong here

  A bastion host remains a high-value target and still requires controlled network access. Even if the bastion is private, inbound connectivity and SSH exposure remain. Session Manager provides a more direct elimination of the bastion as well as auditability.

• ✗

  Attach a public IP to each private instance so engineers can SSH directly and use security groups to restrict access.

  Why it's wrong here

  Attaching public IPs to instances in a private subnet defeats the isolation that the subnet was designed to provide, exposing every instance to direct SSH attempts from the internet. Security groups are useful for limiting access, but they are network-layer controls and do not substitute for identity-based authorization or session auditing; a single misconfigured rule or compromised instance broadens the attack surface. This approach still leaves management ports like 22 open to the network, whereas Session Manager brokers connections through the AWS control plane without any inbound port.

• ✗

  Create a security group rule that allows engineers’ source IP addresses to reach instances over RDP on port 3389.

  Why it's wrong here

  Opening port 3389 to engineer IPs assumes a Windows-focused administrative path and requires a direct network route to each instance, which keeps the management plane exposed to the internet and vulnerable to brute-force RDP attacks if the source IP is spoofed or a rule is too broad. IP-based allowlisting is also brittle because engineer addresses change and it cannot enforce per-user IAM permissions or produce an auditable record of who did what. This option neither removes a bastion nor addresses the core requirement; it merely shifts the exposure from a single jump host to the target instances themselves, and it is irrelevant for Linux workloads.

Go deeper

Related to this question