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.

Политики управления сервисами и ограничительные барьеры на уровне организации

Политики управления сервисами (Service Control Policies, SCP) формируют внешний периметр того, что может делать любой субъект в AWS Organization. SCP — это не IAM-политика. Она ничего не предоставляет, а лишь определяет максимальные разрешения, доступные для аккаунтов в составе OU или всей организации. Разрешение Allow в IAM-политике, политике ресурса или границе разрешений будет полностью неактивно, если SCP запрещает данное действие. Именно эта асимметрия делает SCP правильным инструментом для создания ограничительных барьеров на уровне всей организации: ограничение по регионам, запрет на использование определенных сервисов, защита централизованно управляемых IAM-ролей и принудительное шифрование при создании ресурсов.

Каноническая SCP, запрещающая создание незашифрованных таблиц DynamoDB и бакетов S3, выглядит так:

Version: "2012-10-17"
Statement:
  - Sid: DenyUnencryptedS3
    Effect: Deny
    Action: s3:CreateBucket
    Resource: "*"
    Condition:
      StringNotEquals:
        s3:x-amz-server-side-encryption-aws-kms-key-id: !Ref CmkArn
  - Sid: DenyUnencryptedDdb
    Effect: Deny
    Action: dynamodb:CreateTable
    Resource: "*"
    Condition:
      "Null":
        dynamodb:SSESpecificationEnabled: "true"

Распространенная ловушка — пытаться принудительно установить правило «никто в организации не может использовать us-east-2» или «никто не может отключать CloudTrail» с помощью IAM-политик, прикрепленных в каждом аккаунте. Даже при согласовании границ разрешений и политик удостоверений локальный администратор может предоставить себе лазейку. Положиться можно только на SCP, примененную на уровне корня организации или OU, поскольку она ограничивает даже root-пользователя дочерних аккаунтов (за редким исключением нескольких действий, которые нельзя ограничить).

SCP также должны защищать роли для экстренного доступа и делегированного администрирования: добавьте явный Deny для любых действий, нацеленных на роли, такие как OrganizationAccountAccessRole или SecurityAudit, если aws:PrincipalArn вызывающего субъекта не соответствует списку утвержденных.

AWS Config, пакеты соответствия и принудительное применение в нескольких аккаунтах

AWS Config предоставляет уровень непрерывной оценки, который дополняет SCP (предотвращение), обеспечивая обнаружение (наблюдение и отчеты об отклонениях). Пакет соответствия (conformance pack) — это набор правил Config — как управляемых (например, s3-bucket-server-side-encryption-enabled), так и пользовательских на базе Lambda или Guard — упакованный в виде единого развертываемого YAML-артефакта с опциональными действиями по исправлению.

Чтобы развернуть стандартный базовый набор правил на всю организацию, используются два механизма в комбинации:

CloudFormation StackSets из управляющего аккаунта с разрешениями, управляемыми сервисом, и параметром AutoDeployment: Enabled, чтобы любой новый аккаунт, присоединяющийся к организации, автоматически получал стек, который включает регистратор Config и канал доставки. Это решает проблему начальной настройки: пакет соответствия не может оценивать аккаунт, в котором не включен Config.
Пакеты соответствия, развертываемые из аккаунта делегированного администратора (например, security-01) с помощью PutOrganizationConformancePack. Это распространяет единый набор правил на все текущие и будущие аккаунты без необходимости настраивать каждый из них вручную.

Шаблон «делегированный администратор + агрегатор» важен: он позволяет команде безопасности видеть состояние соответствия для всех аккаунтов в одном месте, при этом разрешая командам приложений добавлять свои собственные правила локально. Развертывание тех же правил напрямую из управляющего аккаунта сработало бы, но это нарушает принцип наименьших привилегий и мешает аудитам на предмет разделения обязанностей.

CloudFormation Guard, StackSets и Service Catalog

Предотвращение следует «сдвигать влево». CloudFormation Guard (cfn-guard) — это инструмент для реализации «политик как код», который анализирует шаблоны CloudFormation (или любой JSON/YAML) и оценивает их на соответствие декларативным правилам перед развертыванием. Правило Guard выглядит так:

