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.

CloudFrontの地理的制限と国レベルのブロッキング

CloudFrontには国別にトラフィックをブロックする2つのメカニズムがあり、コストと機能性の観点からどちらを選択するかが重要です。組み込みの地理的制限機能（ジオブロッキングとも呼ばれる）は、ディストリビューションに直接設定され、ビューワーのIPから導出された国の許可リストまたはブロックリストに対してエッジでリクエストを評価します。これは無料で、ルールの評価を必要とせず、オリジンフェッチが発生する前にHTTP 403を返します。「X国からの訪問者をブロックする」といった単純なコンプライアンスシナリオには、これが最も安価でシンプルな選択肢です。

もう一つの選択肢はWAFのジオマッチステートメントで、こちらはより柔軟です。国の照合をURIパス、ヘッダー、レート制限と組み合わせたり、それらを否定（「/adminに対してのみA国を許可する」など）したりできます。ロジックが条件付きの場合、WAFが必要になります。地理的制限だけでは「特定のパスに対してのみX国をブロックする」といった表現はできません。要件が単純な国単位のブロックであり、WAFのリクエストごとのコストを避けたい場合は、ネイティブの地理的制限を選択してください。

プライベートコンテンツのための署名付きURLと署名付きCookieの比較

CloudFrontは、オリジン（S3バケット、ALB、またはメディアオリジン）をオリジンアクセスコントロールやカスタムヘッダーの背後に隠したまま、認可されたプライベートコンテンツを配信するための2つの方法をサポートしています。

署名付きURL: 各URLが署名とポリシーを持ちます。単一ファイルのダウンロードや、ファイルごとのアクセス制御が必要な場合（例：一度きりのソフトウェアインストーラーのリンク）に最適です。
署名付きCookie: クライアントは認証サービスから一度CloudFront-Policy、CloudFront-Signature、CloudFront-Key-Pair-IdのCookieセットを受け取ります。それ以降、一致するパスパターンへのすべてのリクエストは、URLを書き換えることなく自動的に認可されます。

HLSビデオストリーミングのように、1回の再生セッションでマニフェストから参照される何千もの.tsセグメントをフェッチする場合、署名付きCookieの方が劇的にシンプルです。マニフェスト内のすべてのセグメントURLを個別の署名付きURLで書き換えることも可能ですが、レイテンシーと複雑さが増します。サブスクライバーが内部のユーザーストアに対して認証された後、ストリーミングのパスパターンをスコープとしてCookieを設定します。

ワイルドカード署名付きCookieの標準的なポリシーは次のようになります。

{
  "Statement": [{
    "Resource": "https://d123.cloudfront.net/videos/*",
    "Condition": {
      "DateLessThan": {"AWS:EpochTime": 1735689600},
      "IpAddress":    {"AWS:SourceIp": "203.0.113.0/24"}
    }
  }]
}

これをオリジンアクセスコントロール (OAC) またはオリジン側でWAFによって検証されるシークレットカスタムヘッダーと組み合わせることで、ユーザーがCloudFrontをバイパスして直接オリジンにアクセスするのを防ぎます。

AWS WAF: マネージドルール、ATP、およびレートベースのルール

ワークロードがCloudFrontの背後にある場合、Web ACLはリージョナルなALBではなく、CloudFrontディストリビューションにアタッチします。エッジへのアタッチは、何百ものPOP（攻撃者により近い場所）で悪意のあるリクエストを終了させます。これにより、DDoS中のオリジン負荷が軽減され、ブロックされたトラフィックがVPCを通過しないため、オリジンからのエグレスも低減します。WAFをALBにのみアタッチすると、ボリューム型のフラッド攻撃がリージョナルなロードバランサーに到達し、LCUを消費してしまいます。また、クロスリージョン攻撃は、グローバルなエッジネットワークではなく、単一のリージョンで処理されることになります。

組み合わせるべき主要なルールグループ：

