Which command creates a readiness probe for a deployment config "myapp" that GETs /healthz on port 8080 with a 20-second period?

Which command creates a readiness probe for a deployment config "myapp" that GETs /healthz on port 8080 with a 20-second period?

• A. oc set probe dc/myapp --readiness --get-url=http://:8080/healthz --period=20
• B. oc set probe dc/myapp --readiness --open-tcp=3306 --period=20
• C. oc set probe dc/myapp --liveness --get-url=http://:8080/healthz --period=30
• D. oc set probe dc/myapp --readiness --tcp-get-url=http://:8080/healthz --period=20

Answer: (A)

When you want a pod to be considered ready only after it can respond to a specific HTTP request, you configure a readiness probe that uses an HTTP GET. The correct command sets a readiness probe for the deployment config, uses a URL with an HTTP GET to the health endpoint, and specifies the cadence. The best choice uses the readiness flag to indicate a readiness probe for the deployment config myapp, with an HTTP GET to http://:8080/healthz and a period of 20 seconds. The empty host in the URL means the probe targets the pod itself on port 8080, hitting the /healthz path as a simple health check. The 20-second period establishes how often the probe runs, aligning with the requirement. The other options either switch to a liveness probe instead of readiness, use a TCP-only check (not an HTTP GET to a path), or use an invalid flag for the probe type. For example, a TCP probe on a different port doesn’t verify the HTTP health endpoint, and a liveness probe answers a different operational question. Using a nonstandard flag like --tcp-get-url wouldn’t be recognized.

When you want a pod to be considered ready only after it can respond to a specific HTTP request, you configure a readiness probe that uses an HTTP GET. The correct command sets a readiness probe for the deployment config, uses a URL with an HTTP GET to the health endpoint, and specifies the cadence.

The best choice uses the readiness flag to indicate a readiness probe for the deployment config myapp, with an HTTP GET to http://:8080/healthz and a period of 20 seconds. The empty host in the URL means the probe targets the pod itself on port 8080, hitting the /healthz path as a simple health check. The 20-second period establishes how often the probe runs, aligning with the requirement.

The other options either switch to a liveness probe instead of readiness, use a TCP-only check (not an HTTP GET to a path), or use an invalid flag for the probe type. For example, a TCP probe on a different port doesn’t verify the HTTP health endpoint, and a liveness probe answers a different operational question. Using a nonstandard flag like --tcp-get-url wouldn’t be recognized.