rule s3_encrypted {
  Resources.*[ Type == "AWS::S3::Bucket" ] {
    Properties.BucketEncryption exists
    Properties.BucketEncryption.ServerSideEncryptionConfiguration[*] {
      ServerSideEncryptionByDefault.SSEAlgorithm == "aws:kms"
    }
  }
}

Встраивание этого инструмента в этап CI/CD — обычно в виде шага в Docker-контейнере, который выполняет cfn-guard validate -r rules.guard -d template.yaml — приводит к сбою конвейера до создания любого несоответствующего ресурса. При нарушении конвейер публикует сообщение в топик SNS, на который подписана команда безопасности, что обеспечивает им видимость без превращения в узкое место ручного утверждения. Полагаться только на StackSets или проверку наборов изменений CloudFormation для уведомления команды безопасности — это ловушка: ни один из этих сервисов не выдает заключения о соответствии для каждого отдельного ресурса, и к моменту создания стека ресурс уже существует в аккаунте.

Service Catalog дополняет Guard на «последней миле». Вместо того чтобы позволять разработчикам писать произвольные шаблоны CloudFormation, платформенная команда публикует проверенные продукты (базовые конфигурации VPC, шаблоны RDS, кластеры EKS) в виде портфелей Service Catalog, которые предоставляются другим аккаунтам через AWS RAM. Разработчики запускают их с ограниченными параметрами, а IAM-роль с ограничением на запуск (launch constraint) создает ресурсы с повышенными правами, которых у самого разработчика нет. Это обеспечивает аудируемую модель развертывания по принципу самообслуживания, где базовый шаблон уже прошел проверки Guard.

Сами StackSets требуют правильной настройки: используйте модель разрешений SERVICE_MANAGED при развертывании из управляющего аккаунта организации, включите доверенный доступ для CloudFormation в Organizations и тщательно настройте роли выполнения. Пара AdministrationRoleARN/ExecutionRoleName (в режиме самоуправления) или роли, связанные с сервисом (в режиме управления сервисом), должны иметь разрешение iam:PassRole для сервисной роли CloudFormation, которая фактически создает ресурсы. Если забыть прикрепить сервисную роль CloudFormation и вместо этого полагаться на учетные данные пользователя, выполняющего развертывание, это приведет к периодическим ошибкам AccessDenied для iam:PassRole — частая причина сбоев операций StackSet. Правильный подход — это одна выделенная сервисная роль на стек, имеющая только те разрешения, которые необходимы для создания заявленных типов ресурсов.

Автоматизированные конвейеры исправления

Когда Config обнаруживает несоответствие, исправление должно быть автоматическим для всего, что можно безопасно восстановить самостоятельно. Последовательность событий такова:

Config публикует событие Compliance Change в шину событий по умолчанию.
Правило EventBridge фильтрует результаты NON_COMPLIANT по определённым правилам и направляет их либо в документ Systems Manager Automation (для простых, идемпотентных исправлений, таких как включение шифрования S3), либо в функцию Lambda (для исправлений на уровне API), либо в конечный автомат Step Functions (для многоэтапных рабочих процессов, требующих утверждений, повторных попыток или межсервисной оркестрации).

Например, если срабатывает правило s3-bucket-public-read-prohibited, его исправляет runbook SSM Automation AWS-DisableS3BucketPublicReadWrite. Для более сложных процессов — скажем, когда политика ключа KMS отклоняется от эталона и её нужно согласовать, уведомив команду-владельца — Step Functions координирует действия: считывает текущую политику, сравнивает её с эталонной версией, вызывает kms:PutKeyPolicy, а затем отправляет уведомление в SNS. Хранение логики исправления в Step Functions, а не в одной функции Lambda, обеспечивает наблюдаемость каждого шага и чёткую семантику повторных попыток.

IAM Access Analyzer и проверка политик

IAM Access Analyzer отвечает на два разных вопроса. Во-первых, анализаторы внешнего доступа выявляют ресурсы (S3, KMS, IAM-роли, Lambda, SQS, Secrets Manager), политики которых предоставляют доступ субъектам за пределами определённой зоны доверия — аккаунта или организации. Включите анализатор на уровне организации из аккаунта делегированного администратора, чтобы результаты агрегировались централизованно.