AWSマネージドルールセット: AWSManagedRulesCommonRuleSet（OWASPトップ10スタイル）、AWSManagedRulesKnownBadInputsRuleSet、AWSManagedRulesAmazonIpReputationListは、ほぼチューニングなしで広範なカバレッジを提供します。
アカウント乗っ取り防止 (ATP): AWSManagedRulesATPRuleSetは、指定したログインエンドポイントを検査し、クレデンシャルスタッフィングのパターンを追跡し、送信された認証情報を侵害された認証情報のデータベースと照合し、漏洩したパスワードを再利用するボットをブロックします。ユーザー名とパスワードの正確なログインパスとJSONボディのフィールド名を設定する必要があります。
レートベースのルール: 単一IPからのリクエスト数を5分間のウィンドウで制限します（例：2,000リクエスト）。/searchのスクレイピングが/の匿名ブラウジングに影響を与えないように、URIやメソッドでスコープを限定します。レートベースのルールは、レイヤー7のボリューム型攻撃やブルートフォースによる列挙を緩和します。

WAFルールの簡略化されたブロック：

Rules:
  - Name: RateLimitLogin
    Priority: 1
    Action: { Block: {} }
    Statement:
      RateBasedStatement:
        Limit: 500
        AggregateKeyType: IP
        ScopeDownStatement:
          ByteMatchStatement:
            SearchString: /api/login
            FieldToMatch: { UriPath: {} }
            PositionalConstraint: STARTS_WITH
            TextTransformations: [{ Priority: 0, Type: LOWERCASE }]

ACM証明書、DNS検証、およびCloudFront

CloudFrontの場合、証明書はオリジンがどこにあってもus-east-1（バージニア北部）のACMでプロビジョニングする必要があります。これは、CloudFrontがそのリージョンから証明書を読み取るグローバルサービスであるため、厳格な要件です。ALBのようなリージョナルサービスは、ALB自身のリージョンから証明書を読み取ります。

自動更新したいパブリック証明書には、常にRoute 53のCNAMEレコードを使用したDNS検証を使用してください。ACMは、検証用のCNAMEが公開されている限り、DNS検証された証明書を自動的に更新します。Route 53はこのプロセスを非常に簡単にします（コンソールではリクエスト中に「Route 53でレコードを作成」オプションが提供されます）。対照的に、Eメール検証は、ドメインの5つのアドレス（admin@、administrator@、hostmaster@、postmaster@、webmaster@）とWHOISの連絡先に確認メールを送信します。これらのメールボックスは存在しないか、企業のメールフィルターによって隔離されることが多く、有効期限が切れる60日前に更新が失敗し、防げたはずの障害を引き起こします。Eメール検証のクリックを自動化する方法はありません。

マルチリージョンのALBに対する正しい更新パターンは次のとおりです。リージョンごとにDNS検証されたACM証明書をリクエストし、検証用CNAMEをRoute 53に一度だけ公開し、証明書をALBリスナーにアタッチし、あとはACMに更新と再デプロイを任せます。人間の介入は発行時で終了します。

DNSSECとRoute 53

Route 53のホストゾーンでDNSSEC署名を有効にすると、ドメインに対するDNSスプーフィングやキャッシュポイズニングを防ぐことができます。Route 53はKMS（us-east-1の非対称ECCキー）でKSKを管理します。あなたはレジストラでDSレコードを公開する必要があります。DNSSEC署名はゾーンの名前解決を保護するものであり、DNSトラフィックを暗号化する（それはDoH/DoTの役割です）ものでも、CloudFrontのTLSに影響を与えるものでもないことに注意してください。

レスポンスヘッダー: ポリシーとLambda@Edgeの比較

CloudFrontは、Strict-Transport-Security、X-Frame-Options、X-Content-Type-Options、Content-Security-Policyなどのセキュリティヘッダーを自動的に挿入しません。オリジンが変更できない場合（レガシーなS3サイト、サードパーティのオリジンなど）、2つの選択肢があります。

レスポンスヘッダーポリシー: ネイティブで宣言的なCloudFrontの機能です。マネージドポリシーまたはカスタムポリシーをキャッシュビヘイビアにアタッチして、HSTS、CORS、セキュリティ、およびカスタムヘッダーを追加します。コード不要、コールドスタートなし、呼び出しごとのコストなしのため、これがデフォルトの選択肢となるべきです。
Lambda@Edge (ビューワーレスポンスまたはオリジンレスポンス): リクエストごとにCSPのnonceを変える、リクエスト属性に基づいてヘッダーを書き換えるなど、動的なロジックが必要な場合に使用します。シンプルさと引き換えに柔軟性を提供し、リクエストごとのコストが追加されます。

