Amazon SCS-C02: ネットワーキングとVPCセキュリティ — 学習ガイド
こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
VPCエンドポイントとエンドポイントポリシー
VPCエンドポイントは、AWSサービスへのトラフィックをAWSネットワーク内に留め、パブリックインターネット、NATゲートウェイ、インターネットゲートウェイをバイパスします。構造的に異なる2つの種類があり、これらを混同することは最も一般的な設計ミスの1つです。
ゲートウェイエンドポイントは、Amazon S3とDynamoDBにのみ存在します。これらはルートテーブルエントリです。エンドポイントをルートテーブルに関連付けると、サービスのプレフィックスリスト（例：us-east-1のS3の場合はpl-63a5400a）宛のトラフィックは、エンドポイント経由で透過的に再ルーティングされます。コストはかからず、アタッチされたVPCの外部からはアクセスできません。
インターフェイスエンドポイント（AWS PrivateLinkを利用）は、プライベートIPアドレスを持つENIとしてサブネット内に配置されます。S3やDynamoDB以外のすべてのサービス（Secrets Manager、KMS、STS、SSM、CloudWatch Logs、ECR API/DKRなど、その他数百）で必要とされます。NATゲートウェイを持たないプライベートサブネットのEC2インスタンスがSecrets ManagerからGetSecretValueする必要がある場合、ゲートウェイエンドポイントは役に立ちません。com.amazonaws.<region>.secretsmanagerインターフェイスエンドポイントを作成し、プライベートDNSを有効にして、標準のサービスホスト名がエンドポイントのプライベートIPに解決されるようにする必要があります。
エンドポイントポリシーは、呼び出し元のIAMポリシーとは独立して、エンドポイント経由で何ができるかを制限します。データ窃取を防ぐための最も重要な2つの条件キーは、aws:PrincipalOrgID（呼び出しを行うアイデンティティが自社のOrganizationに属している必要がある）とaws:ResourceOrgID（アクセス対象のS3バケットやKMSキーなどが自社のOrganizationに属している必要がある）です。両方を適用することで、正規のS3権限を持つ侵害されたインスタンスが、組織外の攻撃者が管理するバケットに書き込むという典型的なデータ窃取経路を閉ざすことができます。認証情報はS3に対して依然として有効ですが、エンドポイントがリクエストの転送を拒否します。
{
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "o-abc123",
"aws:ResourceOrgID": "o-abc123"
}
}
}]
}
デフォルトのエンドポイントポリシーは完全に許可的（"Resource":"*"に対して"Action":"*"）です。そのため、ゲートウェイエンドポイントと最小権限のIAMのみを持つサブネットであっても、エンドポイントポリシー自体を厳格化しない限り、データ窃取に悪用される可能性があります。
ハイブリッド接続: VPNとDirect Connect
Site-to-Site VPNは、仮想プライベートゲートウェイ（またはTransit Gateway）とカスタマーゲートウェイデバイスの間に2つのIPsecトンネルを確立します。プロビジョニングが迅速で、デフォルトで暗号化されており、パブリックインターネットを経由するため、スループットとレイテンシーはISPの経路に依存します。
AWS Direct Connectは、Direct Connectロケーションを介して専用の物理回線をプロビジョニングします。予測可能な低レイテンシーと、一貫した広帯域（1/10/100 Gbps）を提供し、これは通信量の多いオンプレミスのデータベーストラフィックにとって重要です。Direct Connect自体はレイヤー3で暗号化されません。フレームはプライベートファイバー上を流れます。低レイテンシーとIPsecの両方を必要とするワークロードの場合、標準的な解決策は、Direct Connectに加えてパブリックVIF上でSite-to-Site VPNを実行する（または新しいDXポートでMACsecを備えたTransit Gatewayを使用する）ことです。また、VPN単体は、プライマリのDirect Connectリンクに対する暗号化されたバックアップとしても推奨されており、回線障害時の耐障害性を提供します。
- Direct Connectのみ: 低レイテンシー、プライベートだがIPレイヤーでは非暗号化。
- VPNのみ: 暗号化済み、迅速にデプロイ可能だが、インターネット経路のレイテンシーとジッターがある。
- Direct Connect + VPN: 低レイテンシーかつIPsec暗号化。標準的なHAパターンでもある。
セキュリティグループ、NACL、DHCP、送信元/送信先チェック
セキュリティグループはステートフルです。インバウンドリクエストを許可すると、そのレスポンスは自動的にアウトバウンドが許可されます。許可ルールのみをサポートし、ENIごとに評価されます。
ネットワークACLはステートレスで、サブネット境界で動作します。すべてのフローには2つのルールが必要です。1つは最初の方向の通信用、もう1つはエフェメラルポート範囲（Linuxでは通常32768–60999、Windowsでは49152–65535、NLB/ELBでは1024–65535を使用）での戻りトラフィック用です。インバウンドのTCP 443を許可しつつ、アウトバウンドのTCP 1024–65535を許可し忘れたNACLは、TLS通信をサイレントに失敗させます。ICMPはTCP/UDPとは異なります。戻りの「echo reply」パケットは明示的に許可する必要があり、Path MTU DiscoveryはICMPタイプ3コード4に依存しているため、意図せずドロップしやすいです。また、NACLのルールは番号順に評価され、最初に一致したものが適用され、最後に暗黙の拒否ルールがあります。
DHCPオプションセットは、VPCが起動時にインスタンスに渡す情報を制御します：domain-name-servers、domain-name、NTPサーバー、NetBIOSなどです。デフォルトのAmazonProvidedDNSをカスタムのオンプレミスリゾルバーに置き換えることは正当な場合がありますが、実際のセキュリティ上の影響があります。GuardDutyのようなサービスは、Route 53 Resolverを通過するクエリからDNSベースの検出結果（例：「cryptocurrency」や「C&C domain」の検出）を導き出します。インスタンスがサードパーティのDNSサーバーを参照するようになると、GuardDutyはそのクエリを検知できなくなり、これらの検出結果タイプは表示されなくなります。これは、意図せず検出を無効にしてしまう簡単な方法です。
送信元/送信先チェックは、送信元または送信先のIPがENIと一致しないパケットをドロップするENIの属性です。このデフォルトは通常のインスタンスには正しい設定ですが、トラフィックを転送する役割を持つアプライアンス（NATインスタンス、仮想ファイアウォール（Palo Alto、Fortinet、Check Point）、トランジットルーター、VPNコンセントレーターなど）の動作を妨げます。これらのENIについては、このチェックを無効にしてください：
aws ec2 modify-instance-attribute \
--instance-id i-0abc123 \
--no-source-dest-check
VPCピアリング、RAM共有VPC、NAT設計
VPCピアリングは、1対1の非推移的なレイヤー3リンクです。AがBとピアリングし、BがCとピアリングしている場合、AはCに到達できません。AとCを直接ピアリングするか、Transit Gatewayを使用する必要があります。両側のルートテーブルには、ピアCIDRへのルートを含める必要があり、セキュリティグループはリージョン内でのみピアのセキュリティグループIDを参照できます。
AWS Resource Access Manager (RAM)を介した共有VPCでは、ネットワークアカウントがVPCを所有し、個々のサブネットを参加者アカウントと共有できます。参加者は共有サブネットにリソースを起動しますが、VPC、ルートテーブル、またはエンドポイントを変更することはできません。所有者が接続ポリシーの制御を維持します。これは、多くのVPCをピアリングするよりも安価でシンプルになることが多いです。
プライベートサブネットからのアウトバウンドインターネットアクセスには、NATゲートウェイをアベイラビリティーゾーンごとにデプロイし、各プライベートサブネットを自身と同じAZにあるNATにルーティングします。単一のNATゲートウェイはAZ間の依存関係となり、スケール/可用性のボトルネックになります。ワークロードが、送信元IPを許可リストに登録するサードパーティ（例えば決済プロセッサ）を呼び出す場合、登録するのはNATゲートウェイのElastic IPです。Auto Scalingグループの背後にあるインスタンスはすべてその固定EIPを介して送信されるため、グループがスケールしても送信元IPは変わりません。EC2インスタンスとRDSデータベースをプライベートサブネットに配置し、ALBでHTTP/HTTPSのみを終端させることで、このパターンが完成します。
Route 53 Resolver：転送とクエリログ
Route 53 Resolver（すべてのVPCにある.2アドレス）は、ハイブリッドDNSの要です。アウトバウンドリゾルバーエンドポイントは、条件付き転送ルールを介して、指定されたドメイン名をAWSからオンプレミスのDNSサーバーに転送します。これは、例えばcorp.example.internalがActive Directoryに対して解決されるようにするために使用されます。インバウンドリゾルバーエンドポイントはその逆を行い、オンプレミスのホストが*.eu-west-1.compute.internalやプライベートホストゾーンを解決するためにクエリできるプライベートIPをVPC内に提供します。
リゾルバークエリログは、VPCから行われたすべてのDNSクエリをCloudWatch Logs、S3、またはKinesis Firehoseに書き込みます。これは、データ漏洩や不正使用が疑われる場合の調査における信頼できる記録であり、GuardDutyを補完しますが、置き換えるものではありません。DHCPオプションセットがインスタンスをAmazon以外のリゾルバーにリダイレクトする場合、クエリがRoute 53 Resolverに到達しないため、クエリログとGuardDutyのDNS関連の検出結果の両方が機能しなくなることに注意してください。
実践的な問題：ユースケースシナリオ
シナリオ： Meridian Financialは、ハブアンドスポークネットワークを持つマルチアカウントのAWS環境を運用しています。共有サービスVPCは、中央のNATゲートウェイ、Route 53 Resolverエンドポイント、Transit Gatewayアタッチメントをホストし、複数のアプリケーションVPCはTransit Gatewayにピアリングまたはアタッチされています。オンプレミスのデータセンターはDirect ConnectとVPNフェイルオーバーで接続されており、チームはハイブリッドDNS解決のために、一元化されたDHCPオプションセットと共有リゾルバーエンドポイントに依存しています。
課題： 最近のインシデントで、スポークがVPCエンドポイントの代わりに共有NATにルーティングしていたため、機密性の高いS3オブジェクトがパブリックインターネット経由でアクセスされていたことが判明しました。また、内部ゾーンのDNSクエリがパブリックリゾルバーに漏洩し、（送信元/送信先チェックが無効化された）アドホックなルーターとして使用されていたEC2がラテラルムーブメント（横方向の移動）を可能にしていました。
推奨アプローチ：
- 共有サービスVPCにS3とDynamoDB用のゲートウェイVPCエンドポイントと、Secrets ManagerとKMS用のインターフェースエンドポイント（AWS PrivateLink）をデプロイし、指定されたバケットやサービスプリンシパルへのアクセスを制限する明示的なエンドポイントポリシーをアタッチします。
- アプリケーションサブネットがAWS APIとS3にVPCエンドポイントを使用するようにNAT設計を再構築します。NATゲートウェイは、厳格なエグレスセキュリティグループとCloudWatch/S3へのフローログを設定した上で、真のインターネット送信専用として維持します。
- 文書化されたルーティングアプライアンスを除くすべてのEC2インスタンスで送信元/送信先チェックを再度有効にします。ルーティングをTransit GatewayアタッチメントまたはマネージドNATインスタンスに移行し、ルートテーブルの最小権限を徹底します。
- セキュリティグループとサブネットNACLをデフォルトで拒否する姿勢に強化し、AWS OrganizationsのSCPとAWS Configルールを介して、一元化されたIAM+SGベースラインを適用します。
- Route 53 Resolverのインバウンド/アウトバウンドエンドポイントをデプロイし、条件付き転送とDNS Firewallルールを設定し、CloudWatch Logsへのリゾルバークエリログを有効にし、DHCPオプションセットを使用してRAM経由で共有されるすべてのVPCに内部リゾルバーを強制することで、ハイブリッドDNSを強化します。
論理的根拠： このアプローチは、エンドポイントポリシーを持つVPCエンドポイントを使用することで不要なインターネット送信を排除し、Transit Gateway/Direct Connectを介してルーティングを一元化および制御し、インスタンスレベルの保護を回復させ、リゾルバーエンドポイントとロギングでDNS漏洩を防ぎます。これは、AWSのネットワーキングと多層防御のベストプラクティスに沿ったものです。
VPCエンドポイントとエンドポイントポリシー
VPCエンドポイントを使用すると、VPC内のワークロードは、パブリックインターネットやNATゲートウェイを経由せずにAWSサービスのAPIにアクセスできます。アーキテクチャには2つの種類があり、間違ったものを選択すると、トラフィックの誤ったルーティングの一般的な原因となります。
ゲートウェイエンドポイント: Amazon S3とDynamoDBでのみ使用されます。ルートテーブルのターゲットとして実装されます（
vpce-xxxxxxxxを指すプレフィックスリストpl-xxxxxxxx）。ENIは作成されず、DNSの変更も不要で、時間単位のコストはかかりません。インターフェイスエンドポイント (PrivateLink): KMS、SQS、SNS、Secrets Manager、STS、EC2 API、およびその他ほとんどのサービスで使用されます。選択したサブネット内にプライベートIPを持つENIをプロビジョニングし、時間単位およびGB単位で課金されます。
アカウントBのEC2インスタンスが、アカウントAのKMSキーで暗号化されたアカウントAのS3バケットから読み取りを行うクロスアカウントのバッチジョブの場合、正しい設計はS3用のゲートウェイエンドポイントとKMS用のインターフェイスエンドポイントを組み合わせることです。ゲートウェイエンドポイントはs3:GetObject、s3:PutObject、s3:PutObjectAcl、s3:ListBucketのトラフィックをインターネットから隔離し、インターフェイスエンドポイントはkms:Decrypt、kms:Encrypt、kms:GenerateDataKeyに対して同様の役割を果たします。KMSキーのARNは標準のkms.<region>.amazonaws.comホスト名を使用するため、SDKが変更なしのホスト名をパブリックなKMSサービスではなくエンドポイントENIに解決できるように、インターフェイスエンドポイントでプライベートDNSを有効にする必要があります。プライベートDNSを有効にしない場合（またはVPCレベルのDNSホスト名とDNS解決の両方が有効になっていない場合）、クライアントは依然としてパブリックエンドポイントにアクセスしてしまいます。したがって、「コード変更なし」という要件は、暗黙的にプライベートDNSを要求していることになります。
エンドポイントポリシーは、独立した第2の認可レイヤーです。デフォルトでは寛容なポリシーが存在しますが、特定のバケットとキーに対して強化（Hardening）を行う場合は次のようになります。
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": "*",
"Action": ["s3:GetObject","s3:PutObject","s3:PutObjectAcl","s3:ListBucket"],
"Resource": ["arn:aws:s3:::acct-a-bucket","arn:aws:s3:::acct-a-bucket/*"]
}]
}
エンドポイントを作成するだけでは不十分です。2つの典型的な失敗パターンがあります。(1) エンドポイントは存在するが、プライベートサブネットのルートテーブルにS3プレフィックスリストのエントリがないため、トラフィックが依然としてNATゲートウェイ経由で出て行ってしまう。(2) エンドポイントポリシーでs3:PutObjectAclのようなアクションが省略されていたり、間違ったバケットARNをターゲットにしていたりするため、IAMでは許可されるはずの呼び出しがサイレントにブロックされる。バケットポリシーとエンドポイントポリシーの両方でリクエストを許可する必要があります。これらは和集合（union）ではなく、積集合（intersection）として評価されます。
セキュリティグループ、NACL、および迅速な封じ込め
セキュリティグループとNACLは、異なるレイヤーで重複する問題を解決しますが、試験ではインシデント対応のためにどちらかを選択させることがよくあります。
セキュリティグループ: ステートフルで、ENIレベルで評価されます。戻りのトラフィックは自動的に許可されます。許可ルールのみが存在します。ホストレベルのポリシー（例：「Web層はアプリケーション層の8080番ポートにアクセスできる」）に最適です。
ネットワークACL: ステートレスで、サブネットの境界で評価されます。許可ルールと拒否ルールの両方が存在し、ルール番号順に処理されます。サブネット全体にわたる大まかなブロック、特にIP範囲のブロックリスト登録や、サブネット内の全インスタンスで特定のポートをシャットダウンするのに最適です。
マルウェアの感染拡大により、多くのインスタンスでコマンド&コントロール（C2）IPセットへのアウトバウンドTCP/2905をブロックする必要がある場合、NACLの拒否ルールが適切な手段です。セキュリティグループは「拒否」を表現できず、影響を受けるすべてのENIが参照するすべてのSGを列挙して変更する必要があります。サブネットレベルの単一のNACL拒否ルールを低いルール番号（例：90）で設定すれば、そのサブネット内のすべてのインスタンスを即座にカバーしつつ、後の許可ルールで評価される無関係なトラフィックは維持できます。
NACLはステートレスであるため、両方向の通信にルールが必要であることを忘れないでください。2905番ポートでのアウトバウンド（egress）をブロックするのにインバウンド（ingress）ルールは不要ですが、インバウンドの応答も拒否したい場合は、インバウンドのエントリを追加する必要があります。また、正当な戻りトラフィックを通過させるためには、エフェメラルポート（1024–65535）に対するインバウンドの許可エントリが存在しなければなりません。
NATゲートウェイ、ルーティング、およびAZの独立性
NATゲートウェイはゾーンリソースです。標準的なパターンは、アベイラビリティーゾーンごとに1つのNATゲートウェイを配置し、各プライベートサブネットのルートテーブルで0.0.0.0/0を同じAZ内のNATに向けることです。
PrivateRouteTable-AZ-a: 0.0.0.0/0 -> nat-aaaa (in subnet public-az-a)
PrivateRouteTable-AZ-b: 0.0.0.0/0 -> nat-bbbb (in subnet public-az-b)
PrivateRouteTable-AZ-c: 0.0.0.0/0 -> nat-cccc (in subnet public-az-c)
複数のAZで単一のNATを共有すると安価に見えますが、2つの問題が発生します。パケットごとのクロスAZデータ転送料金と、ハードな可用性の依存関係です。そのAZがダウンすると、すべてのプライベートサブネットがインターネットへのアウトバウンドアクセスを失います。ゾーンごとのNATパターンは、Transit Gatewayインスペクションと組み合わせた場合に、非対称リターンのような奇妙な動作を回避するのにも役立ちます（下記参照）。
調査のためのVPCフローログ
フローログは、VPC、サブネット、またはENIレベルで5タプルのメタデータ（送信元/宛先IP、ポート、プロトコル、アクションACCEPT/REJECT、バイト数、パケット数）をキャプチャします。TCP/2905でC2ホストにビーコン信号を送信しているインスタンスを特定するには、VPCでフローログを有効にし、トラフィックタイプをREJECTに設定して（NACLがトラフィックをドロップしているため）、CloudWatch Logs InsightsまたはAthenaでクエリを実行します。
SELECT srcaddr, dstaddr, dstport, action, COUNT(*) AS hits
FROM vpc_flow_logs
WHERE dstport = 2905 AND action = 'REJECT'
GROUP BY srcaddr, dstaddr, dstport, action
ORDER BY hits DESC;
srcaddr列により、パケットキャプチャやホストエージェントなしで、最小限の労力で感染したインスタンスのIPが明らかになります。「ALL」トラフィックを選択しても機能しますが、データ量とコストが増加します。「ACCEPT」のみを選択すると、ドロップされた試行が完全に失われてしまい、まさに確認する必要がある情報を見逃すことになります。
PrivateLink、Transit Gateway、およびNetwork Firewall
PrivateLinkは、インターフェースエンドポイントモデルを独自のサービスに拡張するものです。プロバイダーVPCはVPCエンドポイントサービスの背後でNLBを公開し、コンシューマーはVPCピアリングやルート共有なしでそれにアクセスするためのインターフェースエンドポイントを作成します。これは一方向性であり、プロバイダーのCIDRを完全に隠蔽します。
Transit Gateway (TGW) は、多数のVPCとオンプレミス環境との多対多接続のハブとして機能します。一般的なパターンは、AWS Network Firewallやサードパーティ製アプライアンスを実行する一元化された検査VPCを設け、TGWルートテーブルがスポーク間のトラフィックをこの検査VPC経由で誘導するというものです。しかし、この設計はデフォルトのTGWの動作では破綻します。なぜなら、TGWは異なるAZにあるアタッチメントENI間でフローをハッシュするため、戻りパスが往路パスとは異なるAZに入る可能性があるからです。ステートフルファイアウォールは、SYNを確認していないフロー途中のパケットをドロップしてしまいます。
これには2つの修正を同時に行う必要があります。第一に、検査VPCのTGWアタッチメントでアプライアンスモードを有効にします。これにより、各双方向フローが同じAZのENIに固定され、往路と復路が同じファイアウォールエンドポイントを通過するようになります。第二に、スポークアタッチメントが検査VPCアタッチメントにトラフィックを送信し、検査VPC上の独立した検査後ルートテーブルがトラフィックを正しいスポークに返すように、TGWルートテーブルを設定します。どちらか一方（ルートテーブルなしのアプライアンスモードのみ、またはアプライアンスモードなしのルートテーブルのみ）を省略すると、非対称ルーティングによるパケットドロップが依然として発生します。
Network Firewall自体はSuricata互換のルールを使用し、フロー状態を維持するために対称ルーティングに依存します。これを検査VPCとスポークVPCの両方でFlow Logsと組み合わせることで、どのスポークがセッションを開始したか、そしてファイアウォールがそれを許可したかドロップしたかを証明するために必要なフォレンジックの追跡情報が得られます。
実践的な問題：ユースケースシナリオ
シナリオ： Meridian Financialは、マルチアカウントのAWS環境を運用しており、us-east-1リージョンの3つのアベイラビリティゾーンにまたがる本番VPC群が、AWS Transit Gatewayによって中央のセキュリティVPCに接続されています。彼らは各AZのNAT Gatewayをエグレスに、パートナーSaaS用にはS3ゲートウェイエンドポイントとインターフェースエンドポイント（PrivateLink）を、そしてSecurity GroupとNACLに加えて一元化されたAWS Network Firewallを使用しています。VPC Flow LogsはモニタリングのためにCloudWatchにストリーミングされています。
課題： ある本番EC2インスタンスが、外部IPおよびS3へのラテラルムーブメント（横方向の侵入）とデータ窃取を試みている疑いがあります。Meridianは、他のビジネスクリティカルなVPCを中断させることなく、AZをまたいで迅速に封じ込める必要があります。
推奨アプローチ：
- 侵害されたインスタンスのSecurity Groupを、すべてのアウトバウンド/インバウンドを拒否する制限的な「隔離用」SGに置き換えて即座に隔離し、Systems Managerによる自動修復のためにインスタンスにタグを付けます。同時に、サブネットレベルのNetwork ACLルールを適用して、疑わしい外部IPレンジへのエグレスをブロックします。
- 影響を受けるVPCのTGWルートテーブルアタッチメントを削除または隔離用TGWルートテーブル（ブラックホール、または他のアタッチメントへのルートなし）に変更することで、Transit Gateway上でVPCを隔離し、他のVPCへのラテラルムーブメントを停止します。
- TGW/ルートテーブルのエントリを更新して検査を強制し、既知の悪意のある宛先をブロックすることで、VPCの残りのエグレスを一元化されたAWS Network Firewall経由にリダイレクトします。AZごとのNAT Gatewayを維持することでAZの独立性を保ち、回復力のある検査済みエグレスを確保します。
- S3/DynamoDBゲートウェイエンドポイントに制限的なVPCエンドポイントポリシーを適用して、承認されていないプリンシパルからのPut/Getを拒否することで、データプレーンの制御を強化します。また、内部APIがインターネットパスを回避するためにインターフェースエンドポイント（PrivateLink）を使用するようにします。
- VPC Flow LogsをCloudWatch Logs InsightsおよびAWS CloudTrailと併用してフォレンジックを実行し、その後、修復（再イメージ化、キーのローテーション）を行い、検証後にのみインスタンスを再導入します。ルールはAWS Firewall Manager/AWS Configを介して強制します。
理論的根拠： この手順は、ホストとネットワークの両方のレイヤーで、迅速かつ最小権限の原則に基づいた封じ込めを提供します。Network FirewallとTransit Gatewayルーティングで検査を一元化して爆発半径を最小限に抑え、AZごとのNATでAZの回復力を維持し、そして説明責任のある調査のためにVPC Flow Logsを使用します。これはAWSの多層防御のベストプラクティスに沿ったものです。
← データ保護とS3 · すべてのドメイン · エッジとアプリケーションセキュリティ →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →