Hard Difficulty Questions

Into ~/.config/containers/policy.d/keys/

Why it fails: Podman reads signature verification keys from the GPG keyring configured in policy.json, not from a policy.d keys directory, which is not a recognised lookup path. A per-user policy.d location is tempting because policy.json itself lives under /etc/containers, suggesting sibling directories hold related configuration.

Into /etc/containers/certs.d/keys/

Why it fails: /etc/containers/certs.d/ holds registry TLS certificate authorities for transport trust, not GPG keys for image signature verification. It is tempting because both directories sit under /etc/containers and both concern trusting a registry, but certs.d governs TLS, not signedBy.

Into /var/lib/containers/sigstore/

Why it fails: /var/lib/containers/sigstore/ stores signature and identity data for sigstore-based verification, not the GPG public keys referenced by signedBy. It is tempting because sigstore is a genuine container-signing mechanism, and would be the correct location when policy.json uses sigstore rather than GPG signedBy.

podman push --sign-by <key_id> app:latest

Why it fails: Pushing and signing are separate operations, though some workflows combine them via configuration.

podman gpg --sign app:latest

Why it fails: podman gpg is not a valid subcommand.

podman sign --key <key_id> app:latest

Why it fails: The sign subcommand is nested under image (podman image sign), not directly under podman.

Use ENV for the binary and WORKDIR for the arguments.

Why it fails: ENV sets environment variables and WORKDIR sets the working directory; neither defines the container's executable or its arguments. It is tempting because both instructions configure runtime context, but launching a web server with overridable defaults requires ENTRYPOINT for the binary and CMD for arguments.

Use RUN for both the binary and the arguments.

Why it fails: RUN executes commands only during image build, so nothing persists as the container's runtime command or default arguments. It is tempting because RUN accepts shell syntax, but build-time layers cannot supply overridable runtime defaults; ENTRYPOINT and CMD are required for that.

Use CMD for the binary and ENTRYPOINT for the default arguments.

Why it fails: Reversing the instructions makes CMD the executable and ENTRYPOINT the arguments, so podman run arguments replace the binary rather than the defaults. It is tempting because both instructions accept exec form, but ENTRYPOINT must hold the binary for appended arguments to override CMD defaults.

podman run -v /host/path:/container/path:ns

Why it fails: 'ns' is not a volume mount flag.

podman run -v /host/path:/container/path:uid=root

Why it fails: uid=root is not a valid suffix option.

podman run -v /host/path:/container/path:map

Why it fails: 'map' is not a valid volume suffix flag.

podman secret cat my_secret

Why it fails: 'cat' is not a valid subcommand.

podman secret show my_secret

Why it fails: 'show' is invalid; use 'inspect'.

podman secret view my_secret

Why it fails: 'view' is not a valid subcommand.

podman kube create --compose

Why it fails: Incorrect. This command syntax does not exist.

podman-compose to-kube

Why it fails: Incorrect. 'to-kube' is not a valid subcommand.

podman-compose export --kubernetes

Why it fails: Incorrect. This is not a valid command.

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.

registry: name: registry.example.com mirror: internal-mirror.example.com

Why it fails: YAML syntax is not supported in registries.conf.

SERVER=registry.example.com MIRROR=internal-mirror.example.com

Why it fails: Shell environment format is not used for registries.conf.

[registry "registry.example.com"] mirror = "internal-mirror.example.com"

Why it fails: This INI-style syntax is incorrect; registries.conf uses TOML array of tables ([[registry]]).

format

Why it fails: 'format' is not a mount parameter.

The Containerfile lacks an explicit CACHE instruction at the top.

Why it fails: Containerfile has no CACHE instruction; layer caching is automatic and keyed on instruction text plus parent layer. An explicit cache directive is tempting because Dockerfiles do have cache-related flags, but the real cause is that the RUN precedes the COPY of requirements.txt, invalidating the layer whenever any earlier instruction changes.

Podman disables caching by default for all RUN instructions containing package managers.