マネージドレスポンスヘッダーポリシーのSecurityHeadersPolicyは、一般的なベースラインを1つのアタッチメントでカバーします。

よくある落とし穴の解説

パブリックACM証明書をEメール検証でリクエストすることは、更新が、ほとんどの組織が監視していないかスパムに振り分けてしまう一般的なアドレスに送信されたメールを人間が読むことに依存するため、まさに脆弱です。Route 53によるDNS検証は、人間の介在を完全に排除します。

WAFをALBにのみアタッチすることは、理論上は同等に見えますが、攻撃トラフィックをリージョン内に強制的に引き込み、ALBのキャパシティを消費します。CloudFrontのエッジにアタッチされたWAFは、数百のPOPでブロックするため、分散型のフラッド攻撃はグローバルに吸収され、オリジンのエグレスは低く保たれます。これはDDoS攻撃中に非常に重要です。

CloudFrontが自動的にセキュリティヘッダーを追加すると想定すると、侵入テストの失敗につながります。ディストリビューションはオリジンが送信するヘッダーをそのままプロキシします。X-Frame-Options: DENY、HSTS、CSPを挿入するには、レスポンスヘッダーポリシーまたはLambda@Edge関数を明示的にアタッチする必要があります。

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

シナリオ: Meridian Financialは、グローバルに分散された顧客ポータルと社内レポートポータルをAWS上で運営しています。パブリックトラフィックはAmazon CloudFrontを経由して、動的API用のApplication Load Balancerとプライベートレポート用のS3オリジンにルーティングされます。DNSはRoute 53にあり、TLS証明書はAWS Certificate Manager (ACM)によって発行されています。

課題: 攻撃者が複数の国からアカウントのスクレイピングとクレデンシャルスタッフィングを行っており、オリジンエンドポイントを直接叩くことでCloudFrontをバイパスし、プライベートレポートをダウンロードしています。これにより、オリジンの過負荷とデータ漏洩が発生しています。

推奨アプローチ:

CloudFrontを唯一のパブリックエントリポイントとして設定し、CloudFrontの地理的制限を適用して問題のある国をブロックします。Origin Access Control (OAC)を有効にし、S3/ALBのオリジンポリシーをロックして、CloudFrontのみがオリジンコンテンツを取得できるようにします。
ユーザーごとのプライベートレポートは、署名付きCookieではなくCloudFrontの署名付きURL（短いTTL）で提供し、各ダウンロードが個別に認可され、監査可能になるようにします。
AWS Managed Rulesを使用してAWS WAFをCloudFrontディストリビューションにアタッチし、AWS WAF Bot Control（高度な脅威保護）を有効にし、レートベースのルールとCAPTCHAチャレンジを作成して、スクレイピングとクレデンシャルスタッフィングを緩和します。
ACMでTLS証明書をプロビジョニングし（CloudFrontディストリビューション用はus-east-1）、Route 53経由のDNS検証を使用し、Route 53のエイリアスレコードをCloudFrontディストリビューションに発行します。
Route 53のホストゾーンでDNSSECを有効化し、CloudFrontとWAFのアクセスログをS3に記録するように有効化し、DDoSの可視性とアラートのためにCloudWatchアラームとオプションのAWS Shield Advancedを作成します。

論理的根拠: OACとWAFを使用してすべてのトラフィックをCloudFront経由に強制することで、最小権限のオリジンアクセスが強制されます。地理的制限とレートベース/WAF保護が不正なトラフィックを停止させ、署名付きURLがオブジェクトごとの認可を提供し、DNSSECを伴うACM+DNS検証がAWSのベストプラクティスに従って信頼されたTLSとDNSの完全性を保証します。

AWS WAFのルールとALBおよびCloudFrontとの統合

