Amazon SCS-C02: ロギング、監査、フォレンジック — 学習ガイド

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

Amazon GuardDutyの検出結果と修復

GuardDutyはマネージド型の脅威検出サービスであり、舞台裏で3つのテレメトリーストリームを継続的に取り込みます。その3つとは、CloudTrailの管理イベント（およびオプションでS3データイベント）、VPCフローログ、Route 53 DNSクエリログです。GuardDutyがこれらのログソースを利用するために、ユーザーが個別に有効化、配信、または料金を支払う必要はありません。サービスが複製されたストリームを直接読み取るためです。このため、GuardDutyは1回のAPIコールでオンにでき、ログパイプラインのエンジニアリング作業は一切不要で、数分以内に検出結果の生成を開始できます。

検出結果には0.1から8.9の重要度の値が付与され、低（0.1–3.9）、中（4.0–6.9）、高（7.0–8.9）にマッピングされます。代表的な対応が必要な検出結果には、UnauthorizedAccess:EC2/SSHBruteForce、Backdoor:EC2/C&CActivity.B!DNS、CryptoCurrency:EC2/BitcoinTool.B、Recon:IAMUser/MaliciousIPCallerなどがあります。修復パターンは検出結果によって異なります。EC2ベースの侵害は、一般的に隔離用のセキュリティグループでインスタンスを分離し、フォレンジックのためにボリュームをスナップショットし、その後終了させることが求められます。IAMベースの検出結果では、アクセスキーをローテーションし、そのプリンシパルの最近のCloudTrailアクティビティを確認する必要があります。

マルチアカウント環境の場合、AWS Organizations経由でGuardDutyを有効化し、委任された管理者アカウント（一般的にはセキュリティツールアカウント）を指定します。委任された管理者は、サービスがオンになっているすべてのリージョンで、既存および新規のすべてのメンバーアカウントでGuardDutyを自動的に有効化できます。委任された管理者の設定がない場合、アカウントごとのGuardDutyの検出結果は各メンバー内で分離されたままになります。検出器を個別に有効化しても、それらが中央で集約されることはありません。

AWS Security Hubとアカウント横断での集約

Security Hubは、正規化と集約のレイヤーです。GuardDuty、Inspector、Macie、IAM Access Analyzer、Firewall Manager、Config、および数十のパートナー製品からの検出結果を取り込み、AWS Security Finding Format (ASFF) に変換します。また、CIS AWS Foundations、AWS Foundational Security Best Practices、PCI DSS、NIST 800-53などの標準に照らして独自のコントロールを実行します。

アカウント横断、リージョン横断の集約はGuardDutyと同じように機能します。Organizationsの委任された管理者でSecurity Hubを登録し、次に集約リージョンを指定します。これにより、他のリージョンからの検出結果がその単一のペインに複製されます。よくある間違いは、各アカウントでSecurity Hubを有効にして統合ビューを期待することです。委任された管理者と集約リージョンの設定がなければ、各アカウントは依然として自身の検出結果しか見ることができません。

Security Hub自体はメールを送信しません。通知と自動化は、デフォルトのEventBridgeバス上でSecurity Hubの検出結果イベントを照合し、それらをSNS、Lambda、Step Functions、またはSystems Manager Automationドキュメントに転送することで構築されます。

CloudTrail: 管理イベント vs データイベント

CloudTrailは2つのカテゴリのアクティビティを記録しますが、これらを混同することが、検出範囲における最も一般的なギャップです。

管理イベント: コントロールプレーンの操作 — RunInstances、CreateBucket、AttachRolePolicy、PutBucketAcl。新しい証跡ではデフォルトで有効。
データイベント: 大量の、リソースレベルの操作 — S3オブジェクトレベルのコール（GetObject、PutObject、DeleteObject、PutObjectAcl）、LambdaのInvoke、DynamoDBの項目レベルのAPIコール。デフォルトでは無効で、別途課金されます。

