6 Amazon Penetration Tester Interview Questions & Answers

The OSI model organizes network communication into seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application. During an authorized review, I use it to understand where traffic flows and to classify observations, misconfigurations, and possible weaknesses without treating the model itself as a security control.

The practical purpose of the OSI model in a security review is to give me a structured way to reason about network communication. It divides communication into seven conceptual layers, from the physical medium at Layer 1 to application-facing network services at Layer 7. I can use those layers to locate where an observed behavior occurs and choose appropriate evidence to examine. The model does not prove that a weakness is exploitable, and modern Internet protocols do not always map perfectly to one OSI layer. It is primarily an analysis and troubleshooting framework.

1. Do you want only the seven layers and their functions, or also how a penetration tester uses them during an authorized review?
2. Should I give a simple client-to-server example to show how data moves through the layers?

I would start from Layer 1 and move upward:

1. Physical — Layer 1: This layer carries raw bits over a physical or wireless medium. Examples include copper, fiber, and radio. During an authorized review, physical connectivity or transmission problems can be classified here.

2. Data Link — Layer 2: This layer handles local-link communication using frames and link-layer addressing, such as MAC addresses. Ethernet and IEEE 802.1Q VLAN tagging are common examples. This layer is useful when reasoning about local network behavior and segmentation at the link level.

3. Network — Layer 3: This layer handles logical addressing and routing between networks. IP is the main example shown in the diagram, and ICMP provides network-layer control and diagnostic messaging for IP. A tester can use this layer to reason about source and destination addresses, routes, and network boundaries.

4. Transport — Layer 4: This layer provides end-to-end transport functions. TCP provides reliable, connection-oriented delivery, while UDP provides connectionless datagram transport without TCP-style reliability. Ports help identify transport endpoints. I should not say that every Layer 4 protocol provides reliability because UDP does not.

5. Session — Layer 5: Conceptually, this layer establishes, manages, and terminates communication sessions or dialogs and can support synchronization or checkpoints. In modern Internet implementations, these functions are often combined with application libraries or other layers rather than appearing as a separate protocol layer.

6. Presentation — Layer 6: Conceptually, this layer deals with representation of data, including translation, encoding, compression, and encryption-related transformations. Formats such as ASCII or JPEG illustrate representation functions. TLS is often placed near this layer in teaching diagrams because it transforms and protects application data, but real Internet protocol mappings do not always align exactly with OSI boundaries.

7. Application — Layer 7: This is the layer closest to user applications and provides application-facing network services. Common examples include HTTP, DNS, and SMTP. During an authorized assessment, observations about an application protocol can be organized at this layer.

The diagram shows a client sending data toward a server through the seven conceptual layers. When sending, information is logically processed down the stack toward transmission; the receiving system processes it back up toward the application. This is a conceptual representation rather than a claim that every deployed protocol stack implements seven separate software modules.

For security work, the key decision is: At which layer is the observed behavior occurring, and what evidence supports that conclusion? For example, an IP routing problem belongs primarily at the Network layer, while an HTTP behavior belongs primarily at the Application layer. Some technologies span or do not cleanly align with a single OSI layer, so I use the model as a reasoning aid rather than forcing every protocol into an exact box.

The security-review boundary is also important. I analyze only systems and traffic covered by the authorization and rules of engagement. Identifying a protocol, reachable service, or unusual behavior at one layer does not by itself prove a vulnerability or impact. I would gather appropriate evidence and validate any security conclusion separately.

The main limitation is that the OSI model is a reference model, not an implementation specification for the modern Internet. Its value is simplicity: it gives testers and defenders a shared vocabulary for discussing where communication functions, failures, and security observations occur.

1. Start with the observed client-to-server communication and confirm that it is within the authorized scope.
2. Identify the relevant communication function rather than immediately calling it a vulnerability.
3. Map the observation to the most useful OSI layer: Physical, Data Link, Network, Transport, Session, Presentation, or Application.
4. Trace the relevant evidence, such as the medium, frame behavior, IP addresses and route, transport protocol and ports, session behavior, data representation or encryption, or application protocol.
5. Remember that some real protocols span conceptual OSI boundaries, so do not force an artificial one-to-one mapping.
6. Validate the observed behavior independently before making a security finding. A layer classification explains where something occurs; it does not prove exploitability or impact.

The OSI model itself has almost no operational or financial cost because it is a conceptual framework. Its main cost is the time needed to understand which layer is relevant and gather suitable evidence. The seven-layer structure makes communication easier to explain and troubleshoot, but real systems may combine several OSI functions, so forcing every protocol into exactly one layer can create confusion. For a security review, additional effort comes from safely validating an observation instead of assuming that a protocol, port, or unusual behavior represents a vulnerability.

