Select Two (Multi-Select) Questions

libnetwork

Why it fails: libnetwork is Docker's networking library, tied to the Docker daemon; Podman's daemonless architecture uses netavark for network setup and aardvark-dns for name resolution. It tempts because both manage container networks, but libnetwork cannot function without dockerd.

docker-proxy

Why it fails: docker-proxy is a Docker daemon component for publishing container ports; Podman does not run a daemon and uses netavark plus aardvark-dns instead. It tempts because both tools publish ports similarly, yet docker-proxy depends on dockerd, which Podman deliberately omits.

iptables-nft

Why it fails: Podman configures container networking through netavark and aardvark-dns, with nftables rules managed directly; iptables-nft is a compatibility shim, not the primary backend. It tempts because Docker historically relied on iptables, but Podman's modern stack bypasses that legacy path.

Shared memory block devices via NFS exports

Why it fails: Podman persists container data through volumes and bind mounts; NFS-exported shared memory block devices are not a native storage mechanism. It is tempting because NFS is a legitimate network filesystem, and would be correct when containers must share remote file storage across hosts rather than use Podman's built-in volume drivers.

Direct Fibre Channel LUN mapping inside containers

Why it fails: Fibre Channel LUN mapping happens at the host storage layer, not inside containers, and Podman exposes no native mechanism for it. It is tempting because raw block devices suit databases needing direct disk control, and would be correct when a host presents a LUN that is then bind-mounted or passed through to a container.

Distributed HDFS cluster mounts

Why it fails: HDFS is a distributed filesystem accessed through Hadoop clients, not a storage mechanism Podman natively supports for container persistence. It is tempting because HDFS handles large distributed datasets, and would be correct when analytics workloads must read and write data across a Hadoop cluster rather than mount local container volumes.

Directly edit a running container's image tag using 'podman edit --tag'.

Why it fails: No such command exists; Podman has no 'podman edit --tag' subcommand, and image tags are immutable references set at build, tag, or commit time, not editable on a running container. It is tempting because 'podman tag' and 'podman commit' do manipulate tags, but only when creating new image references.

Instantly migrate a running container to a remote physical server using 'podman migrate'.

Why it fails: Podman offers no 'podman migrate' command; live container migration across hosts is not a Podman capability, since containers are tied to local storage and namespaces. It is tempting because 'podman generate kube' and 'podman play kube' recreate workloads elsewhere, but that redeploys from a manifest rather than migrating a running container.

start

Why it fails: The 'start' action is not part of 'podman network', which uses create, ls, inspect, connect, disconnect and rm for CNI network management. It is tempting because 'podman start' launches containers, so the verb feels applicable, but networks are created rather than started.

build

Why it fails: The 'build' action belongs to 'podman build' for constructing images from a Containerfile; 'podman network' manages CNI networks with create, ls, inspect, connect and rm. It is tempting because build is a common podman subcommand, but it operates on images, not networks.

commit

Why it fails: Committing a container writes its current state to a new image, which is the job of 'podman commit', not the network subcommand. It is tempting because podman's command groups look alike, but network management covers creating, inspecting, connecting and removing container networks.

podman cp --target=container_name host_file.txt /app/file.txt

Why it fails: The `--target` flag does not exist for `podman cp`; the container must be named as a positional argument, either `podman cp host_file.txt container_name:/app/file.txt` or `podman cp container_name:/app/file.txt host_file.txt`. The flag is tempting because `--target` appears in other Podman commands, such as `podman build`, where it specifies a build stage.

podman cp --direction=to-container host_file.txt container_name:/app/

Why it fails: podman cp has no --direction flag; direction is inferred from whether the source or destination is a container path. The syntax is tempting because explicit direction flags exist in other tooling, but podman relies on argument position, so this command errors as an unknown option.

podman cp --from=container_name /app/file.txt host_file.txt

Why it fails: `--from` is not a valid `podman cp` flag; the command rejects it outright, so no copy occurs. It is tempting because `--from` genuinely belongs to `podman build` and `podman create --mount`, where it selects a build stage or mount source. For host-to-container or container-to-host file transfer, the container reference is simply prefixed with its ID or name.

ENTRYPOINT instructions cannot be overridden at runtime under any circumstances.

Why it fails: ENTRYPOINT can be overridden at runtime using docker run --entrypoint, so the claim of impossibility is false. It is tempting because ENTRYPOINT does define the fixed executable that CMD arguments append to, making it feel immutable. The actual axis is that CMD supplies default arguments, while ENTRYPOINT sets the command.

CMD and ENTRYPOINT perform identical functions with no syntactical differences.

Why it fails: CMD supplies default arguments that ENTRYPOINT can consume, while ENTRYPOINT defines the executable; their syntax and override behaviour differ. The claim of identical function is tempting because both appear as trailing instructions in a Containerfile and both influence the container's startup command. Only one CMD takes effect.

Disable SELinux enforcement globally on the container host before generating signatures.

Why it fails: Disabling SELinux globally weakens host security and is not required to sign or push images; generating a GPG key pair and configuring the registry's signature policy are. It is tempting because SELinux denials can block container operations, but targeted policy adjustments, not global disablement, resolve those.

