Courseiva
MigrationhardMultiple ChoiceObjective-mapped

Resizing EBS Volumes in CloudFormation for SAP /usr/sap

Exhibit

Refer to the exhibit.

Exhibit:
```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Resources": {
    "SAPApplicationServer": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "InstanceType": "r5.2xlarge",
        "ImageId": "ami-0abcdef1234567890",
        "BlockDeviceMappings": [
          {
            "DeviceName": "/dev/xvda",
            "Ebs": {
              "VolumeSize": 100,
              "VolumeType": "gp3"
            }
          },
          {
            "DeviceName": "/dev/xvdb",
            "Ebs": {
              "VolumeSize": 200,
              "VolumeType": "io1",
              "Iops": 10000
            }
          }
        ]
      }
    }
  }
}
```

A company is migrating an SAP application server to AWS using CloudFormation. The template snippet is shown in the exhibit. The SAP application requires at least 300 GB of disk space for /usr/sap. Which change should be made to the template?

Quick Answer

This question is testing whether you can map a stated application storage requirement onto the specific block device in a CloudFormation template that's meant to serve it, rather than just adding capacity somewhere in the template. The SAP application server needs at least 300 GB for /usr/sap specifically, and based on the template's structure, a 100 GB root volume plus a 200 GB second volume, the second volume (/dev/xvdb) is the one intended to hold /usr/sap, since the root volume is reserved for the operating system rather than application data. Because that second volume is currently sized at only 200 GB, it falls short of the stated 300 GB requirement even though the combined total across both volumes happens to equal 300 GB; total disk space across unrelated volumes doesn't satisfy a requirement that applies to one specific mount point. The fix, then, is to increase the size of that second volume directly to at least 300 GB so the /usr/sap file system itself has sufficient space, rather than growing the root volume, which doesn't serve /usr/sap, or adding an entirely separate third volume, which would be a valid but less direct way to solve the same problem. The broader skill here is reading infrastructure-as-code templates carefully enough to identify which volume maps to which application directory, since sizing requirements in SAP scenarios are almost always tied to a specific mount point, not to the instance's total attached storage.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

Increase the size of the second volume (/dev/xvdb) to 300 GB.

The SAP application server typically needs a large disk for /usr/sap. The template currently has a 100 GB root volume and a 200 GB additional volume, total 300 GB. However, /usr/sap is usually mounted on a separate volume. The 200 GB volume is likely for /usr/sap, but 200 GB may not be enough if the requirement is at least 300 GB. The correct action is to increase the second volume size to at least 300 GB. Increasing root volume or adding a third volume are alternatives but less direct.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Change the instance type to a larger size to provide more instance storage.

    Why it's wrong here

    Instance storage is ephemeral and not suitable for SAP data.

  • Increase the root volume (/dev/xvda) size to 300 GB.

    Why it's wrong here

    /usr/sap is typically on a separate volume.

  • Increase the size of the second volume (/dev/xvdb) to 300 GB.

    Why this is correct

    The second volume is likely for /usr/sap; increase to 300 GB.

  • Add a third EBS volume of 100 GB for /usr/sap.

    Why it's wrong here

    Could work but less efficient than increasing existing volume.

About these practice questions

One of 1,616 original PAS-C01 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

1 more way this is tested on PAS-C01

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. The exhibit shows a CloudFormation template snippet. During migration, the SAP application server fails to start because the root volume is too small. What is the most efficient fix?

easy
  • A.Manually resize the EBS volume via the AWS Console and then update the stack.
  • B.Modify the template to increase VolumeSize to 100 and update the stack.
  • C.Stop the instance, modify the volume size, and start the instance.
  • D.Delete the stack and create a new one with a larger volume.

Why B: Modifying the template to increase the volume size and updating the stack is the proper Infrastructure as Code approach. Option A is wrong because modifying the volume directly is not recommended for CloudFormation-managed resources. Option C is wrong because stopping the instance is not necessary for volume modification, but the template should be updated. Option D is wrong because deleting and recreating is less efficient.

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This PAS-C01 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PAS-C01 exam.