[DOCS-5624] inclusive naming screenshot update inbound agent

content/doc/book/scaling/architecting-for-scale.adoc

@@ -169,14 +169,14 @@ http://<your-jenkins-host>/jnlpJars/agent.jar
 If running a version of Jenkins newer than 1.559, the _.jar_ will be kept
 up to date each time it connects to the controller.
 
- * *The JNLP-HTTP connector*: This approach is quite similar to the JNLP-TCP
+ * *The Inbound-HTTP connector*: This approach is quite similar to the Inbound-TCP
    Java Web Start approach, with the difference in this case being that the
    agent is executed as headless and the connection can be tunneled via HTTP(s).
-   The exact command can be found on your JNLP agent's configuration page:
+   The exact command can be found on your Inbound agent's configuration page:
 
-[[jnlp_agent]]
-.JNLP agent launch command
-image::hardware-recommendations/jnlp-slave.png[scaledwidth=90%]
+[[inbound_agent]]
+.Inbound agent launch command
+image::hardware-recommendations/inbound-agent.png[Inbound agent node screen, scaledwidth=90%]
 
 This approach is convenient for an execution as a daemon on Unix.
 
@@ -270,9 +270,9 @@ resources together with their destruction when they are not needed anymore:
   of on-premises agents. The EC2 agents will be dynamically created inside an
   AWS network and de-provisioned when they are not needed.
 * The plugin:azure-vm-agents[Azure VM Agents Plugin]
-  dynamically spins up Jenkins agents as Azure VMs per user provided 
-  configuration via templates, including support for virtual network integration 
-  and subnet placement. Idle agents can be configured for automatic shutdown 
+  dynamically spins up Jenkins agents as Azure VMs per user provided
+  configuration via templates, including support for virtual network integration
+  and subnet placement. Idle agents can be configured for automatic shutdown
   to reduce costs.
 * The plugin:jclouds-jenkins[JCloud plugin]
   creates the possibility of executing the jobs on any cloud provider supported