Store the private signing key inside the container image payload.

Why it fails: Embedding the private key in the image exposes it to anyone who pulls the image, defeating the signature's purpose; the private key stays on the signing host and only the public key is distributed. It is tempting as a way to make signing self-contained, but it destroys the trust model.

Set the container storage driver to vfs in storage.conf.

Why it fails: The vfs driver only changes how layers are stored on disk and has no bearing on image signing or pushing; configuring a signing key and enabling signature verification are the required actions. It is tempting because vfs is used for troubleshooting storage issues, but it is unrelated to signature workflows.

-p container=80,host=8080

Why it fails: Podman's --publish flag takes positional colon-separated values, not key=value pairs; container=80,host=8080 is parsed as an invalid port specification. It tempts because key=value syntax appears elsewhere in Podman, such as --env or --label, but not for port publishing.

-p 80:8080:tcp:bind

Why it fails: Podman's --publish syntax accepts protocol and IP bindings, but not a fourth 'bind' field; the valid forms are hostPort:containerPort, optional IP, and optional /tcp or /udp. It tempts because Docker-style flags sometimes include extra qualifiers, yet Podman rejects this token.

Running 'podman network ls' to verify image network attachment.

Why it fails: podman network ls lists configured networks, not local images, so it cannot confirm a download succeeded. It is tempting because images attach to networks at run time, making this command correct when checking which networks exist before starting a container.

Running 'podman ps -a' to see the downloaded image layers.

Why it fails: 'podman ps -a' lists containers, not images, so it cannot confirm a downloaded image; downloaded images are verified with 'podman images'. It is tempting because 'podman ps' does report on local container state, and would be the right tool had the question asked about running or stopped containers rather than image layers.

Running 'podman volume inspect' to check image storage paths.

Why it fails: podman volume inspect reports storage volumes, not downloaded images, so it cannot confirm an image exists locally. It is tempting because volumes and images both reside in local storage, making this command correct when verifying a container's persistent volume mounts instead.

GET

Why it fails: GET is not a valid Containerfile instruction; the builder cannot parse it. It is tempting because HTTP GET describes fetching remote data, and tools like curl or wget retrieve files, but Containerfile has no GET directive — ADD and COPY handle external content instead.

FETCH

Why it fails: FETCH is not a Containerfile instruction; COPY and ADD bring files from the build context or remote URLs into the image. It is tempting because FETCH resembles a retrieval verb, and ADD already handles remote URL retrieval, so the name feels plausible.

IMPORT

Why it fails: IMPORT is not a Containerfile instruction at all, so the builder rejects it. It is tempting because other tooling uses import-style directives to pull external content, and Docker's legacy builder had an import command for creating images from tarballs, but neither brings files into a build context.

podman volume modify

Why it fails: Podman has no volume modify subcommand; volumes are altered only via create, rm, prune or inspect flags. It is tempting because Docker-style tooling suggests mutable volume attributes, and such a command would be the right choice if you needed to relabel or resize an existing volume in place.

podman volume edit

Why it fails: Podman exposes volume creation, inspection, listing, removal and pruning; there is no edit subcommand, so this fails. It is tempting because editing configuration feels analogous to modifying other resources, yet volumes are managed by recreating or relabelling them instead.

Modify the size limit of an existing volume using podman volume resize

Why it fails: Podman volumes are not size-limited objects, so no resize subcommand exists; the suite covers create, inspect, ls, rm and prune. It is tempting because block storage tools offer resize, but podman volumes inherit host filesystem capacity and cannot be resized through the volume command suite.

Encrypt a managed volume at rest using podman volume encrypt

Why it fails: Podman has no volume encryption subcommand; encryption at rest is handled by underlying storage or filesystem layers, not the podman volume suite. It is tempting because container security often involves encrypted volumes, but podman volume supports create, inspect, ls, rm and prune, not encrypt.

Convert a bind mount to a named volume using podman volume convert

Why it fails: No convert subcommand exists in the podman volume suite; bind mounts and named volumes are distinct mount types chosen at container run time. It is tempting because migrating between storage types is a common operational task, but podman volume only offers create, inspect, ls, rm and prune.

podman freeze

Why it fails: Freeze is a cgroup operation that throttles a container via the freezer controller but is not the documented Podman pause pairing. It is tempting because freezing genuinely halts processes, yet the exam expects pause and unpause, which use SIGSTOP and SIGCONT semantics on the container's init process.

podman resume

Why it fails: Podman has no resume subcommand; the pair is pause and unpause, so this verb does not exist in the CLI. It is tempting because resume describes the intended outcome, and similar verbs appear in other container tooling, but the actual command that restarts a paused container's processes is unpause.

podman stop

Why it fails: Stop terminates the container's processes and tears down its namespaces, so state is lost and no resume is possible. It is tempting as a way to halt activity, but pause suspends processes in place with SIGSTOP while retaining memory and filesystem state, allowing unpause to continue exactly where execution left off.