AWS WAFは、順序付けられたルールで構成されるWeb ACLに対してHTTP(S)リクエストを評価するレイヤー7ファイアウォールです。各ルールはリクエストの属性（URI、ヘッダー、ボディ、クエリ文字列、ソースIP）を検査し、終了アクション（Allow, Block, Challenge, CAPTCHA）または非終了アクション（Count）を返します。Web ACLは、CloudFrontディストリビューション、Application Load Balancer、API Gateway、AppSync、Cognitoユーザープール、およびApp Runnerサービスにアタッチします。CloudFrontにアタッチする場合、ACLはエッジで実行され、us-east-1（グローバル）スコープで作成する必要があります。ALBの場合は、ロードバランサーと同じリージョンに作成する必要があります。

レートベースのルールは、単一のIP（または転送されたIPヘッダー、あるいはURIとIPの組み合わせなどの集約キー）から到着するリクエストの数を、5分間のローリングウィンドウで追跡します。カウントが設定されたしきい値を超えると、レートが制限値を下回るまでルールのアクションが発動します。AWS WAFは攻撃者のリストを数秒で継続的に更新するため、レートベースのルールは、少数で変化するIPセットからの大量の不正利用に対する標準的な解決策です。手動でIPセットをキュレーションする必要がなく、最初のルールをデプロイした後の運用オーバーヘッドは実質的にゼロです。

{
  "Name": "RateLimitPerIP",
  "Priority": 10,
  "Statement": {
    "RateBasedStatement": {
      "Limit": 2000,
      "AggregateKeyType": "IP"
    }
  },
  "Action": { "Block": {} },
  "VisibilityConfig": {
    "SampledRequestsEnabled": true,
    "CloudWatchMetricsEnabled": true,
    "MetricName": "RateLimitPerIP"
  }
}

IPセットは、ルールからIPSetReferenceStatementで参照される、CIDR範囲の再利用可能なリストです。これらは、地理的に制限された管理エンドポイントや、脅威インテリジェンスフィードからの既知の不正な範囲など、決定論的なブロック/許可リストがある場合に適切なプリミティブです。カスタムルールは、論理演算子AndStatement、OrStatement、NotStatementを使用して複数のステートメントを組み合わせることで、「米国以外の国から/loginへのリクエストで、かつ特定のヘッダーがないものをブロックする」といった条件を表現できます。

DDoS緩和レイヤーおよびオリジン保護としてのCloudFront

CloudFrontは、トラフィックがALBやEC2フリートに到達するずっと手前のAWSエッジで、ボリューム型攻撃やステート枯渇型攻撃を吸収します。すべてのエッジロケーションではAWS Shield Standardが自動的に実行され、SYNフラッド攻撃やリフレクション攻撃の緩和を無料で提供します。ALBの前にCloudFrontを配置することで、攻撃対象領域をエッジネットワークに縮小し、エッジスコープのWAF、地理的制限、TLS終端を有効にできます。

この緩和策は、攻撃者がALBのDNS名を直接叩いてCloudFrontをバイパスできない場合にのみ有効です。この経路を強化するには2つのメカニズムがあります。第一に、CloudFrontがシークレットのカスタムオリジンヘッダー（例：X-Origin-Verify: <random-value>）を挿入するように設定し、ALBのリスナールールでそのヘッダー値が完全に一致しないリクエストに対して403を返すように設定します。シークレットはAWS Secrets Managerを介して定期的にローテーションします。第二に、ALBのセキュリティグループを、CloudFrontのエッジIPレンジを含むAWSマネージドプレフィックスリストcom.amazonaws.global.cloudfront.origin-facingに制限します。

ALBListenerRule:
  Type: AWS::ElasticLoadBalancingV2::ListenerRule
  Properties:
    Actions:
      - Type: fixed-response
        FixedResponseConfig: { StatusCode: "403", ContentType: text/plain }
    Conditions:
      - Field: http-header
        HttpHeaderConfig:
          HttpHeaderName: X-Origin-Verify
          Values: ["!Ref OriginSecret"]
      - Field: http-header
        HttpHeaderConfig: { HttpHeaderName: X-Origin-Verify, Values: ["*"] }
    Priority: 1

CloudFront経由のトラフィックを強制せずに、単にWAF ACLをALBにアタッチするだけでは、ALBのエンドポイントはパブリックに名前解決可能なままになります。攻撃者は（証明書の透明性ログ、過去のDNS、またはサブドメインの列挙によって）DNS名を発見すると、それを直接攻撃し、すべてのエッジ保護をバイパスできます。これは、「CloudFront + ALB」設計における最も一般的なアーキテクチャ上の間違いです。