「誰かがPutObjectAclを使ってS3オブジェクトをパブリックにしたときに検出する」というセキュリティ要件がある場合、個々のオブジェクトに対するACLの変更はデータイベントであるため、通常の管理イベントの証跡ではこれをキャプチャできません。同様に、機密性の高いバケットからのGetObjectによるデータエグレスは、データイベントがなければ可視化されません。PutBucketAcl（バケットレベル）は管理イベントでありログに記録されますが、PutObjectAcl（オブジェクトレベル）はそうではありません。

管理アカウントまたは委任された管理者アカウントで作成された組織の証跡を使用します。これにより、すべてのメンバーアカウントのイベントが単一のS3バケットにキャプチャされ、メンバーアカウントのプリンシパルによって無効にされることはありません。証跡を以下の方法で保護します：

宛先バケットでのSSE-KMS暗号化。不正な復号を拒否するKMSキーポリシーを使用。
CloudTrailサービスプリンシパルなしでのs3:PutObjectを拒否し、削除も拒否するバケットポリシー。
ログファイルの整合性検証を有効化。これにより、改ざんを証明できるように、SHA-256で署名されたダイジェストファイルが1時間ごとに生成されます。

作成例：

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name central-ct-logs \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

aws cloudtrail put-event-selectors \
  --trail-name org-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,
                       "DataResources":[{"Type":"AWS::S3::Object",
                                         "Values":["arn:aws:s3:::sensitive-bucket/"]}]}]'

EventBridgeとSNSによるアラート

EventBridgeは、検出結果を人間や自動化されたレスポンダーに接続するルーティングの仕組みです。すべてのGuardDutyの検出結果、すべてのSecurity Hubの検出結果の更新、およびすべてのCloudTrail由来のイベントは、デフォルトのイベントバスに送られます。ルールはJSONイベントパターンを使用してフィルタリングし、1つ以上のターゲット（SNS、Lambda、SQS、Kinesis Data Firehose、Step Functions、Systems Manager）にファンアウトします。

重大度の高いGuardDutyの検出結果を、メール用のSNSトピックと分析用のOpenSearchに送るFirehose配信ストリームの両方に転送する標準的なパターン：

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": { "severity": [ { "numeric": [ ">=", 7 ] } ] }
}

Security HubのCRITICALな検出結果をメールにルーティングする場合：

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": { "Label": ["CRITICAL"] },
      "Workflow": { "Status": ["NEW"] }
    }
  }
}

メールエンドポイントは単純なSNSサブスクリプションです。配信が開始される前に、サブスクライバーはメールで送られてきたリンクを介して確認する必要があります。1つのルールで最大5つのターゲットを指定できるため、アラートと下流の分析でルールを複製する必要はありません。

パターンを作成する際は、CloudTrailの管理イベントが"detail-type": "AWS API Call via CloudTrail"で到着することを覚えておいてください。一方、データイベントは、CloudWatch Logsに発行する証跡を設定し、メトリクスフィルターを使用するか、EventBridgeのCloudTrailデータイベント統合を介してサブスクライブしない限り、デフォルトバスには表示されません。データイベントを有効にせずに、デフォルトバスで"eventName": "PutObjectAcl"に一致するEventBridgeルールを作成しても、何も一致しません。

CloudWatch Logs、Insights、メトリクスフィルター、アラーム

CloudTrail（およびVPCフローログ、アプリケーションログ）をCloudWatch Logsに送信することで、ほぼリアルタイムの検知が可能になります。メトリクスフィルターは、受信するすべてのログイベントをパターンに対してスキャンし、カスタムCloudWatchメトリクスをインクリメントします。そのメトリクスに対するCloudWatchアラームがSNSをトリガーします。

例：コンソールサインインの失敗が繰り返された場合にアラームを発報する。

aws logs put-metric-filter \
  --log-group-name /aws/cloudtrail/org \
  --filter-name ConsoleSignInFailures \
  --filter-pattern '{ ($.eventName = "ConsoleLogin") && ($.errorMessage = "Failed authentication") }' \
  --metric-transformations metricName=ConsoleLoginFailures,metricNamespace=Security,metricValue=1

CloudWatch Logs Insightsは、専用のクエリ言語を使用したアドホックなクエリ実行を提供し、アラームが発報した後のインシデント対応に役立ちます。