Why it fails: Podman caches RUN layers by default exactly as Buildah and Docker do; no package-manager-specific cache suppression exists. The claim is tempting because package managers have their own download caches, but the observed rebuild stems from the RUN preceding the COPY of requirements.txt, so its parent layer changes each build.

The USER instruction was set to root, which disables layer caching.

Why it fails: USER root does not disable layer caching; cache keys derive from instruction content and parent layers, not the runtime user. It is tempting because root versus non-root affects permissions and reproducibility, but the actual cause is instruction ordering, where the dependency-fetching RUN sits before the COPY of requirements.txt.

podman run --share-namespace mypod -d myimage

Why it fails: --share-namespace is not a valid podman run flag; namespace sharing comes from joining the pod, not from a run-time option. It tempts because the flag name sounds like the mechanism, and would fit if Podman exposed namespace sharing as a standalone switch.

podman pod connect mypod myimage

Why it fails: podman pod connect attaches an existing container to a pod's namespaces; it neither creates a container nor accepts an image argument, so it cannot launch the two containers required. It tempts because it genuinely joins containers to pods, which is correct when the containers already exist.

podman run --network pod:mypod -d myimage

Why it fails: --network pod:mypod joins the container to the pod's network namespace, but the scenario requires the container to run inside the pod sharing all namespaces, which --pod achieves. It tempts because it does share networking, and would be correct if only the network namespace needed sharing.

/etc/sysconfig/podman using the SEARCH_REGISTRIES variable

Why it fails: /etc/sysconfig/podman holds environment variables for the Podman service, not registry expansion rules, so SEARCH_REGISTRIES there never alters `podman pull` resolution. It is tempting because sysconfig files genuinely configure daemon behaviour, and would be the right place to set service-level environment overrides for the podman system service.

/etc/containers/registries.d/default.yaml using the search-domains parameter

Why it fails: registries.d holds per-registry signature and mirror settings, not unqualified-search expansion; search-domains is not a valid key there. It tempts because registries.d is genuinely the right place for registry-specific configuration, such as mirror or signature-store definitions.

~/.config/containers/auth.json using the default-registry key

Why it fails: auth.json stores registry credentials for authentication, not unqualified-name search shortcuts, so it cannot expand 'rhel9'. It is tempting because it configures registry behaviour, but the correct file is registries.conf, whose unqualified-search-registries parameter defines which registries Podman searches.

podman network prune --force

Why it fails: Prune removes all unused user-defined networks, not the single named 'test-net', so it could delete other dormant networks you intended to keep. It is tempting because prune does clear unused networks, and it would be the right choice when reclaiming space from many stale networks rather than one specific one.

podman rm network test-net

Why it fails: podman rm removes containers or images, not networks; the network subcommand is absent, so this syntax fails. podman network rm test-net is the correct command. podman rm suits deleting stopped containers, which is a different resource class entirely.

podman network delete test-net

Why it fails: Podman's removal subcommand is 'rm', not 'delete'; 'podman network delete test-net' is not a valid command and fails immediately. It is tempting because 'delete' is the intuitive verb for removing a named resource, and it would be correct if Podman had adopted that alias instead of 'rm'.

They are converted into host-level iptables rules embedded in annotations.

Why it fails: Podman records published ports as containerPort and hostPort entries in the generated Pod spec, not as iptables rules in annotations. Annotations carry metadata for external tooling, which is why this mapping appears plausible to anyone familiar with CNI port-mapping implementations.

They are ignored entirely and must be added manually.

Why it fails: Published ports are translated into the manifest's ports section, so nothing is discarded. Treating them as ignored would be reasonable only if the command produced a bare container spec with no networking fields, which is not how the generator behaves.

They cause the generation command to fail with a port conflict error.

Why it fails: Port publishing is a normal container attribute that the generator translates without error. Assuming failure confuses this with a genuine host-port collision at container start, where two containers binding the same port on one host would indeed conflict.