Shield Advancedのメトリクス、アラーム、通知

Shield Advancedは、強化された検出、Shield Response Teamへの24時間365日のアクセス、攻撃中のスケーリングに対するコスト保護、およびアプリケーションレイヤーの攻撃の可視性を追加します。しかし、攻撃が発生したときに自動的にEメールやSMSを送信するわけではありません。通知はCloudWatchを通じて明示的に設定する必要があります。

Shield Advancedは、AWS/DDoSProtection名前空間に、保護対象リソースごとにDDoSDetectedメトリクス（攻撃中は値が1）とDDoSAttackBitsPerSecond、DDoSAttackPacketsPerSecond、DDoSAttackRequestsPerSecondを発行します。DDoSDetected >= 1でCloudWatchアラームを作成し、アラームアクションとしてSNSトピックを指定します。その後、SNSがEメール、SMS、チャット、またはLambdaレスポンダーにファンアウトします。

aws cloudwatch put-metric-alarm \
  --alarm-name ShieldDDoSDetected \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:secops-alerts

Shield Advancedが「単にメールをくれる」と思い込むのはよくある誤解です。CloudWatchアラームとSNSサブスクリプションがなければ、唯一のシグナルはShieldコンソールとAWS Health Dashboardのイベントだけです。

自動化されたLambdaブロッキングとAWS Network Firewall

Network Firewallは、サブネットのルートテーブルを通過するトラフィックを検査する、ステートフルなVPC接続型のレイヤー3〜7ファイアウォールです。そのポリシーは、ステートレスおよびステートフルのルールグループで構成されます。ステートフルルールグループはSuricata互換の構文を使用します。ルールグループはAPIで管理されるため、イベント駆動型の自動化に最適なターゲットです。

一般的なパターンは、GuardDutyの検出結果（例：UnauthorizedAccess:EC2/RDPBruteForceやBackdoor:EC2/C&CActivity）に応答するものです。Security Hubが検出結果を集約し、EventBridgeがイベントパターンにマッチしてLambda関数を呼び出し、そのLambdaがUpdateRuleGroupを呼び出して、攻撃元のIPまたは侵害されたインスタンスのENIをターゲットとするドロップルールを挿入します。

def handler(event, _):
    ip = event["detail"]["findings"][0]["ProductFields"]["aws/guardduty/service/action/networkConnectionAction/remoteIpDetails/ipAddressV4"]
    new_rule = f'drop ip {ip} any -> any any (msg:"GD-block"; sid:{sid()}; rev:1;)'
    rg = nfw.describe_rule_group(RuleGroupArn=RG_ARN)
    rules = rg["RuleGroup"]["RulesSource"]["RulesString"] + "\n" + new_rule
    nfw.update_rule_group(
        RuleGroupArn=RG_ARN,
        UpdateToken=rg["UpdateToken"],
        RulesSource={"RulesString": rules})

VPCエッジでEC2インスタンスまたはCIDRとの間の双方向トラフィックをブロックする必要がある場合、Network Firewallが正しい選択です。WAFはサポートされているレイヤー7エンドポイント宛のHTTPリクエストのみを検査するため、アウトバウンドのC2トラフィックや非HTTPプロトコルを停止させることはできません。

Countアクションによるロギング、モニタリング、安全なロールアウト

すべてのWeb ACLでWAFのロギングを有効にし、CloudWatch Logs、S3、またはKinesis Data Firehoseにストリーミングします。ログには、一致したルール、アクション、リクエストヘッダー、そして（リダクションルールにより）サニタイズされたボディが含まれます。コンソールでのサンプリングされたリクエストは簡単な確認には便利ですが、過去3時間分、かつルールごとに100サンプルしか保持されません。監査やフォレンジックのためには完全なログが必要です。