A common mistake is memorizing the seven names without understanding what they represent. Another is saying every modern network literally implements seven separate OSI layers. It is also incorrect to say that all Transport-layer protocols provide reliable delivery; TCP does, while UDP does not provide TCP-style reliability. Another mistake is forcing technologies such as TLS into one exact layer without acknowledging that real protocol stacks do not always map cleanly to the OSI model. In a penetration test, the biggest security mistake is treating a layer, protocol, reachable port, or scanner observation as proof of a vulnerability without validating the actual weakness and impact.

Name the layers in order, give one simple function for each, and then explain why the model matters to a penetration tester: it helps classify where network behavior occurs. Mention that it is a conceptual reference model, so real Internet protocols may not map perfectly to one layer. That demonstrates understanding rather than simple memorization.

SSH normally starts with a TCP connection to port 22, negotiates algorithms, performs key exchange, verifies the server host key, and establishes encrypted, integrity-protected transport. The client then authenticates, commonly with a public key. After success, SSH multiplexes secure channels such as a shell or command session.

This question is asking me to trace what happens from an authorized SSH client to a remote SSH server and explain where trust and encryption begin. I would separate five stages: TCP connection, protocol and algorithm negotiation, key exchange plus server verification, user authentication, and the encrypted application session. The important distinction is that the initial TCP connection itself is not the security boundary. SSH establishes cryptographic keys and authenticates the server during the transport-layer exchange. User authentication then runs through that protected transport before remote commands or other SSH channels are allowed.

1. Should I explain SSH at the protocol level, or also describe what I would validate during the authorized review?
2. Should I assume normal direct SSH over TCP port 22, as shown in the diagram?
3. Should I focus on public-key authentication while also mentioning password authentication as an alternative?

I would start with the practical goal: SSH, or Secure Shell, gives the authorized client a confidential, integrity-protected, authenticated way to use a remote system across an untrusted network.

1. Connect over TCP. The SSH client opens a TCP connection to the remote SSH service. Port 22 is the standard SSH port and is the default shown in the diagram, although a server can be configured to listen elsewhere. At this point, TCP gives reliable byte transport but does not itself provide SSH encryption or authentication.

2. Exchange identification and negotiate algorithms. The SSH peers first exchange protocol identification strings. They then exchange key-exchange initialization messages and negotiate compatible algorithms. These include the key-exchange method, server host-key algorithm, encryption algorithms, integrity algorithms, and other supported transport parameters. The important point is that both sides select mutually supported cryptographic parameters rather than assuming them. rfc-editor.org

3. Perform key exchange and authenticate the server. The negotiated key-exchange mechanism lets both sides establish shared secret material without transmitting the resulting session keys directly across the network. SSH derives encryption and integrity keys from the key-exchange result. With an explicit server-authentication key exchange, the server proves control of its host private key by signing the exchange data. The client validates that proof and decides whether the corresponding host key represents the expected server. In a normal known-host workflow, the client compares the observed host key with a previously trusted host-key record or another approved host-key policy. An unexpected host-key change is security-significant because blindly accepting it can defeat server authentication. rfc-editor.org

The diagram labels the transport before completion of the initial key exchange as not encrypted and the traffic after key exchange as encrypted and integrity protected. More precisely, the negotiated protection begins when the peers exchange the protocol's new-keys messages and start using the newly derived keys. From that point, higher-level SSH traffic runs through the protected transport. rfc-editor.org

4. Authenticate the user inside the protected transport. SSH user authentication is a separate layer above the transport layer. With public-key authentication, the server determines whether the offered public key is acceptable for the requested account, and the client proves possession of the corresponding private key with a digital signature. The diagram simplifies this as signing a challenge. More precisely, the public-key authentication signature is bound to the SSH session and authentication request rather than being a generic reusable challenge response. Password authentication is also supported, but the password is sent only after the SSH transport has established confidentiality protection.

Authentication can fail safely. An invalid signature, unacceptable public key, incorrect password, or unsatisfied authentication policy should result in authentication failure rather than an authenticated session. Likewise, failure to negotiate acceptable transport algorithms or failure to validate the expected server identity should stop the trusted connection rather than silently lowering the security requirement.

5. Open SSH connection channels. After user authentication succeeds, the SSH connection protocol operates through the protected transport. It can multiplex multiple logical channels over one SSH connection. For example, an authorized user may receive an interactive shell or execute a command. The diagram correctly represents commands and their output as travelling inside the encrypted, integrity-protected connection.