Во-вторых, проверка политик и генерация политик в Access Analyzer выполняются на этапе их создания. aws accessanalyzer validate-policy возвращает предупреждения безопасности, ошибки и предложения (например, помечая слишком широкие разрешения Resource: "*" в сочетании с чувствительными действиями). Интегрируйте эту проверку в тот же этап CI/CD, что и cfn-guard, чтобы IAM-политики, встроенные в CloudFormation, проверялись перед развёртыванием. Access Analyzer также может генерировать политику с минимальными привилегиями на основе истории CloudTrail, заменяя политику с wildcard-символами на точные действия, которые роль фактически использовала. Это механический ответ на требование «обеспечить минимальные привилегии для доступа к данным» наряду с ограниченной политикой ключа KMS, которая разрешает kms:Decrypt только тогда, когда вызывающим сервисом является S3, DynamoDB, Lambda или EKS, с помощью условий kms:ViaService.

Практическая задача: сценарий использования

Сценарий: Meridian Financial управляет AWS Organization с несколькими аккаунтами, включая производственный, тестовый, песочницу и централизованный аккаунт безопасности. Они развёртывают рабочие нагрузки, используя как шаблоны CloudFormation, так и шаблоны, создаваемые разработчиками в песочнице. Владение распределено между командами, и они должны соответствовать внутренним требованиям по шифрованию данных и доступу с минимальными привилегиями.

Проблема: Разработчики в песочнице случайно создали публичные бакеты S3 и слишком разрешительные IAM-политики, которые распространились на другие аккаунты. У команды безопасности нет последовательного, автоматизированного контроля и проверки шаблонов в масштабах всей организации.

Рекомендуемый подход:

Создать политики контроля сервисов (SCP) на уровне организации, чтобы запретить публичный доступ к S3, принудительно включить шифрование бакетов и ограничить привилегированные действия IAM на корневом уровне организации для создания превентивных барьеров.
Из центрального аккаунта безопасности развернуть агрегатор AWS Config и пакеты соответствия (Conformance Packs) с помощью CloudFormation StackSets во все аккаунты и регионы для непрерывной оценки публичного доступа к S3, шаблонов прикрепления IAM-политик и соответствия требованиям шифрования.
Интегрировать правила CloudFormation Guard (cfn-guard) в конвейер CI/CD (CodePipeline/CodeBuild) и требовать использования продуктов Service Catalog для утверждённой инфраструктуры, чтобы шаблоны проходили проверку и развёртывались только соответствующие требованиям стеки.
Включить автоматическое исправление AWS Config с помощью документов SSM Automation или runbook-сценариев Lambda для высокоприоритетных находок (автоматическая блокировка публичного доступа к S3, исправление слишком широких IAM-политик) и запускать дополнительные рабочие процессы через EventBridge.
Централизованно запускать IAM Access Analyzer и проверку политик, передавать результаты в Security Hub и автоматизировать создание тикетов или запуск сценариев исправления для обнаруженных меж-аккаунтных или слишком разрешительных политик.

Обоснование: Этот подход сочетает превентивные барьеры на уровне организации (SCP), непрерывное обнаружение (Config/Conformance Packs), проверку шаблонов на ранних этапах («shift-left») (cfn-guard/Service Catalog) и автоматическое исправление с помощью IAM Access Analyzer для обеспечения минимальных привилегий и достижения последовательного управления в среде с несколькими аккаунтами в соответствии с лучшими практиками AWS.

AWS Config: правила для организаций, агрегаторы и делегированное администрирование

AWS Config — это основа для детективного контроля соответствия в AWS. Сервис непрерывно записывает конфигурации ресурсов и оценивает их на соответствие правилам — либо управляемым AWS (например, restricted-ssh, vpc-flow-logs-enabled, encrypted-volumes), либо пользовательским (реализованным с помощью Lambda или Guard). В масштабах предприятия три архитектурных решения имеют большее значение, чем сами правила: как развертываются правила, как агрегируются результаты и кто владеет инструментами.