Countアクションは、安全なルールロールアウトに不可欠です。新しいマネージドルールグループ（例：AWSManagedRulesCommonRuleSetやBot Controlグループ）をデプロイする際は、まずルールアクションのオーバーライドをCountに設定します。CountedRequestsのCloudWatchメトリクスとログエントリを監視し、誤検知（本来ブロックされるべきではなかった正当なトラフィック）がないかを確認します。除外設定を調整した後でのみ、アクションをBlockに切り替えます。Countフェーズを経ずにマネージドルールをいきなりBlockでデプロイすると、SizeRestrictions_BODYのようなルールが正当な大容量アップロード用のエンドポイントをブロックしたり、CrossSiteScripting_BODYがリッチテキストエディタのペイロードに反応したりして、日常的に障害を引き起こす原因となります。その際の修正方法は、グループ全体を無効にするのではなく、誤検知した特定のルールに対してスコープダウンステートメントやルールアクションのオーバーライドを追加することです。

WAFのメトリクス（BlockedRequests、AllowedRequests、CountedRequests）をCloudWatchアラームと組み合わせることで、ブロック数の急増や許可トラフィックの急減があった場合にオンコールエンジニアを呼び出し、エッジでの保護と運用上の認識とのループを閉じることができます。

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

シナリオ： Meridian Financialは、Application Load Balancer (ALB) をECSサービスの前段に配置したマルチAZのVPCで、顧客向けウェブアプリケーションを運用しており、静的および動的コンテンツをCloudFront経由で配信しています。チームはAWS WAFを使用していますが、ネットワークレイヤーの脅威に対する自動化が限定的で、サービス間のロギングに一貫性がありませんでした。

課題： 最近、ログインエンドポイントを標的とした大規模なボリューム攻撃とアプリケーションレイヤーへのトラフィックスパイクが発生し、クレデンシャルスタッフィングの試行によってALBのCPUが枯渇しました。セキュリティチームは、迅速なDDoS緩和、一貫したオリジン保護、悪意のあるIPの自動ブロッキング、そしてより厳格なルールの安全なロールアウトを必要としています。

推奨アプローチ：

グローバルなエッジでの緩和策としてALBの前段にCloudFrontを有効にし、カスタムオリジンヘッダーを検証してCloudFrontからのトラフィックのみを受け入れるようにALBを設定します。また、CloudFrontマネージドのプレフィックスリストまたは既知のIPレンジでインバウンドアクセスを制限します。
AWSマネージドのルールセットに加えて、カスタムのレートベースルールとボット検出ルールを持つAWS WAFv2をデプロイします。このWAFをCloudFrontディストリビューションとALBの両方にアタッチします。最初は、新しいカスタムルールをCOUNTモードに設定してテレメトリを収集します。
アカウントをAWS Shield Advancedに登録し、CloudFrontディストリビューションとALBを関連付けます。Shield/DDoSメトリクスを使用してCloudWatchメトリクスアラームを作成し、アラームをSNSトピックに転送して、オンコール通知やランブックのトリガーとして利用します。
ログを一元化します。CloudFront、ALB、WAF、AWS Network FirewallのログをKinesis Data Firehose経由でS3にストリーミングし、CloudWatchのメトリクス/ダッシュボードを有効にしてCOUNTモードでのルール一致数を監視します。
VPCにAWS Network Firewallをステートフルルールグループと共にデプロイし、そのロギングを有効にします。不審なパターンに対するCloudWatchメトリクスフィルターを作成し、アラームによってトリガーされるLambdaを構築して、攻撃元のIPを拒否リストに追加するようNetwork Firewallのルールグループを自動的に更新します。
合意した観測期間中、COUNTモードとダッシュボードでトラフィックを観察した後、信頼度の高いWAFルールをBLOCKに切り替えます。また、安全なロールバックとルールグループのバージョニングを伴うNetwork Firewallの自動更新を維持します。

論理的根拠： CloudFrontをWAFおよびShield Advancedと共にエッジレイヤーとして使用することで、階層的なDDoS保護が提供されます。一方、一元化されたロギング、COUNTモードでのルール検証、およびLambdaによる自動化されたNetwork Firewallの更新により、AWSのベストプラクティスに沿った、安全で可観測性のある自動化されたネットワーク防御が実現します。

← ネットワーキングとVPCセキュリティ · すべてのドメイン · ガバナンス、構成、自動化 →

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