For an authorized remote-access review, I would collect evidence for each important boundary instead of treating one observation as proof of everything. TCP reachability proves that a network path to the service exists; it does not prove that authentication succeeds or that a vulnerability exists. I would verify the expected destination, TCP port, SSH identification, negotiated algorithms, server host-key identity, permitted authentication method, successful or rejected authentication outcome, and resulting authorized session behavior. I would avoid credential guessing or disruptive testing unless the rules of engagement explicitly allowed it.

The main tradeoff is between usability and assurance. SSH can safely cross an untrusted network because encryption, integrity protection, server authentication, and user authentication address different problems. However, cryptography does not decide whether the authenticated account has appropriate operating-system permissions. SSH also cannot protect an endpoint whose private keys or host itself are already compromised. Key management, trusted host-key verification, account authorization, and endpoint security therefore remain important outside the encrypted tunnel.

1. Confirm that the remote host, network path, SSH service, identity, and authentication method are inside the written authorization scope.
2. Trace the expected client-to-server path and confirm the SSH TCP destination and configured port, using port 22 only when that is the expected configuration.
3. Establish one normal SSH connection and observe the protocol identification and algorithm negotiation without attempting disruptive scanning or credential guessing.
4. Verify that key exchange completes and record the negotiated transport properties needed for the review.
5. Validate the server host-key identity against the approved trust source; treat an unexplained mismatch as a failed trust decision rather than automatically accepting it.
6. Exercise only the approved user-authentication method. For public-key authentication, confirm that authentication succeeds only when the client can prove possession of an authorized private key.
7. After authentication, verify only the authorized remote-session behavior, such as opening a shell or permitted command channel.
8. Record evidence separately for TCP reachability, SSH service identification, server authentication, user authentication, and authorized session access so that none is incorrectly presented as proof of another.

SSH adds several small costs in exchange for secure remote access. The client and server spend CPU time on key exchange, signatures, encryption, and integrity checks, but this overhead is normally modest for administrative sessions. Administrators must protect client private keys and server host keys, maintain trusted host-key information, manage which user public keys are authorized, remove stale access, and investigate unexpected host-key changes. Operational complexity increases when many hosts or users are involved because key rotation and trust distribution must be controlled. Stronger cryptographic policy can also reduce compatibility with old clients or servers, so organizations must balance interoperability against accepting outdated or disallowed algorithms.

A common mistake is saying that SSH becomes secure merely because TCP port 22 is reachable. TCP connectivity only establishes the transport path. Another mistake is mixing server authentication with user authentication: the server host key lets the client verify the remote server, while user authentication proves an identity to the server. It is also wrong to say the client's private key is sent to the server; public-key authentication uses a signature to prove possession of that private key. Another mistake is treating the public-key signature as an arbitrary reusable challenge response instead of a signature bound to the SSH session and authentication request. Finally, automatically accepting an unexpected host key removes an important server-authentication protection.

Explain SSH as a five-stage flow and name the trust decision at each stage. Emphasize that key exchange plus host-key verification establishes the protected transport, then user authentication happens inside it. Finish by separating network reachability, server identity, user identity, and post-authentication authorization.

I would confirm authorization first, then restrict network exposure, apply least-privilege IAM, require IMDSv2, encrypt EBS, harden and patch the OS, and enable useful logging and monitoring. I would validate each control with safe, reversible checks, document evidence, and retest after remediation.

Securing an EC2 instance means protecting both how people reach it and what the workload can do after access is obtained. In an authorized assessment, I would first confirm the exact AWS account, Region, instance, approved tester identity, trusted source addresses, and rules of engagement. I would then review network exposure, workload identity, metadata protection, storage encryption, operating-system hardening, and visibility. I would keep the work inside the customer-controlled environment, use non-destructive validation first, record evidence, and retest confirmed fixes rather than assuming that a configuration is secure.

1. Is the instance intended to be publicly reachable, or should access come only from trusted internal or administrative networks?
2. Which inbound services are actually required, such as SSH on port 22 or HTTPS on port 443?
3. Does the instance need an IAM role to call AWS services, and what exact permissions does the workload require?
4. Are CloudTrail and instance or security logs already collected, and where should assessment evidence be recorded?
5. Are there any provider-policy, availability, or change-control restrictions beyond the normal rules of engagement?

I would organize the assessment in four connected parts.

First, I establish authorization and scope. I confirm the written rules of engagement, the approved AWS account and Region, the exact EC2 instance, the tester identity, and the trusted IP addresses from which testing may originate. AWS secures the underlying cloud infrastructure, while the customer is responsible for areas such as EC2 network configuration, guest operating-system security, credentials, applications, and data. I would test only customer-controlled resources covered by the authorization. AWS permits customers to assess supported services such as their own EC2 instances without prior approval when the activity follows its penetration-testing policy. Command and Control testing requires prior approval, and customers must not test AWS infrastructure or AWS services themselves.