fields @timestamp, userIdentity.arn, sourceIPAddress, eventName

よくある落とし穴

S3オブジェクトレベルのアクティビティの欠落: PutObjectAcl、GetObject、DeleteObjectはデータイベントです。デフォルトの証跡は管理イベントのみをキャプチャします。データイベントセレクターを追加しなければ、これらのAPI名をターゲットとする検出結果、アラーム、またはEventBridgeルールは、何も通知されずに決して発行されません。
委任管理者なしでの一元的な可視性: すべてのアカウントでGuardDutyやSecurity Hubを有効にしても、結果は集約されません。検出結果は、AWS Organizationsで委任管理者を登録し、Security Hubの場合は集約リージョンを選択した後にのみ、一元的に集約されます。クロスアカウント招待は小規模な環境では機能しますが、スケールせず、アカウントごとの承諾が必要です。
フィルターにおける管理イベントとデータイベントの混同: PutBucketAcl（バケット）は管理イベントであり、標準的なEventBridgeやメトリクスフィルターで機能します。一方、PutObjectAcl（オブジェクト）は、データイベントが有効化され、同じパイプラインに配信されない限り、パターンがどれだけ精巧に作られていても機能しません。

実践的な問題：ユースケースシナリオ

シナリオ: Meridian Financialは、専用のセキュリティアカウントと一元的なログ記録アカウントを持つ、マルチアカウントのAWS Organizationを運営しています。彼らの環境には、S3内の顧客のPII、EC2/Lambda上のトランザクションAPIが含まれ、CloudTrailはすでに管理イベントを中央のS3バケットに書き込んでいます。チームは、より迅速な検知とアカウント間の協調的な対応を望んでいます。

課題: セキュリティエンジニアは、S3 GETの急増と、データ漏えいの可能性を示唆する関連するGuardDutyの検出結果を検知しましたが、アラートはノイズが多く、相関付けられたCloudTrailのコンテキストやアカウントをまたいだ自動封じ込めが欠けています。

推奨アプローチ:

すべてのメンバーアカウントでAmazon GuardDutyを有効にし、セキュリティアカウントをGuardDutyの委任管理者として指定します。S3データイベント保護を有効にして、検出結果にオブジェクトレベルのアクセス異常が含まれるようにします。
アカウントごとにCloudTrailを設定し、管理イベントを保持のために中央のS3に配信し、選択された価値の高いデータイベント（S3 GetObject/PutObject/DeleteObjectおよびLambda Invoke）を低レイテンシーでの検査のためにセキュリティアカウントのCloudWatch Logsに転送します。
セキュリティアカウントでAWS Security Hubをオンにし、メンバーアカウントとのクロスアカウント集約を有効にして、GuardDutyの検出結果、CloudTrailから派生した検出結果、Config/Inspectorの結果が一元化および正規化されるようにします。
重大度の高いGuardDutyおよびSecurity Hubの検出結果に一致するEventBridgeルールを作成し、それらをページャー通知のためにSNSに、またCloudTrailのコンテキストを使用して封じ込めアクション（APIキーの失効、IAMセッションの削除、EC2 ENIの隔離）を実行する修復用Lambdaにルーティングします。
IAMプリンシパルでスコープを絞った異常なs3:GetObjectレートに対するCloudWatch Logsメトリクスフィルターと、同じEventBridge/SNS/Lambdaパイプラインをトリガーするアラームを追加します。セキュリティアカウントでCloudWatch Logs Insightsクエリを使用して、インシデントのトリアージのために相関付けられたCloudTrailイベントでアラートを強化します。

論理的根拠: 検出結果（GuardDuty + Security Hub）を一元化し、ターゲットを絞ったCloudTrailデータイベントをCloudWatchに送信することで、EventBridge/SNS/Lambdaを介した低レイテンシーでの相関付け、アラート、自動封じ込めが可能になります。これは、検知、クロスアカウント集約、自動応答に関するAWSのベストプラクティスに沿ったものです。

CloudTrailの一元化とログの完全性