The signature verification policy file '/etc/containers/policy.json'.

Why it fails: policy.json manages image signatures, not storage drivers.

The registry authentication file '~/.config/containers/auth.json'.

Why it fails: auth.json stores registry credentials, not storage settings.

--ephemeral

Why it fails: --ephemeral applies to podman run, causing the container to be removed on exit, but podman generate systemd does not accept it to control service stop behaviour. It suits one-off run commands where automatic container cleanup after exit is wanted.

--recreate

Why it fails: --recreate is not a podman generate systemd flag; it belongs to podman play kube and podman-compose workflows for rebuilding containers. It suits recreating pods from Kubernetes YAML manifests, not generating a systemd unit that removes its container on stop.

--auto-remove

Why it fails: The --auto-remove flag only deletes the container once it exits, and does not make systemd recreate a fresh container on start; that behaviour comes from --new. It is tempting because it genuinely handles cleanup after a container stops, which suits one-shot or batch workloads rather than persistent services.

podman network attach backend-net web1

Why it fails: 'podman network attach' does not exist; the actual subcommand is 'podman network connect', which hot-plugs a running container into a user-defined network without restarting it. The name 'attach' is tempting because Podman uses it for volumes and containers, but network membership uses 'connect' instead.

podman container modify --network backend-net web1

Why it fails: Podman offers no container modify subcommand; network attachment for a running container is done with podman network connect, which updates the network namespace live. Modify-style commands exist for podman pod and some container attributes, but not network membership, so this syntax fails outright.

podman network join --container web1 backend-net

Why it fails: Podman has no 'network join' subcommand; the correct verb is 'connect', which attaches a running container to a user-defined network via the container's network namespace. The join syntax resembles Docker Swarm service joining, so it tempts administrators familiar with orchestration tooling rather than Podman's own network management commands.

podman run -v /host/dir:/container/dir:mtype=shared myapp

Why it fails: mtype=shared is not valid volume syntax; the propagation mode is given directly as shared, rshared, slave, rslave, private or rprivate. It is tempting because mtype appears in mount(8) documentation for shared subtrees, but Podman's -v flag expects the bare mode keyword.

podman run -v /host/dir:/container/dir:sync myapp

Why it fails: The sync option controls how writes are committed to storage, not mount propagation, so host mounts will not appear inside the container. It is tempting because sync is a valid volume option, and would be the right choice when durability of writes matters rather than propagating host mount events.

podman run -v /host/dir:/container/dir:propagate myapp

Why it fails: propagate is not a recognised volume option; Podman accepts shared, slave, private, rshared, rslave and rprivate for propagation, so the command fails. It is tempting because the word describes the desired outcome, but the correct choice names the actual propagation mode, such as shared.

podman ports proxy_svr

Why it fails: podman ports is not a valid subcommand.

podman inspect --ports proxy_svr

Why it fails: There is no --ports flag in podman inspect.

podman ps --filter port=80

Why it fails: While ps has filter options, it does not output mapped host ports in a custom formatted list like inspect formatting does.

/etc/systemd/system/containers/

Why it fails: Quadlet reads .container files from the standard systemd unit search paths; a nested containers subdirectory is not scanned, so the unit is never generated. It is tempting as an intuitive grouping location, and it would be correct only if systemd's unit path configuration were explicitly extended to include it.

/var/lib/containers/systemd/quadlets/

Why it fails: Quadlet reads system-wide root units from /etc/containers/systemd/, not this path; /var/lib/containers/systemd/quadlets/ is not a search location, so the unit is ignored. The path is tempting because /var/lib/containers holds Podman's storage, but that is image and container data, not unit definitions.

/etc/systemd/system/

Why it fails: Root containers read Quadlets from /etc/containers/systemd/, not /etc/systemd/system/, which holds native systemd unit files. The directory is tempting because it is the standard location for system-wide unit definitions, and it would be correct for a hand-written .service unit rather than a Quadlet-generated one.