Для развертываний в нескольких учетных записях и регионах под управлением AWS Organizations правильным подходом является назначение учетной записи делегированного администратора (обычно это учетная запись безопасности или аудита, а не управляющая учетная запись) с помощью команды

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

. Из этой учетной записи используйте PutOrganizationConfigRule или PutOrganizationConformancePack, чтобы распространить правила на все учетные записи-члены и регионы. Отказ от делегированного администрирования заставляет вас включать Config вручную в каждой учетной записи или запускать все из управляющей учетной записи — последнее нарушает принцип разделения обязанностей, а первое не масштабируется за пределы нескольких учетных записей.

Правила для организаций распространяют одно определение правила; агрегаторы собирают результаты оценок. Создайте агрегатор в учетной записи делегированного администратора с OrganizationAggregationSource, охватывающим все учетные записи и регионы. Панель управления агрегатора затем отвечает на вопросы вроде «В каких VPC в 200 учетных записях отсутствуют Flow Logs?» без необходимости жонглирования ролями между учетными записями. Обратите внимание, что агрегаторы работают только для чтения: они отображают состояние соответствия, но сами не выполняют исправления.

Пакеты соответствия (Conformance Packs) для обеспечения базового уровня

Пакет соответствия (conformance pack) объединяет правила AWS Config и действия по их исправлению в единый YAML-шаблон. AWS поставляет пакеты, сопоставленные с такими стандартами, как PCI DSS, HIPAA, NIST 800-53 и CIS. Развертывание пакета соответствия для организации из учетной записи делегированного администратора нацелено на определенные OU — например, применение более строгого пакета к OU Prod, чем к Sandbox. Это наиболее эффективный способ обеспечить единый базовый уровень соответствия в сотнях учетных записей, поскольку один вызов API распространяет набор правил и связанную с ним логику исправлений повсеместно и одновременно.

Resources:
  EncryptedVolumesRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: encrypted-volumes
      Source:
        Owner: AWS
        SourceIdentifier: ENCRYPTED_VOLUMES
  EncryptedVolumesRemediation:
    Type: AWS::Config::RemediationConfiguration
    Properties:
      ConfigRuleName: encrypted-volumes
      TargetType: SSM_DOCUMENT
      TargetId: AWSConfigRemediation-EncryptS3BucketVolume
      Automatic: true
      MaximumAutomaticAttempts: 3
      RetryAttemptSeconds: 60

Паттерны автоматического исправления

Существует два канонических пути исправления, и выбор между ними зависит от требований к задержке и сложности.

Путь встроенного исправления Config использует AWS::Config::RemediationConfiguration для вызова сценария автоматизации SSM Automation всякий раз, когда правило сообщает о статусе NON_COMPLIANT. AWS предоставляет готовые сценарии, такие как AWS-EnableVPCFlowLogs, AWSConfigRemediation-RemoveUnrestrictedSourceIngressRules и AWSConfigRemediation-EncryptSNSTopic. Этот путь является декларативным, чисто интегрируется с пакетами соответствия и идеален, когда допустима задержка в несколько минут.

Путь, управляемый через EventBridge, необходим, когда важна низкая задержка или требуется пользовательская оркестрация. Config генерирует событие Config Rules Compliance Change при каждом переходе состояния. Правило EventBridge фильтрует по detail.newEvaluationResult.complianceType = NON_COMPLIANT и направляет его в Lambda-функцию (или Step Function, или напрямую в сценарий SSM). Поскольку EventBridge срабатывает в течение нескольких секунд после оценки, становится возможным исправление менее чем за минуту.

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Затем обработчик Lambda вызывает RevokeSecurityGroupIngress для нарушающей правила группы безопасности. Какой бы путь вы ни выбрали, автоматизация должна использовать IAM-роль с минимальными разрешениями для изменения целевого ресурса. Частый сценарий сбоя — это когда правило Config показывает, что статус соответствия бесконечно переключается между NON_COMPLIANT и COMPLIANT, потому что сценарий исправления завершается с ошибкой AccessDenied — Config записывает вызов, но молча продолжает работу. Всегда проверяйте историю выполнения SSM Automation и предоставляйте роли сценария конкретные разрешения на изменение, которые ей необходимы (например, ec2:CreateFlowLogs, iam:PassRole для роли доставки flow-log и logs:CreateLogGroup).

