Which of the following best explains why interacting with running containers is important in DevOps?
Think about what you might do if an app inside a container is not working as expected.
Interacting with running containers allows you to check logs, run commands, and fix issues without rebuilding images. This helps in quick debugging and monitoring.
What will be the output of the following command if the container named webapp is running and has a file /app/version.txt containing 'v1.2.3'?
docker exec webapp cat /app/version.txt
Consider what docker exec does when running a command inside a container.
The docker exec command runs the given command inside the specified running container. If the file exists, it outputs its content.
What is the correct order of commands to start a container named db if stopped, then open an interactive shell inside it?
Think about checking container status before starting and interacting.
First, check running containers with docker ps. Then start the container if stopped. Next, open an interactive shell. Stopping is optional and last.
You run docker exec myapp ls but get the error 'Error: No such container: myapp'. What is the most likely cause?
Consider what the error message says about the container name.
The error means Docker cannot find a running container with the name 'myapp'. The container might be stopped or never created.
Which option describes the best practice to keep data safe and persistent when interacting with containers that may be stopped or removed?
Think about how container filesystems behave when containers are deleted.
Container filesystems are ephemeral. Using volumes or bind mounts stores data outside containers, ensuring persistence even if containers are removed.