Second, I reduce network exposure with the instance's security group. I allow only the inbound services the workload truly needs and restrict administrative access to trusted source IP ranges where possible. For example, port 22 should not be broadly open simply because SSH exists, and port 443 should be exposed only when the workload actually needs HTTPS. Security groups control network reachability, but network reachability is separate from IAM authorization. Reaching a TCP port does not mean an identity has permission to perform AWS API actions.

Third, I harden the EC2 workload itself. If the instance needs AWS permissions, I use an IAM role through an instance profile with only the actions and resources the workload requires instead of storing long-lived access keys on disk. I require Instance Metadata Service Version 2, or IMDSv2, so metadata requests require session tokens and IMDSv1 is disabled for that instance. I encrypt attached EBS volumes so data at rest is protected. I also keep the guest operating system patched, remove unnecessary services and packages, and avoid placing reusable secrets in user data or ordinary files.

Fourth, I verify visibility and the deployed state. I review CloudTrail for relevant EC2 and IAM control-plane activity and use suitable monitoring, such as CloudWatch-supported metrics and logs, for the instance and its security signals where configured. Logging is a detection control; it does not replace prevention through IAM, network restrictions, metadata settings, encryption, or host hardening.

For validation, I start with read-only discovery and reversible tests. I verify the effective security-group path from the authorized source, inspect the actual instance role and permissions, confirm that IMDSv2 is required, verify EBS encryption, review patch and service state, and confirm that expected control-plane activity is recorded. I record the principal, resource, action, condition, network path, observed evidence, remediation owner, and retest result where applicable.

Safe failure matters. If a check would require destructive modification, expose a reusable credential, affect another tenant, create uncontrolled traffic, or risk availability, I stop and use a safer proof or obtain explicit approval. I do not treat a potentially weak setting as proof of exploitation.

The main limitation is that no single control proves the instance is secure. A narrow security group does not prove IAM is least privileged, IMDSv2 does not remove every application-level risk, encryption does not prevent an authorized process from reading decrypted data, and CloudTrail or monitoring does not prevent compromise. The tradeoff is between strong restriction and operational need: every open port, IAM permission, installed service, and monitoring component should have a justified purpose. After remediation, I repeat the same safe checks against the deployed configuration to confirm that the original path is actually closed.

1. Confirm written authorization, AWS account, Region, EC2 instance, tester identity, trusted source IPs, and stop conditions.
2. Review security-group reachability and allow only required inbound services from appropriate sources.
3. Review the EC2 instance profile and verify that the workload uses a least-privilege IAM role rather than long-lived static credentials.
4. Confirm that IMDSv2 is required and IMDSv1 access is disabled for the instance.
5. Verify that attached EBS volumes are encrypted without exposing key material.
6. Review the guest operating system for patch state, unnecessary services, and unsafe secret storage.
7. Confirm relevant CloudTrail coverage and appropriate instance or security monitoring.
8. Use read-only or reversible evidence to validate each finding, avoid destructive actions, document the exact observed path, assign remediation ownership, and safely retest.

The technical cost is mostly configuration review, patching, IAM design, encryption, and monitoring rather than a complex algorithm. Operational cost can increase when teams restrict ports, remove services, rotate access methods, or tighten IAM because applications may depend on existing access. Logging and monitoring also create storage, analysis, and alert-maintenance work. Encryption and key-management choices can add policy and lifecycle responsibility. Human effort is required to maintain patching, review permissions, respond to alerts, and retest changes. Stronger controls should therefore be applied according to the instance's real access and workload needs.

Common mistakes include opening SSH or application ports to far more source addresses than necessary; assuming a security group also controls IAM permissions; attaching an overly broad instance role; storing long-lived AWS keys or other reusable secrets on the host; leaving IMDSv1 available when IMDSv2 can be required; overlooking unencrypted EBS volumes; neglecting operating-system patching and unnecessary services; assuming CloudTrail records every host-level event; treating logging as a preventive control; testing outside the approved account, Region, resource, or provider policy; and making destructive changes when read-only or reversible evidence would be sufficient.

Present the answer as a layered flow: authorization and scope, network exposure, instance identity and hardening, then visibility and validation. Explicitly separate network reachability from IAM permission and AWS responsibility from customer responsibility. Finish by explaining how you would prove the controls safely and retest them instead of simply listing security settings.