Systems Manager Automation и Patch Manager

Сценарии автоматизации SSM Automation — это рабочая лошадка для императивного исправления. Это версионируемые документы YAML/JSON, описывающие шаги — вызовы API, утверждения, ветвление — выполняемые указанной вами IAM-ролью. Помимо исправлений, инициируемых Config, они выполняют задачи по расписанию для поддержания порядка: ротация ключей доступа, добавление тегов к неприсоединенным томам EBS или удаление остановленных инстансов через 30 дней.

Patch Manager — это подсистема SSM, которая поддерживает операционные системы в соответствии с базовым набором исправлений (patch baseline) — набором одобренных патчей, классификаций и фильтров по степени серьезности. Инстансы группируются в группы исправлений (patch groups) с помощью тега Patch Group; окно обслуживания (maintenance window) планирует запуск документа AWS-RunPatchBaseline для них. Статус соответствия передается обратно в Config и Security Hub, замыкая цикл между состоянием на уровне ОС и организационной отчетностью.

Service Catalog, CloudFormation StackSets и превентивные защитные барьеры

Обнаружение и исправление — это реактивные меры. Для предотвращения несоответствия требованиям используйте превентивные меры контроля:

Service Catalog позволяет публиковать тщательно отобранные, параметризованные шаблоны CloudFormation в виде продуктов. Разработчики могут запускать утвержденные шаблоны (например, защищенный VPC, зашифрованный кластер RDS), не имея IAM-разрешений для доступа к базовым сервисам, что обеспечивает разделение обязанностей между командой платформы и потребителями.
CloudFormation StackSets развертывают идентичные стеки в разных аккаунтах и регионах. Благодаря разрешениям, управляемым сервисом, и таргетингу на OU, одна операция позволяет развернуть рекордеры Config, IAM-роли или детекторы GuardDuty в каждом аккаунте организации, включая новые, созданные с помощью автоматического развертывания.
Service Control Policies (SCPs) — это единственный механизм, который может полностью заблокировать вызов API на уровне организации. Config и SSM не могут предотвратить вызов RunInstances без шифрования — они могут только обнаружить и исправить это постфактум. Попытка ввести жесткие запреты (например, «никаких публичных бакетов S3») исключительно с помощью правил Config оставляет временной промежуток между созданием ресурса и его исправлением. Чтобы устранить этот пробел, сочетайте правило обнаружения Config с SCP, запрещающим, например, s3:PutBucketPublicAccessBlock.

Аварийное восстановление: резервное копирование, шаблоны и контроль версий

Для достижения целевых показателей RPO/RTO необходимо, чтобы и данные, и определения инфраструктуры были восстановимыми. AWS Backup централизует политики резервного копирования для EBS, RDS, DynamoDB, EFS и FSx; политики резервного копирования на уровне организации применяют планы ко всем аккаунтам-участникам, а межрегиональные и межаккаунтные копии защищают от потери региона и компрометации аккаунта. RPO определяется частотой резервного копирования; RTO зависит от механизмов восстановления (восстановление DynamoDB на момент времени (PITR) занимает минуты; восстановление снимка RDS в другом регионе может занять час).

Восстановление инфраструктуры основано на шаблонах CloudFormation, хранящихся в CodeCommit (или другом Git-провайдере) как в единственном источнике истины. Повторное развертывание StackSet из шаблонов под контролем версий позволяет за минуты восстановить VPC, IAM и стеки приложений в регионе восстановления. Хранение шаблонов только в консоли — без репозитория — делает RTO непредсказуемым, поскольку отсутствует воспроизводимый артефакт.

Анализ типичных ошибок