CloudTrailはAWS APIアクティビティの正式な記録であり、あらゆる監査アーキテクチャの基盤は、単一のマルチリージョン証跡です。これは、理想的にはAWS Organizations内の専用のログアーカイブアカウントにある、一元化された1つのS3バケットにログを配信します。マルチリージョン証跡は、現在のすべてのリージョンおよびAWSが将来ローンチするすべてのリージョンにおける管理イベントを自動的にキャプチャします。一方、単一リージョンの証跡は、ワークロードが他の場所で起動した瞬間に死角を生み出し、これは監査における典型的な完全性の不備です。組織レベルで適用すると、証跡はすべてのメンバーアカウントのイベントもキャプチャするため、組織に新しいアカウントが参加した場合も、アカウントごとの設定なしでカバーされます。

証跡でログファイルの検証を有効にします。これにより、CloudTrailは配信されたログファイルのSHA-256ハッシュを含む、署名付きダイジェストファイルを1時間ごとに同じS3バケットに配信します。aws cloudtrail validate-logsコマンドは、ダイジェストチェーンをたどり、改ざん、削除、または欠落を検出します。検証がなければ、防御担当者はインシデント後にログが変更されていないことを証明できず、フォレンジック証拠としての有効性が失われます。

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name corp-audit-logs \
  --is-multi-region-trail \
  --is-organization-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...
aws cloudtrail start-logging --name org-trail

配信の失敗は、ほとんどの場合、CloudTrailのバグではなく、下流のアクセス許可の問題です。S3バケットは証跡を作成する前に存在している必要があり、そのバケットポリシーは、証跡に一致するaws:SourceArn条件付きでcloudtrail.amazonaws.comにs3:PutObjectを許可する必要があります。また、オブジェクトの所有者はバケットの所有者（bucket-owner-full-control）でなければなりません。証跡がSSE-KMSを使用する場合、CMKポリシーはCloudTrailサービスプリンシパルに対してkms:GenerateDataKey*を許可する必要があり、かつすべてのコンシューマー（Athena、セキュリティエンジニア、Lambdaパーサー）はそのキーに対するkms:Decrypt権限を持っている必要があります。よくある障害モードは、ログは正常に配信されているのに、クエリロールがログ暗号化CMKに対するDecrypt権限を欠いているために、Athenaクエリが「AccessDenied」を返すというものです。これは暗号化を無効にするのではなく、キーポリシーで修正してください。

CloudWatch Logs、メトリクスフィルター、リアルタイムアラーム

CloudTrailは5分から15分のバッチでS3にログを配信します。これは過去に遡っての監査には十分ですが、リアルタイムの検知には遅すぎます。機密性の高いイベントでアラームを発生させるには、証跡をCloudWatch Logsにストリーミングする（証跡のオプション）か、特定のイベントをEventBridge経由でルーティングします。CloudWatch Logsのアプローチでは、メトリクスフィルターを使用してJSONイベントのパターンマッチングを行い、CloudWatchメトリクスをインクリメントします。これにより、CloudWatchアラームとSNS通知が起動されます。典型的な例は、ルートコンソールへのサインインです。

{ $.eventName = "ConsoleLogin" && $.userIdentity.type = "Root" }

EventBridgeは、KMSキーの無効化やIAMポリシーの変更など、範囲が狭く既知のイベントに対してより適していることが多いです。なぜなら、ルールがLogsのコストなしで直接LambdaやStep Functionsをトリガーできるからです。集計されたカウントやダッシュボード化が必要な場合は、メトリクスフィルターを使用します。

CloudWatch Logsの保持期間は、デフォルトで**無期限（Never Expire）**に設定されていますが、これはコストが高く、ほとんどの場合、適切な設定ではありません。コンプライアンス要件に合わせて、ロググループごとに明示的な保持期間を設定します（aws logs put-retention-policy）。一般的には、CloudWatchに90日間ホットデータとして保持し、サブスクリプションフィルターやKinesis Data Firehoseを介してS3に長期アーカイブします。

