Which type of monitor can the administrator create to look for a specific keyword response from the website and will be used to keep the services UP?

• A. UDP-ECV monitor with the keyword in the Special Parameters 'Receive String' field
• B. HTTP-ECV monitor with the keyword in the Special Parameters 'Receive String' field
• C. TCP monitor with the keyword in the Special Parameters 'Response Codes' field
• D. HTTP monitor with the keyword in the Special Parameters 'Response Codes' field

Answer: (B)

Verifying actual HTTP content is the key idea here. To ensure a website is truly up, you want a health check that fetches a page and confirms a specific piece of content appears in the response body. An HTTP-ECV (Extended Content Verification) monitor does exactly that: it requests the page and looks for a keyword you specify in the Special Parameters field called Receive String. If the keyword isn’t found, the monitor fails, signaling the service isn’t delivering the expected content and prompting failover or rerouting to keep users away from a bad node.

Other options don’t fit as well. A UDP-ECV monitor isn’t suitable for HTTP content checks because UDP isn’t reliable for validating a web page’s content. A TCP monitor focuses on connectivity and response codes related to the handshake, not the actual page content. An HTTP monitor that uses Response Codes checks which HTTP status codes are returned, but not whether the body contains the required keyword. The keyword in Receive String is the mechanism that confirms the presence of the expected content, which is why the HTTP-ECV option is the correct choice.