Open an admin session without a public doorway — Systems Manager and Session Manager

Your goal

Plan controlled access to a managed server without opening inbound SSH.

Why this matters

A teammate needs to inspect a server. You will prepare it for Session Manager, limit who may connect, and decide which session records the team needs to keep.

Words you will use

A managed node is a machine configured for Systems Manager. An agent runs on it. IAM permissions decide who may start a session. Session records help review access.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Prepare the managed node

A server sits in a private subnet. You want an administrative session without opening a public inbound SSH port. Choose the required preparation.

What must the server have?

A working SSM Agent, suitable IAM permissions, and service connectivity.

Session Manager needs the node to be properly managed and able to reach the required service endpoints. No inbound SSH opening is required for this connection, but agent, network, and permission setup still matter.

The node has the prerequisites for managed sessions.

Agent + node role + service access → managed node

2. Limit who can connect

An engineer needs access to a test server, but not every production server. The session entry point should respect that boundary.

What should control access?

Scoped IAM permissions for the intended nodes and session actions.

Authorize the people and resources that actually need sessions. Use appropriate IAM conditions and resource scope, then test allowed and denied cases. A private connection still requires careful human access control.

The engineer can reach the intended server only.

Authorized identity → allowed session action → intended node

3. Choose the right audit evidence

The team needs to review who opened a session and, for supported shell sessions, what occurred. Different session types have different logging capabilities.

What should be verified?

Session activity records and supported content logging are configured and tested.

Review API activity records and configure supported session logging where needed. Do not assume SSH or port-forwarding session contents are captured by Session Manager. Match the audit requirement to the session type.

The audit plan states what is recorded and what is not.

Session type → supported logging → protected audit records

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.