SY0-701 Security Architecture 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.

• ✓

  Step 1: ClientHello (with key share), Step 2: ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished, Step 3: Client Finished

  Why this is correct

  This is the correct order because TLS 1.3 reduces round trips to one: the client sends its key share in ClientHello, the server responds with its key share, certificate, and finished in a single flight, and the client sends its finished to complete the handshake.

• ✗

  Step 1: ClientHello, Step 2: Client Finished, Step 3: ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished

  Why it's wrong here

  This ordering is invalid because the client cannot compute the handshake traffic keys or send its Finished until it has received the server's key share in the ServerHello and validated the server's Certificate and CertificateVerify. The Client Finished is an authenticated message encrypted under keys derived from the combined key shares, so it necessarily occurs after the server's single flight. Placing it second ignores that the client has no basis to derive any secret yet.

• ✗

  Step 1: ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished, Step 2: ClientHello, Step 3: Client Finished

  Why it's wrong here

  The server cannot open a TLS 1.3 handshake because it has no way to know which protocol version, cipher suite, or key share the client supports until it receives a ClientHello. The server's flight of ServerHello, EncryptedExtensions, Certificate, CertificateVerify, and Finished is explicitly a response to the client's initial message, so putting it first reverses the required request-response flow. The ClientHello must always be the first message in the handshake.

• ✗

  Step 1: ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished, Step 2: Client Finished, Step 3: ClientHello

  Why it's wrong here

  This sequence fails both the initiation rule and the dependency rule: the handshake must start with ClientHello to advertise the client's key share and supported parameters, and the client's Finished must arrive after it has processed the server's certificate and derived the handshake secrets from the exchanged key shares. Listing the ServerHello flight first and the ClientHello last also breaks the fundamental request-response ordering, since the server's flight is a logical consequence of the client's offers, not a preamble. The only valid order is ClientHello, server flight, then Client Finished.

Go deeper

Related to this question