収録問題 80問 ／ 10問ランダム出題
ランダムに出題・即時フィードバック・間違えた問題の復習機能付き
開発中のNode.jsアプリで、依存関係のインストール結果をイメージに固定しつつ、ソース変更時の再ビルドを速くしたい。Dockerfileで先にコピーするべきものはどれですか？
答え： package.json とロックファイル
依存関係定義だけを先にコピーしてインストールすると、そのレイヤーをキャッシュしやすくなります。ソース変更だけなら依存関係の再インストールを避けやすくなります。
開発環境でホスト上のソース変更をすぐコンテナに反映したい。最も自然な方法はどれですか？
答え： バインドマウントでソースディレクトリをマウントする
バインドマウントはホストのファイルをコンテナへ直接見せられるため、ローカル開発でよく使います。
開発用Composeで、アプリの待受ポート3000をホストの3000番から確認したい。設定として適切なのはどれですか？
答え： ports: ["3000:3000"]
ports はホスト側ポートとコンテナ側ポートの公開に使います。3000:3000 はホスト3000からコンテナ3000へ転送します。
コンテナ内でアプリがlocalhostに接続しても、ホスト側DBへつながらない。理由として最も適切なのはどれですか？
答え： コンテナ内のlocalhostはコンテナ自身を指すため
コンテナは独自のネットワーク名前空間を持つため、コンテナ内のlocalhostはホストではなくコンテナ自身です。
開発用と本番用で起動コマンドやマウントだけを変えたい。Composeで分ける方法として適切なのはどれですか？
答え： ベースComposeに開発用overrideファイルを重ねる
Composeは複数ファイルをマージできます。共通定義を保ち、開発固有のマウントやコマンドだけをoverrideする形が扱いやすいです。
コンテナ内で作った依存キャッシュをビルド間で再利用し、最終イメージには含めたくない。BuildKitで適切なのはどれですか？
答え： RUN --mount=type=cache
BuildKitのcache mountは、パッケージマネージャのキャッシュなどをビルド間で再利用しつつ、イメージレイヤーには直接含めない用途に向きます。
ホットリロード用の開発コンテナで、依存関係ディレクトリだけはコンテナ側のものを使いたい。よく使う構成はどれですか？
答え： ソースをバインドマウントし、依存ディレクトリは名前付きボリュームで分離する
ホストのソースを見せつつ、node_modulesなどOS差が出やすい依存ディレクトリは名前付きボリュームでコンテナ内管理にする構成があります。
開発チームでDockerfileを共有するとき、OSパッケージのインストールを安定させる観点で避けたい書き方はどれですか？
答え： apt-get upgrade -y を通常のアプリイメージビルドに入れる
アプリ用イメージでは必要パッケージを絞って入れるのが基本です。広範なupgradeはビルド結果の予測を難しくし、ベースイメージ管理との責務も曖昧になります。
コンテナ内アプリの設定値を開発環境ごとに変えたいが、イメージは共通にしたい。適切なのはどれですか？
答え： 環境変数や外部設定として実行時に渡す
設定はイメージに固定しすぎず、環境変数や設定ファイル、Secret管理などで実行時に注入すると、同じイメージを複数環境で使いやすくなります。
ローカル開発で複数サービスをまとめて起動し、サービス名で通信したい。最も向いているものはどれですか？
答え： Docker Compose
Composeは複数コンテナのサービス、ネットワーク、ボリューム、環境変数などをファイルで定義して一括起動できます。
ローカルにあるイメージ一覧を確認したい。使うコマンドはどれですか？
答え： docker image ls
docker image ls はローカルのイメージ一覧を表示します。タグ、イメージID、サイズなどを確認できます。
バックグラウンドでコンテナを起動し、不要になったら停止時に自動削除したい。適切な組み合わせはどれですか？
答え： docker run -d --rm ...
-d はデタッチ実行、--rm は停止後のコンテナ自動削除です。一時的な検証用コンテナで便利です。
停止中も含めてコンテナ一覧を確認したい。適切なコマンドはどれですか？
答え： docker ps -a
docker ps は実行中コンテナ一覧、-a を付けると停止済みを含めた一覧になります。
稼働中コンテナの標準出力ログを追いかけながら確認したい。使うコマンドはどれですか？
答え： docker logs -f <container>
docker logs -f はコンテナのログを追跡表示します。アプリログを標準出力へ出す設計と相性がよいです。
稼働中コンテナの中で一時的にシェルを開いて調査したい。適切なのはどれですか？
答え： docker exec -it <container> sh
docker exec は稼働中コンテナ内で追加コマンドを実行します。-it を付けると対話的なシェル調査に使えます。
Dockerfileからmyapp:devという名前でイメージを作りたい。適切なコマンドはどれですか？
答え： docker build -t myapp:dev .
docker build -t 名前:タグ ビルドコンテキスト でDockerfileからイメージをビルドし、タグを付けます。
未使用の停止コンテナ、ネットワーク、danglingイメージ、ビルドキャッシュをまとめて掃除したい。候補として適切なのはどれですか？
答え： docker system prune
docker system prune は未使用リソースの整理に使います。削除対象を確認し、必要なボリュームやイメージを消さないよう注意します。
Composeで定義したサービスをバックグラウンド起動したい。適切なのはどれですか？
答え： docker compose up -d
docker compose up -d はComposeサービスを作成・起動し、デタッチ状態で実行します。
コンテナやイメージの詳細なJSONメタデータを確認したい。使うコマンドはどれですか？
答え： docker inspect
docker inspect はIPアドレス、マウント、環境変数、設定などの詳細メタデータをJSONで確認できます。
コンテナからホストへ設定ファイルを取り出したい。適切なコマンドはどれですか？
答え： docker cp <container>:/path/file ./file
docker cp はホストとコンテナ間のファイルコピーに使います。調査時の設定ファイル取得などに便利です。
本番用イメージを小さくし、ビルド用ツールを含めない設計として最も適切なのはどれですか？
答え： マルチステージビルドでビルド成果物だけを最終ステージへコピーする
マルチステージビルドでは、ビルド用ステージと実行用ステージを分け、最終イメージに必要な成果物だけを含められます。
コンテナイメージ設計で、1つのコンテナに複数の独立した長時間プロセスを詰め込みすぎない主な理由はどれですか？
答え： 監視、再起動、スケール、ログ分離が難しくなるため
コンテナは責務を絞ると運用しやすくなります。複数責務を入れすぎると障害切り分けやスケール単位が曖昧になります。
本番で同じイメージを確実に再利用したい。タグ設計としてより安全なのはどれですか？
答え： バージョンタグやイメージダイジェストをデプロイに使う
可変なlatestだけに頼ると、同じ指定でも別内容になる可能性があります。バージョンタグやダイジェストを使うと追跡しやすくなります。
DockerfileでCOPY . .する前に.dockerignoreを整える主な目的はどれですか？
答え： 不要・機密ファイルをビルドコンテキストから除外するため
.dockerignore はビルドコンテキストへ送るファイルを減らし、秘密情報や不要な巨大ファイルの混入を防ぎます。
コンテナのデータ永続化設計で、DBデータをコンテナの書き込みレイヤーだけに置くのを避ける理由はどれですか？
答え： コンテナ削除や再作成でデータを失いやすいため
コンテナの書き込みレイヤーはコンテナ寿命に強く依存します。DBデータはボリュームや外部DBなどで永続化する設計が基本です。
Webアプリイメージ設計で、EXPOSE 8080 の意味として正しいものはどれですか？
答え： コンテナが8080番で待ち受ける意図をメタデータとして示す
EXPOSE は公開意図のメタデータであり、ホスト公開にはdocker run -pやComposeのportsなどが必要です。
アプリ設定をDockerfileのARGだけで本番実行時に切り替えようとして失敗した。理由として適切なのはどれですか？
答え： ARGは主にビルド時変数で、実行時設定にはENVや外部注入を使うため
ARGはビルド中の値として扱うのが基本です。実行時に変えたい値は環境変数、設定ファイル、Secret管理などで渡します。
イメージレイヤー設計で、頻繁に変わるファイルをDockerfileの後半でコピーする利点はどれですか？
答え： 前半の安定したレイヤーキャッシュを再利用しやすくなる
Dockerfileは命令順にキャッシュが効きます。変化しにくい依存関係処理を前に、変化しやすいソースコピーを後ろに置くと効率的です。
本番コンテナでアプリログをファイルだけに書く設計より、標準出力へ出す設計が好まれやすい理由はどれですか？
答え： コンテナランタイムやログ基盤が収集しやすいため
コンテナのログは標準出力・標準エラーへ出すと、Dockerやクラウドのログ収集と連携しやすくなります。
イメージにビルド時の秘密情報を残さない設計として適切なのはどれですか？
答え： BuildKitのsecret mountなど、レイヤーに残しにくい仕組みを使う
DockerfileのENVやCOPYで秘密情報を扱うとレイヤー履歴などに残る危険があります。BuildKit secret mountなどを使うと露出を減らせます。
本番でコンテナが異常終了したとき自動再起動したい。単体Docker実行で使う設定として適切なのはどれですか？
答え： --restart=unless-stopped などの再起動ポリシー
再起動ポリシーはDockerデーモンがコンテナ終了時の扱いを判断するための設定です。--rmとは併用目的が異なります。
コンテナのCPUやメモリ使用量をリアルタイムに確認したい。適切なコマンドはどれですか？
答え： docker stats
docker stats はコンテナごとのCPU、メモリ、ネットワーク、ブロックI/Oなどを表示します。
本番運用でコンテナの状態を外部監視から判断しやすくしたい。イメージ側に用意するとよいものはどれですか？
答え： HEALTHCHECK または監視しやすいヘルスエンドポイント
ヘルスチェックはプロセス生存だけでなく、アプリとして正常に応答できるかを判断する材料になります。
運用中コンテナの設定やマウント、ネットワークを後から調べたい。最初に使いやすいコマンドはどれですか？
答え： docker inspect <container>
docker inspect はコンテナの詳細情報をJSONで返すため、マウントやネットワーク、環境変数の確認に向いています。
ホストのディスク容量が逼迫し、Dockerの使用量内訳を確認したい。使うコマンドはどれですか？
答え： docker system df
docker system df はイメージ、コンテナ、ボリューム、ビルドキャッシュの使用量概要を確認できます。
本番に近い検証で、コンテナにメモリ上限を設定したい。単体Docker実行で使う代表的な指定はどれですか？
答え： docker run --memory 512m ...
--memory はコンテナのメモリ使用量に上限を設定する代表的なオプションです。
本番障害時、コンテナ内へ入って手で直す対応が根本対策になりにくい理由はどれですか？
答え： 変更が再現されず、再作成や再デプロイで失われるため
コンテナは再作成される前提で扱います。修正はDockerfile、設定、デプロイ定義へ反映して再現可能にするのが基本です。
Composeサービスのログをサービス横断で確認したい。適切なコマンドはどれですか？
答え： docker compose logs
docker compose logs はComposeプロジェクト内サービスのログ確認に使います。-fで追跡表示もできます。
イメージを別環境へファイルとして渡したいが、レジストリは使えない。適切な組み合わせはどれですか？
答え： docker save と docker load
docker save はイメージをtarに保存し、docker load はそれを読み込みます。タグやレイヤーを保った移送に使います。
運用で不要リソースを削除する前に、特に注意すべきものはどれですか？
答え： 名前付きボリュームに必要な永続データが残っていないか
ボリュームにはDBやアップロードファイルなど重要データが入ることがあります。削除前に用途とバックアップを確認します。
Dockerfileでアプリをrootユーザーのまま実行しないために使う代表的な命令はどれですか？
答え： USER
USER は以降の命令や実行時プロセスのユーザーを指定します。非root実行は権限を絞る基本対策です。
ビルド時にプライベートリポジトリへアクセスする秘密鍵を使いたいが、イメージには残したくない。適切なのはどれですか？
答え： BuildKitのSSH mountやsecret mountを使う
BuildKitのSSH/secret mountは、ビルド中だけ秘密情報を参照し、レイヤーに残すリスクを下げるために使います。
イメージの脆弱性リスクを下げるため、ベースイメージ選定で特に意識することはどれですか？
答え： 必要最小限で、更新されている信頼できるベースを使う
小さく保守されている信頼元のベースは、不要パッケージや既知脆弱性の混入を減らしやすくなります。
コンテナへホストのDockerソケット/var/run/docker.sockをマウントする場合の主なリスクはどれですか？
答え： コンテナからホスト上のDockerを強力に操作できる可能性がある
DockerソケットはホストDockerデーモンへの操作口です。マウントするとコンテナ脱出に近い強い権限につながるため慎重に扱います。
コンテナに不要なLinux capabilityを与えない目的として適切なのはどれですか？
答え： 侵害時に使える権限を減らすため
capabilityはroot権限の一部を細分化したものです。不要なものを落とすと、侵害時の被害範囲を狭めやすくなります。
コンテナのファイルシステム改ざんリスクを下げたい。実行時設定として候補になるものはどれですか？
答え： --read-only
--read-only はコンテナのルートファイルシステムを読み取り専用にします。書き込みが必要な場所はtmpfsやボリュームで明示します。
DockerイメージをCIで扱う際、脆弱性確認として追加したい工程はどれですか？
答え： イメージスキャンを実行し、重大度に応じてリリース判定する
CIでイメージスキャンを行うと、ベースイメージや依存パッケージの既知脆弱性をリリース前に検出しやすくなります。
コンテナに機密情報を渡す設計で避けたいものはどれですか？
答え： 秘密情報をDockerfileへ直接書く
Dockerfileへ秘密情報を書くと、イメージ履歴やレジストリ経由で漏れる危険があります。実行時のSecret管理を使うのが基本です。
本番コンテナに--privilegedを安易に付けるべきでない理由はどれですか？
答え： ホストに近い強い権限を与え、隔離を弱めるため
--privileged は多くの権限やデバイスアクセスを与えます。必要なcapabilityやデバイスだけを個別に許可する設計を検討します。
Docker Engine自体をroot権限なしで動かし、デーモン侵害時の影響を抑える選択肢として知られるものはどれですか？
答え： Rootless mode
Rootless modeはDockerデーモンとコンテナを非rootユーザーで動かす選択肢です。制約もあるため要件に合わせて検討します。
開発用のComposeで、ソースコードは即時反映したいが、コンテナ内で作られる依存ライブラリのディレクトリはホスト側で上書きしたくない。適切な考え方はどれですか？
答え： ソースはbind mountし、依存ディレクトリには別volumeを割り当てる
開発時はソースをbind mountすると編集が即時反映されます。一方、依存ディレクトリを別volumeにすると、ホスト側の空ディレクトリなどでコンテナ内の依存関係を隠してしまう問題を避けやすくなります。
停止済みコンテナを含め、直近に終了したコンテナの終了コードを確認したい。まず使うコマンドとして適切なものはどれですか？
答え： docker ps -a
docker ps -aは停止済みを含むコンテナ一覧を表示し、STATUS欄で終了状態や終了コードを確認できます。詳細が必要な場合はdocker inspectも併用します。
本番用イメージで、ビルド時に必要なコンパイラや開発ツールを最終イメージへ残したくない。Dockerfile設計として適切なものはどれですか？
答え： multi-stage buildでビルド成果物だけを最終ステージへコピーする
multi-stage buildでは、ビルド用ステージに開発ツールを置き、最終ステージへ成果物だけをコピーできます。最終イメージを小さくし、不要な攻撃面を減らしやすくなります。
本番運用でコンテナのログを集約基盤へ送りたい。アプリケーション側の基本方針として適切なものはどれですか？
答え： 標準出力・標準エラーへログを書き、実行基盤側で収集する
コンテナでは標準出力・標準エラーへログを出すと、Dockerやオーケストレーション基盤、ログドライバが収集しやすくなります。コンテナ内ファイルだけに閉じると消失や収集漏れの原因になります。
イメージの取得元を信頼しやすくするため、CIでベースイメージの参照をより再現性高く固定したい。タグだけに頼るより適切な方法はどれですか？
答え： イメージdigestで参照を固定する
タグは同じ名前でも指すイメージが変わることがあります。digestで固定すると、取得するイメージ内容をより厳密に指定でき、再現性や追跡性を高められます。
ローカルにpull済みのイメージが増えてきた。どのリポジトリ名、タグ、イメージID、サイズがあるかをまず一覧で確認したい。適切なコマンドはどれですか？
答え： docker image ls
docker image ls はローカルに存在するイメージの一覧を表示します。pull済みイメージのタグ、ID、作成時期、サイズを把握する最初の確認に向いています。
ビルドやpullを繰り返した結果、<none> と表示されるdanglingイメージが残っている。使用中コンテナに必要なイメージを消さず、まず未参照のdanglingイメージだけを整理したい。適切な操作はどれですか？
答え： docker image prune を実行し、削除対象を確認して進める
docker image prune は既定でdanglingイメージを削除します。-a やvolume削除を含む広いpruneは影響が大きいため、目的と削除対象を確認して使い分けます。
ローカルにpullした nginx:1.27 を、社内検証で分かりやすい web-proxy:test という別名でも扱いたい。イメージ内容を複製せず参照名を追加する操作はどれですか？
答え： docker tag nginx:1.27 web-proxy:test
docker tag SOURCE_IMAGE TARGET_IMAGE は既存イメージに別のリポジトリ名やタグを付けます。イメージの実体を別コピーするのではなく、同じイメージIDを別名で参照できます。
ローカルにpullしたイメージが、想定していたdigestの内容か確認したい。イメージの詳細メタデータからRepoDigestsなどを確認するコマンドとして適切なものはどれですか？
答え： docker image inspect <image>
docker image inspect はローカルイメージの詳細情報をJSONで表示します。RepoDigests、ID、ラベル、作成情報などを確認でき、pull済みイメージの追跡に役立ちます。
インターネットに接続できない検証環境へ、ローカルにpull済みのタグ付きイメージをファイルとして持ち込みたい。タグやレイヤーを保って移送する組み合わせはどれですか？
答え： docker save で保存し、移送先で docker load する
イメージをオフライン移送する場合は docker save でtar化し、移送先で docker load します。export/import はコンテナのファイルシステム向けで、イメージのタグやレイヤー保持とは目的が異なります。
Dockerを初めて使うメンバーに、イメージとコンテナの関係を説明したい。最も適切な説明はどれですか？
答え： イメージは実行前のテンプレートで、コンテナはそのイメージから起動した実行単位である
Dockerイメージはアプリケーションや実行環境をまとめた読み取り専用の雛形です。コンテナはそのイメージをもとに作成され、プロセスとして実行される単位です。
ローカルにない redis:7 イメージを取得してからコンテナを起動したい。Dockerが通常行う流れとして適切なものはどれですか？
答え： 指定イメージがローカルになければレジストリからpullし、その後コンテナを作成・起動する
docker run redis:7 のように指定したイメージがローカルにない場合、Dockerは設定されたレジストリからイメージを取得してからコンテナを作成・起動します。
ホストPCのブラウザから、コンテナ内で80番ポートをlistenするWebサーバーへ http://localhost:8080 でアクセスしたい。適切なポート公開指定はどれですか？
答え： -p 8080:80
-p ホスト側ポート:コンテナ側ポート の順で指定します。ホストの8080番をコンテナの80番へ転送したい場合は -p 8080:80 です。
コンテナを削除してもDBのデータを残したい。Docker管理の保存領域として基本的に使うものはどれですか？
答え： named volume
DBデータのようにコンテナのライフサイクルから切り離して残したいデータには、Dockerが管理するnamed volumeがよく使われます。
一時的な検証用コンテナを、終了時に自動で削除したい。手元に停止済みコンテナを残さない実行オプションとして適切なものはどれですか？
答え： --rm
docker run --rm ... はコンテナ終了時にそのコンテナを自動削除します。短い検証やワンショットコマンドで停止済みコンテナを残したくない場合に便利です。
ComposeでAPIがDBの接続受付開始後に起動するようにしたい。DBコンテナの単なる起動ではなく、ヘルスチェック成功を待つ設定として適切なのはどれですか？
答え： depends_onでDBにcondition: service_healthyを指定する
DB側にhealthcheckを定義し、API側のdepends_onでcondition: service_healthyを指定すると、ComposeはDBがhealthyになるまでAPIの依存条件を満たしません。
起動に40秒かかるアプリへ5秒間隔のヘルスチェックを設定したところ、初期化中の失敗が早期に記録される。起動猶予を明示する項目はどれですか？
答え： start_period
start_periodはアプリの初期化時間を考慮する猶予期間です。その期間中の失敗を通常の連続失敗判定と分けて扱い、起動の遅いサービスの誤判定を減らします。
単一ホストのDockerでjson-fileログが増え続け、ディスク逼迫を起こしている。コンテナ作成時にログ容量を抑える代表的な設定はどれですか？
答え： --log-opt max-size=10m --log-opt max-file=3
json-fileロギングドライバーではmax-sizeとmax-fileでローテーションのサイズと保持ファイル数を制限できます。既存コンテナではなく、再作成時の設定として適用します。
同じDockerfileからamd64とarm64向けイメージを作り、1つのタグでレジストリへ公開したい。適切なコマンド方針はどれですか？
答え： docker buildx build --platform linux/amd64,linux/arm64 --push ...
buildx buildで複数の--platformを指定して--pushすると、各アーキテクチャのイメージと、それらを束ねるマニフェストをレジストリへ公開できます。
コンテナ停止時にアプリへSIGTERMを正しく届け、猶予時間内に処理を終了させたい。Dockerfileの起動指定として適切なのはどれですか？
答え： ENTRYPOINT ["myapp", "--serve"]のexec形式
exec形式は不要なシェルを介さずアプリをPID 1として起動しやすく、Dockerからの停止シグナルを直接受け取れます。アプリ側にもSIGTERM処理が必要です。
アプリが子プロセスを生成するが、終了した子を回収せずゾンビプロセスが残る。アプリ改修までの補助策として適切なのはどれですか？
答え： docker run --init ...
--initは小さなinitプロセスをPID 1として挿入し、シグナル転送や孤児・ゾンビプロセスの回収を補助します。根本的にはアプリのプロセス管理も見直します。
Composeで通常はAPIとDBだけを起動し、デバッグ用管理UIは必要なときだけ追加したい。適切な機能はどれですか？
答え： 管理UIサービスにprofiles: ["debug"]を設定する
Compose profilesを使うと、特定サービスを通常起動から外し、--profile debugのように指定したときだけ有効化できます。
80番ポートをlistenするWebプロセスに、不要なLinux capabilityを与えたくない。最小権限に近づける指定はどれですか？
答え： --cap-drop ALL --cap-add NET_BIND_SERVICE
全capabilityを落として必要なNET_BIND_SERVICEだけを戻すと、低い番号のポートを使う要件を満たしつつ権限を限定できます。アプリやベースイメージで追加要件がないか検証します。
コンテナ内プロセスがsetuidバイナリなどで追加権限を得ることを抑止したい。適切なセキュリティ指定はどれですか？
答え： --security-opt no-new-privileges=true
no-new-privilegesは、実行中プロセスや子プロセスが現在より高い権限を得ることを禁止します。非root実行やcapability削減などと組み合わせます。
複数のComposeファイルと環境変数をマージした最終設定を、起動前に確認したい。適切なコマンドはどれですか？
答え： docker compose config
docker compose configはファイルのマージ、変数展開、正規化後のComposeモデルを表示し、起動前の設定確認や構文検証に使えます。
フロントエンドからのみ到達させたいDB用Composeネットワークを、ホスト外部へ直接接続できない形にしたい。適切なネットワーク設定はどれですか？
答え： internal: true
Composeネットワークのinternal: trueは外部接続性を持たない内部ネットワークを作ります。必要なサービスだけを接続し、DBポートをホストへ公開しない構成と組み合わせます。
最終イメージ内のファイル所有者を非rootユーザーへ設定したいが、別のRUN chownレイヤーは増やしたくない。適切なDockerfile指定はどれですか？
答え： COPY --chown=app:app ./dist /app
COPY --chownはファイルをイメージへコピーする時点で所有者とグループを設定します。後続のRUN chownを避け、非root実行用の所有権を明示できます。
稼働中コンテナへ手作業でパッケージを追加したところ、次回デプロイで変更が消えた。恒久対応として適切なのはどれですか？
答え： Dockerfileへ変更を反映して新しいイメージを作り、コンテナを再作成する
コンテナは再作成可能な実行単位として扱い、OSパッケージやアプリ変更はDockerfileとビルド手順へ反映します。これにより環境を再現でき、変更履歴もレビューできます。
DBのnamed volumeをファイルコピーでバックアップしたい。書き込み中の不整合を避ける基本方針として最も適切なのはどれですか？
答え： DBを停止または静止状態にするか、DB公式のバックアップ機能を使う
書き込み中のDBファイルをそのままコピーすると、複数ファイル間の時点がずれる可能性があります。停止・静止化、スナップショット連携、またはDB製品の論理・物理バックアップ機能を使います。
本番コンテナのルートファイルシステムを読み取り専用にしつつ、/tmpだけは一時書き込み可能にしたい。適切な実行指定はどれですか？
答え： --read-only --tmpfs /tmp
--read-onlyでルートFSを保護し、書き込みが必要な/tmpだけをtmpfsとして明示します。永続化が必要なパスには用途に応じてvolumeを割り当てます。