podman secret compile

Why it fails: Podman has no secret compile subcommand; secrets are created with podman secret create and read with inspect or ls. Compilation suggests building a secret from a source file, but create already ingests files directly, so the verb does not exist in the CLI.

podman secret update

Why it fails: Podman secrets are immutable once created; changing a value requires removing and recreating the secret, so no update subcommand exists. Update would be the right verb for mutable configuration stores such as Kubernetes ConfigMaps, not Podman's secret store.

podman secret modify

Why it fails: Podman exposes create, inspect, ls and rm for secrets; there is no modify subcommand, so this fails. It tempts because editing an existing secret's value seems a natural operation, but Podman requires removing and recreating the secret instead of modifying it in place.

podman inspect --format='{{.Metadata.ExitCode}}' container_name

Why it fails: ExitCode sits under the top-level State object, not Metadata, so this path resolves to nothing and prints blank output. It is tempting because Metadata does exist in the inspect output and holds container creation details, but the exit code is a runtime state attribute reached via {{.State.ExitCode}}.

podman inspect --format='{{.Status.Running}}' container_name

Why it fails: Running is a boolean under State, not Status, so this expression yields no value and cannot report whether the container is active. It is tempting because Status appears in inspect output for other container runtimes, but Podman nests runtime state under State; the working form is {{.State.Running}}.

podman inspect --format='{{.Exit}}' container_name

Why it fails: The inspect JSON exposes the exit code under State.ExitCode, so .Exit matches no field and returns an empty result. It is tempting because the name reads naturally and the surrounding syntax is valid Go templating, but the correct expression for this attribute is {{.State.ExitCode}}.

podman secret extract

Why it fails: Podman exposes no extract subcommand for secrets; retrieval is done with podman secret inspect, which reveals metadata rather than the secret value. It is tempting because extracting a stored credential sounds useful, but the actual subcommands are create, ls, inspect and rm.

podman secret compile

Why it fails: Podman secrets are created, listed, inspected and removed; there is no compile subcommand, so this fails. It is tempting because compile-like verbs appear in build tooling, but secret handling never compiles anything. The valid operations are podman secret create, ls, inspect and rm.

Networks

Why it fails: podman system df reports disk usage for images, containers and volumes only; networks are inspected with podman network ls or inspect. It is tempting because networks are a Podman resource, but they consume no local storage, so they fall outside the command's scope.

Secrets

Why it fails: podman system df covers images, containers and volumes; secrets are managed with podman secret ls and consume no tracked local storage. It is tempting because secrets are a Podman object type, but the command reports storage consumption, which secrets do not contribute to.

Direct modification of the host kernel mount tables

Why it fails: A rootless user cannot write host kernel mount tables directly; the bind mount is performed inside the user namespace and propagated through the container runtime. Direct kernel mount-table editing is the correct approach for privileged administrative tooling running as real root on the host.

Disabling user namespaces across the system

Why it fails: Rootless containers depend on user namespaces to map the unprivileged host user to root inside the namespace; disabling them removes that mapping and breaks the mount entirely. Disabling user namespaces is the correct hardening step when containers must never gain namespace-based privilege separation.

Root privileges on the host operating system

Why it fails: Rootless mode exists precisely so the user lacks root on the host; requiring root privileges contradicts the scenario. Host root is the correct requirement when the container must mount arbitrary block devices or modify shared kernel subsystems that unprivileged namespaces cannot reach.

Using the --environment-map flag

Why it fails: Podman has no --environment-map flag; variables are passed with --env or --env-file. The name suggests mapping key-value pairs, which --env already does, so it tempts anyone assuming a dedicated mapping syntax exists. In practice --env-file supplies many variables from a file.

Using the --var-file flag

Why it fails: Podman has no --var-file flag; environment variables are supplied with --env or --env-file at run time. It tempts because file-based variable injection resembles Docker Compose's env_file or Kubernetes ConfigMap patterns, which would be the right approach in those orchestrators rather than Podman's CLI.

Using the --inject-env flag

Why it fails: Podman provides no --inject-env flag; environment variables enter via --env or --env-file. The wording implies deliberate injection, which is exactly what --env performs, making the invented flag feel plausible. --env-file is the real choice when loading variables from a file.

type=volume

Why it fails: Podman secrets mount as files inside the container, so the only valid type is a bind-style file mount; type=volume is not accepted for secrets. It tempts because volumes are the standard mechanism for persistent container storage, and would be correct when mounting ordinary named volumes rather than secrets.

type=tmpfs

Why it fails: Secrets are delivered as files on a bind mount, not as memory-backed filesystems; type=tmpfs is rejected for secret mounts. It tempts because tmpfs is a real Podman mount type used for emptyDir-style scratch space, and would be correct when a container needs non-persistent in-memory storage.

type=bind

Why it fails: Podman secret mounts accept options such as type=mount, target, uid, gid and mode; type=bind is not a valid secret mount type. Bind mounts apply to volumes, which is why it appears plausible. Secrets are mounted as tmpfs files inside the container, so specifying bind contradicts the supported mount semantics.