機密データの衛生管理のために、アカウントレベルでCloudWatch Logsのデータ保護ポリシーを適用します。これらは、マネージドデータ識別子（クレジットカード番号、AWSシークレットキー、SSNなど）を使用して、取り込み時に一致する文字列をマスクします。重要な点として、マスク解除にはlogs:Unmask権限が必要です。この権限は、緊急時用のロール（break-glass role）にのみ付与してください。ロググループを読み取れてもUnmask権限がないユーザーには、アスタリスクしか表示されません。アカウント全体のポリシーは、現在および将来のすべてのロググループに適用されます。これが正しい統制方法です。ロググループごとのポリシーは、新しいサービスが新しいグループを作成するにつれて、設定がばらばらになりがちです。

大規模なログクエリ: InsightsとAthena

2つのクエリエンジンが、異なる階層のデータに対応します。

CloudWatch Logs Insightsは、専用のクエリ言語を使用して、CloudWatch Logs内に既にあるデータをクエリします。最近の運用データ（Lambdaログ、Logs内のVPCフローログ、アプリケーションログ）に最適です。高速でスキーマ設定は不要ですが、CloudWatchの保持期間とスキャンしたGBあたりのコストに制約されます。
Amazon Athenaは、S3内のデータに対してPresto/Trino SQLを実行します。CloudTrail、ALBアクセスログ、S3に保存されたVPCフローログ、CloudFrontログに対する大規模なフォレンジッククエリに最適です。スキャンしたTBあたり5ドルのコストがかかります。スキャンコストを削減するために、日付/リージョンで**パーティション射影（partition projection）**またはGlueパーティションを使用します。

典型的なフォレンジックのユースケースは、誰がKMSキーを無効化したかを特定することです。CloudTrailのJSONはネストされているため、CloudTrailが作成したAthenaテーブルはuserIdentityを構造体（struct）として公開します。

SELECT eventTime,
       userIdentity.arn                                         AS principal,
       userIdentity.sessionContext.sessionIssuer.arn            AS assumed_role,
       userIdentity.sessionContext.attributes.mfaAuthenticated  AS mfa,
       sourceIPAddress,
       requestParameters
FROM   cloudtrail_logs
WHERE  eventName = 'DisableKey'
  AND  eventTime BETWEEN '2024-05-01T03:00:00Z' AND '2024-05-01T03:30:00Z';

ALBのボット分析には、ALBアクセスログをS3に有効化し、ログのプレフィックスに対してAthenaテーブルを定義します。次に、既知の不正なIPのテーブルと結合し、その集計結果をQuickSightで可視化します。QuickSightはAthenaからデータを読み取るため、パイプラインはALB → S3 → Athena → QuickSightとなります。ALBログをCloudWatch Logs Insightsに送信することは、ネイティブでサポートされているパスではありません。ALBログはS3にのみ送信されます。

VPCフローログはどちらの宛先にも送信できます。filter dstPort=3389 and action="REJECT"のような戦術的な調査にはLogsを選択し、月単位の傾向クエリにはS3（Parquet形式、パーティション化）を選択します。

Audit Managerによる証拠収集

AWS Audit Managerは、PCI DSS、HIPAA、SOC 2、CISなどのフレームワークにマッピングされた証拠収集を継続的に自動化します。Configルール、Security Hubの検出結果、CloudTrailイベント、リソースインベントリから証拠を収集し、コントロール評価の下にパッケージ化します。Organizationsの管理アカウントまたは委任された管理者アカウントで有効にすると、すべてのメンバーアカウントから証拠を収集し、評価レポート（マニフェスト付きの証拠をzip形式でまとめたもの）を生成します。監査人はこれを手動のスクリーンショットの代わりに受け入れます。シナリオで継続的、マルチアカウント、フレームワーク準拠の証拠が求められた場合、これが正解です。Configだけではリソースのコンプライアンスは得られますが、フレームワークへのマッピングはありません。Security Hubは検出結果を提供しますが、評価のパッケージ化は行いません。自作のAthenaレポートは継続的ではありません。

落とし穴のまとめ