Три заблуждения постоянно приводят к неверным ответам. Во-первых, рассмотрение Config как превентивной меры контроля: он проводит оценку после того, как CloudTrail зафиксировал изменение, поэтому для настоящих запретов требуются SCP. Во-вторых, настройка исправления без IAM-роли с достаточными правами — документ SSM существует, правило Config срабатывает, но сценарий исправления (runbook) завершается сбоем без уведомления из-за ошибок в разрешениях. В-третьих, запуск сервисов на уровне организации из управляющего аккаунта вместо регистрации делегированного администратора, что требует ручного включения для каждого аккаунта и мешает корректной работе агрегаторов на уровне организации.

Практическая задача: сценарий использования

Сценарий: Meridian Financial использует многоаккаунтную среду AWS под управлением AWS Organizations с отдельными аккаунтами для продакшена, разработки и безопасности. Команда безопасности должна подтверждать непрерывное соответствие внутренним стандартам и требованиям регуляторов, управляя сотнями инстансов EC2, бакетов S3 и функций Lambda в разных регионах.

Проблема: Недавний аудит выявил непропатченные инстансы EC2, публичные бакеты S3 и непоследовательное применение базовых стандартов в разных аккаунтах; исправление выполняется вручную и медленно, а превентивные меры контроля применяются неравномерно.

Рекомендуемый подход:

Назначить аккаунт безопасности делегированным администратором AWS Config и развернуть агрегатор AWS Config (Aggregator) с помощью CloudFormation StackSets для сбора данных о конфигурации и соответствии из всех аккаунтов и регионов.
Развернуть пакеты соответствия AWS Config (Conformance Packs) на уровне организации из аккаунта безопасности (с помощью StackSets), чтобы кодифицировать базовые меры контроля (публичный доступ к S3, шифрование, тегирование) для последовательного применения одних и тех же правил.
Привязать к правилам высокого риска действия по автоматическому исправлению AWS Config, которые вызывают документы AWS Systems Manager Automation (зарегистрированные как сценарии исправления, runbooks), чтобы нарушения автоматически запускали исправление через SSM Automation или Run Command.
Использовать AWS Systems Manager Patch Manager с базовыми наборами исправлений SSM (Patch Baselines) и State Manager для определения групп исправлений и автоматизации установки обновлений ОС в разных аккаунтах; передавать результаты соответствия требованиям по обновлениям в агрегатор Config.
Публиковать утвержденные шаблоны CloudFormation в AWS Service Catalog и использовать CloudFormation StackSets для развертывания или обновления соответствующих требованиям стеков; применять превентивные защитные барьеры с помощью Service Control Policies в AWS Organizations для блокировки создания запрещенных ресурсов (например, отключить возможность создания публичных бакетов S3).
Настроить Amazon EventBridge (CloudWatch Events) и SNS для уведомления команды безопасности о несоответствиях и для запуска дополнительных рабочих процессов SSM Automation при сложных инцидентах.

Обоснование: Централизация обнаружения с помощью агрегатора Config и пакетов соответствия, автоматизация исправления через SSM и применение превентивных защитных барьеров через Service Catalog/StackSets и SCP обеспечивают последовательные, проверяемые меры контроля и быстрое исправление в соответствии с лучшими практиками AWS в области безопасности, соответствия требованиям и принципа наименьших привилегий.

← Безопасность периметра и приложений · Все домены · Уязвимости →

Отработать эти вопросы → · Тесты на время на 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: Управление, конфигурация и автоматизация — Руководство по подготовке

Политики управления сервисами и ограничительные барьеры на уровне организации

AWS Config, пакеты соответствия и принудительное применение в нескольких аккаунтах

CloudFormation Guard, StackSets и Service Catalog

Автоматизированные конвейеры исправления

IAM Access Analyzer и проверка политик

Практическая задача: сценарий использования

AWS Config: правила для организаций, агрегаторы и делегированное администрирование

Пакеты соответствия (Conformance Packs) для обеспечения базового уровня

Паттерны автоматического исправления

Systems Manager Automation и Patch Manager

Service Catalog, CloudFormation StackSets и превентивные защитные барьеры

Аварийное восстановление: резервное копирование, шаблоны и контроль версий

Анализ типичных ошибок

Практическая задача: сценарий использования

Pass the whole exam — not just this question

Related guides

Одна подписка. Каждый экзамен.