ログが見つからないのをCloudTrailのせいにするのは、通常は間違いです。バケットが存在しない、バケットポリシーがCloudTrailプリンシパルを拒否している、またはオブジェクト所有権が誤って設定されている可能性があります。まずS3を確認してください。
単一リージョンの証跡は安価に見えますが、不完全な監査履歴しか生成しません。組織全体のカバレッジのためには、マルチリージョンがデフォルトの正解です。
SSE-KMSで暗号化されたログは、CMKのキーポリシーがそれらのプリンシパルにkms:Decryptを許可しない限り、Athena、Lambdaパーサー、またはエンジニアからは見えません。暗号化を無効にすることが解決策ではなく、キーポリシーを修正することが解決策です。

実践的な問題：ユースケースシナリオ

シナリオ： Meridian Financialは、本番、ステージング、および専用のログ記録アカウントを持つマルチアカウントのAWS Organizationを運営しています。その環境では、顧客向けのAPI、分析、IAMで管理されるシークレットがホストされており、インシデント対応やコンプライアンス要求をサポートするために、集中管理された改ざん検出可能なロギングと、迅速な調査ツールが必要です。

課題： 最近発生した疑わしい一連のコンソールログインとIAMポリシーの変更が何時間も気づかれず、ログの完全性とタイムリーなアラートが、フォレンジックな再構築やAudit Managerの証拠収集には不十分であるという懸念があります。

推奨アプローチ：

AWS Organizations CloudTrail（組織の証跡）をすべてのリージョンで有効にし、CloudTrailログファイルの整合性検証をオンにします。ログとダイジェストファイルを、復号を少人数のセキュリティチームに制限するキーポリシーを持つKMS CMKで暗号化された中央のS3バケットに配信し、S3アクセスロギングとバージョニングを有効にします。
CloudTrailを設定して、管理イベントと選択したデータイベントをCloudWatch Logsにストリーミングします。次に、高リスクなパターン（新しいIPからのコンソールサインイン失敗、CreateUser、PutRolePolicy）に対してCloudWatch Logsメトリクスフィルターを作成し、ページング（呼び出し）と自動化されたLambdaプレイブックのためにCloudWatch AlarmsをSNSトピックにアタッチします。
最近のイベントを対話的に調査するためにCloudWatch Logs Insightsダッシュボードをデプロイし、ログ記録アカウントで保持ポリシーに従って証拠を保持するための保持期間とライフサイクルルールを設定します。
AWS GlueでCloudTrailのS3オブジェクトをカタログ化し、大規模な遡及的分析と調査員向けのCSV証拠エクスポートを作成するために、Athenaクエリ（リージョン/日付/サービスでパーティション化）を実行します。
CloudTrail、AWS Config、IAMの証拠を自動的に証拠フォルダに収集し、コンプライアンスレビュー担当者向けに定期的なエクスポートをスケジュールするAWS Audit Managerの評価を作成します。

論理的根拠： CloudTrailを集中管理して検証し、リアルタイムのメトリクスフィルターとアラームのためにCloudWatchにストリーミングし、スケーラブルなクエリのためにAthena/Logs Insightsを使用することは、検出、不変なロギング、フォレンジック対応に関するAWSのベストプラクティスに従っています。一方、Audit Managerは監査のための証拠収集を自動化します。

← 脅威検出とアラート · すべてのドメイン · 暗号化、KMS、シークレット →

これらの問題を練習する → · 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.

試験に合格する →

Amazonを閲覧 →

Amazon SCS-C02: ロギング、監査、フォレンジック — 学習ガイド

Amazon GuardDutyの検出結果と修復

AWS Security Hubとアカウント横断での集約

CloudTrail: 管理イベント vs データイベント

EventBridgeとSNSによるアラート

CloudWatch Logs、Insights、メトリクスフィルター、アラーム

よくある落とし穴

実践的な問題：ユースケースシナリオ

CloudTrailの一元化とログの完全性

CloudWatch Logs、メトリクスフィルター、リアルタイムアラーム

大規模なログクエリ: InsightsとAthena

Audit Managerによる証拠収集

落とし穴のまとめ

実践的な問題：ユースケースシナリオ

Pass the whole exam — not just this question

Related guides

1つのサブスクリプション。すべての試験。