C1000-101 Practice Questions

IBM Cloud Monitoring with Sysdig is the service specifically designed to provide deep operational visibility into the performance and health of applications, services, and platforms. It delivers full-stack telemetry, allowing administrators and DevOps teams to monitor infrastructure, services, and applications in real-time. The service includes features for creating custom dashboards, defining alerts on metrics, and troubleshooting performance issues. It is the native, fully integrated monitoring solution offered within the IBM Cloud Catalog for this purpose.

A. Splunk: Splunk is a third-party service available in the catalog, primarily focused on log data analysis, security information, and event management (SIEM), not native real-time performance and health monitoring.

C. LogDNA: This powers the IBM Cloud Log Analysis service, which is designed for aggregating, searching, and analyzing log data, rather than monitoring performance metrics and overall system health.

D. New Relic: While New Relic is a powerful Application Performance Monitoring (APM) tool available in the IBM Cloud Catalog, the native and deeply integrated IBM Cloud Monitoring service is based on Sysdig technology.

1. IBM Cloud Documentation, "About IBM Cloud Monitoring": "IBM Cloud® Monitoring provides operational visibility into the performance and health of your applications, services, and platforms. It offers administrators, DevOps teams, and developers full stack telemetry with advanced features to monitor and troubleshoot, define alerts, and design custom dashboards... The IBM Cloud Monitoring service is based on the Sysdig platform." (Source: IBM Cloud Docs, retrieved from https://cloud.ibm.com/docs/monitoring?topic=monitoring-getting-started)

2. IBM Cloud Documentation, "About IBM Cloud Log Analysis": "Use IBM Cloud® Log Analysis to add log management capabilities to your IBM Cloud architecture... You can use this service to view, monitor, and manage logs..." This documentation clearly defines its role as log management, distinct from performance monitoring. (Source: IBM Cloud Docs, retrieved from https://cloud.ibm.com/docs/log-analysis?topic=log-analysis-getting-started)

3. IBM Cloud Blog, "IBM Cloud Monitoring with Sysdig Is Now Generally Available": This official announcement details the partnership and integration, stating, "IBM Cloud Monitoring with Sysdig gives you operational visibility into the performance and health of your applications, services, and platforms." (Source: IBM Cloud Blog, "IBM Cloud Monitoring with Sysdig Is Now Generally Available," June 26, 2019)

IBM Cloud adopts a shared-responsibility model: IBM secures the cloud infrastructure itself, while each customer is accountable for anything they deploy or configure inside that infrastructure (operating systems, applications, data, network controls). Because the question focuses specifically on “security of a clients’ environments in the IBM Cloud” (that is, the resources that the customer owns and manages inside the cloud), the responsibility rests with the client. IBM’s obligation ends at the underlying physical facilities, hardware, and managed platform services.

A. The OS vendor supplies patches but does not operate or secure the customer’s deployed environment in IBM Cloud.

B. IBM secures the cloud infrastructure, not the customer’s own workloads, data, and configurations.

D. While overall cloud security is shared, the portion concerning the customer’s own environment is solely the client’s duty, not jointly managed.

1. IBM Cloud Docs – “Security and compliance overview: Shared responsibility model,” Section “Security in IBM Cloud” (docs/overview?topic=overview-security).

2. IBM Cloud Virtual Servers Documentation – “Customer responsibilities,” para. 1 & 2 (docs/vsi?topic=virtual-servers-security).

3. IBM Cloud Security White Paper v3, §3.2 “Customer workload responsibilities,” pp. 9–10.

4. NIST SP 800-144 “Guidelines on Security and Privacy in Public Cloud Computing,” §3.1 (supports provider vs. tenant delineation).

IBM Cloud Schematics is the dedicated Infrastructure as Code (IaC) service designed to automate the provisioning and management of IBM Cloud resources. It uses open-source tools, primarily Terraform, to allow users to define their cloud infrastructure in declarative configuration files. By running these files, Schematics can create, update, and manage cloud environments in a consistent, repeatable, and automated fashion. This service directly addresses the need to automate the deployment of resources like VPCs, virtual servers, and Kubernetes clusters.

A. Functions: IBM Cloud Functions is a serverless, event-driven compute platform (FaaS). Its purpose is to run code in response to triggers, not to provision infrastructure.

B. Coligo: This is not a native IBM Cloud service for automating the provisioning of cloud resources.

C. Skytap: Skytap on IBM Cloud is a specialized Infrastructure as a Service (IaaS) offering designed to migrate and run traditional, complex enterprise applications, not for general-purpose resource provisioning automation.

1. IBM Cloud Documentation - About IBM Cloud Schematics: "IBM Cloud® Schematics delivers powerful tools to automate your IBM Cloud infrastructure provisioning and management process... Schematics uses Terraform as the infrastructure-as-code engine." (Source: IBM Cloud Docs, "Getting started with Schematics", Introduction section).

2. IBM Cloud Documentation - About IBM Cloud Functions: "IBM Cloud® Functions is a Function-as-a-Service (FaaS) platform... It's a polyglot, event-driven compute platform that runs application logic in response to events or direct invocations..." (Source: IBM Cloud Docs, "About IBM Cloud Functions", Overview section).

3. IBM Cloud Documentation - About Skytap on IBM Cloud: "Skytap on IBM Cloud is an infrastructure-as-a-service (IaaS) offering that is built to run traditional enterprise applications on IBM Cloud." (Source: IBM Cloud Docs, "Getting started with Skytap on IBM Cloud", Introduction section).

In IBM Cloud VPC, a user can place a virtual-server instance in the Stopped state. When the instance is stopped, “paused billing” is automatically applied: charges for vCPUs and RAM cease, while the boot volume and any reserved public IP continue to incur minimal cost. Restarting the instance is much faster than deleting and recreating it, so paused billing offers an efficient, on-demand way to scale infrastructure up or down without incurring full runtime charges.

A. Reserved billing Provides discounted pricing for long-term, continuously-running instances; does not help rapid up/down scaling.

B. Minimum billing No such billing model exists for IBM Cloud VPC instances.

C. Suspend billing Term used in some Classic infrastructure services, not supported for VPC virtual servers.

1. IBM Cloud Docs – Virtual Private Cloud, “Stopping and starting a virtual server instance” → paragraph “Paused billing begins when the instance is stopped; vCPU and RAM charges halt.” (docs/vpc?topic=vpc-managing-instances#stop-start)

2. IBM Cloud Docs – “Pricing details for Virtual Server for VPC” → section “Paused billing (stopped instances)” (docs/vpc?topic=vpc-instance-pricing#paused-billing)

3. IBM Cloud Docs – “Best practices for cost optimization in VPC” → subsection “Use paused billing instead of deleting and recreating instances.” (docs/vpc?topic=vpc-cost-best-practices#paused)

IBM Cloud Pak for Applications is the solution specifically designed to help organizations modernize existing applications and build new cloud-native applications. It provides an integrated set of tools and runtimes, including Red Hat OpenShift, which enables a consistent development and deployment experience across any public, private, or hybrid cloud. This container-based platform directly addresses the customer's need to adopt cloud-native practices for both new and existing applications while avoiding dependency on a single cloud provider, thus preventing lock-in.

A. IBM Cloud Pak for Data: This solution is an integrated data and AI platform. Its primary purpose is to collect, organize, and analyze data, not general-purpose application development and modernization.

C. IBM Cloud Pak for Security: This solution is focused on providing security insights and threat management. It connects disparate security tools and data sources, but it is not a platform for application development.

D. IBM Cloud Pak for Automation: This solution is designed to automate business processes and workflows. While it has development components, they are specific to automation tasks, not general cloud-native application development.

1. IBM Cloud Pak for Applications Documentation: "IBM Cloud Pak for Applications is an enterprise-ready, containerized software solution for modernizing existing applications and developing new cloud-native apps that run on Red Hat OpenShift." This statement directly aligns with the customer's requirement.

Source: IBM Documentation, "IBM Cloud Pak for Applications," Welcome to IBM Cloud Pak for Applications. (Accessed for version 5.2).

2. IBM Cloud Paks Overview: The official product page describes its purpose: "Accelerate the creation of cloud-native applications by leveraging built-in developer tools and processes... Build applications on any cloud, for deployment on any cloud." This confirms its role in preventing cloud provider lock-in.

Source: IBM Official Product Page, "IBM Cloud Pak for Applications," Overview section.

3. Contrasting IBM Cloud Paks: Official documentation differentiates the Paks by function. IBM Cloud Pak for Data is for "AI Ladder," Cloud Pak for Automation is for "business automation," and Cloud Pak for Security is for "security operations." This clarifies that only Cloud Pak for Applications is centered on general application modernization and development.

Source: IBM Documentation, "IBM Cloud Paks," What are IBM Cloud Paks? section.

A "Cloud Enabled" application is an existing application, originally designed for an on-premise environment, that has been modified or reconfigured to run on a cloud infrastructure. This process often involves minimal code changes, focusing on making the application compatible with the cloud platform. This term is distinct from "Cloud Native," which refers to applications built from the ground up specifically to leverage cloud architectures and services. The key distinction is the application's origin and migration path—it was enabled for the cloud, not born in it.

A. Cloud Aware: This term describes an application that can recognize and interact with cloud services, but it does not specify the application's origin or migration pattern.

B. Cloud Based: This is a very general term for any application that runs on a cloud infrastructure. It is not specific enough, as it includes both cloud-enabled and cloud-native applications.

C. Cloud Native: This refers to applications designed and built specifically for cloud platforms, using architectures like microservices and containers, which is the opposite of a modified on-premise application.

1. IBM Cloud Learn Hub, "Cloud Native vs. Cloud Enabled": This official IBM resource explicitly defines the terms. It states, "Cloud-enabled applications are applications that were originally created to run in a traditional on-premises data center but were later modified to run on a cloud infrastructure." This directly supports the correct answer. (IBM Cloud Education, Cloud Native vs. Cloud Enabled, retrieved from ibm.com/cloud/learn/cloud-native-vs-cloud-enabled).

2. IBM Redbooks, "IBM Cloud Pak for Applications: A Primer" (SG24-8474-00): Section 1.2, "Application modernization," discusses the journey of modernizing traditional applications. It describes moving existing applications to the cloud, a process that results in them being "cloud-enabled" as a step towards potentially becoming fully cloud-native. This source distinguishes the modification of existing apps from building new ones.

3. IBM Cloud Blog, "Cloud-Native vs. Cloud-Enabled vs. Cloud-Based: What’s the Difference?": This article clarifies the terminology, defining Cloud-Enabled as "legacy, on-premises applications that have been moved to the cloud with little-to-no refactoring." It further explains that "Cloud-Based" is a generic umbrella term, making "Cloud-Enabled" the more precise answer for the scenario described. (Published on the official IBM Cloud Blog).

The client's request has two specific requirements: the service must be HIPAA compliant, and it must be a NoSQL document database. IBM Cloud Databases for MongoDB is a fully managed, document-oriented NoSQL database service. According to official IBM Cloud documentation, Databases for MongoDB is a HIPAA-ready service, meaning it can be configured to meet the technical controls and requirements for handling Protected Health Information (PHI). This service directly satisfies both of the client's stated needs, making it the correct choice.

B. Databases for Elasticsearch: While it is a HIPAA-ready NoSQL service, Elasticsearch is primarily a specialized search and analytics engine, not a general-purpose document database as requested.

C. Databases for PostgreSQL: This is an object-relational database system (SQL-based), not a NoSQL document database, and therefore does not meet a core requirement.

D. IBM Db2: This is a relational database management system (RDBMS) that uses SQL. It does not fulfill the requirement for a NoSQL database.

1. IBM Cloud Documentation, "Services enabled for HIPAA": This document lists the IBM Cloud services that are HIPAA-ready. It explicitly includes "Databases for MongoDB," "Databases for Elasticsearch," "Databases for PostgreSQL," and "Db2 on Cloud" in the list of Platform services. This confirms the HIPAA compliance aspect for all options.

Source: IBM Cloud Docs, Compliance, "Services enabled for HIPAA".

2. IBM Cloud Documentation, "About IBM Cloud Databases for MongoDB": This official documentation describes the service as follows: "IBM Cloud® Databases for MongoDB is a document-oriented database service that stores data in a JSON-like, BSON format." This confirms it is a NoSQL document database.

Source: IBM Cloud Docs, Databases for MongoDB, "Getting started with IBM Cloud Databases for MongoDB".

3. IBM Cloud Documentation, "About IBM Cloud Databases for PostgreSQL": This page states, "IBM Cloud® Databases for PostgreSQL is a fully managed service for the popular open-source object-relational database." This confirms it is a relational (SQL) database.

Source: IBM Cloud Docs, Databases for PostgreSQL, "About IBM Cloud Databases for PostgreSQL".

4. IBM Cloud Documentation, "Db2 on Cloud": The product page describes the service as a "fully managed SQL cloud database," confirming it is a relational database and not NoSQL.

Source: IBM Cloud Docs, Db2 on Cloud, "About Db2 on Cloud".

The component labeled "A" in the diagram is represented by a brick wall symbol, which is the standard and universally recognized icon for a firewall in network and system architecture diagrams. Its strategic placement at the edge of the network, intercepting all incoming traffic from users before it reaches the load balancer and internal web servers, confirms its role. A firewall acts as a security barrier, inspecting and filtering traffic based on a defined set of rules to protect the application from unauthorized access and malicious threats.

A. load balancer: The load balancer is explicitly labeled as a separate component in the architecture that receives traffic after it has passed through component A.

C. container: A container is a software package that includes an application and its dependencies. It is a deployment unit, not a network security device.

D. cluster: A cluster is a group of servers working together (e.g., the web servers). Component A is depicted as a single, distinct network device.

1. IBM Cloud Docs: In the "What is a firewall?" article, IBM defines a firewall as "a network security device that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules." This function perfectly matches the role of component A in the diagram. (Source: IBM Cloud Documentation, "What is a firewall?", retrieved from the official IBM website).

2. University Courseware: Standard computer networking textbooks used in university curricula, such as "Computer Networking: A Top-Down Approach," consistently use the brick wall symbol to represent a firewall that separates a trusted internal network from the untrusted public Internet. (Source: Kurose, J. F., & Ross, K. W. (2021). Computer Networking: A Top-Down Approach (8th ed.). Pearson. Chapter 8, Section 8.2 "Firewalls").

3. IBM Redbooks: The IBM Redbooks publication "IBM Cloud Private Application Developer's Guide" discusses the layered security model for cloud applications. It emphasizes the role of firewalls and network policies as a fundamental security component for controlling traffic flow into the cluster. (Source: IBM Redbooks, SG24-8441-00, IBM Cloud Private Application Developer's Guide, Section 2.3 "Security").

To effectively follow IBM Cloud Tutorials, a user needs tools to interact with the cloud platform and to obtain the necessary source code. The IBM Cloud Command Line Interface (CLI) is the primary tool for managing IBM Cloud resources, services, and applications from a terminal, a fundamental task in most tutorials. Git is the de facto standard for version control and is essential for cloning the starter application code and assets provided in repositories (like GitHub) for nearly all hands-on tutorials.

A. VMware is a specific virtualization solution available on IBM Cloud, not a general-purpose tool required to start with most tutorials.

B. Red Hat OpenShift is a specific container platform service on IBM Cloud; many tutorials do not involve OpenShift and use other services instead.

E. A Virtual Private Cloud (VPC) is a networking resource created within IBM Cloud, not a client-side tool a user must have to begin a tutorial.

1. IBM Cloud Documentation, "Setting up the CLI and developer tools": This official guide explicitly states, "To get started with developing apps in IBM Cloud, set up your command-line interface (CLI)..." It then provides installation instructions for the ibmcloud CLI as the foundational step. The same section often guides users on logging in via the CLI to begin work.

Source: IBM Cloud Docs, "Setting up the CLI and developer tools". (A search for this title on the official IBM Cloud documentation website will lead to the relevant page).

2. IBM Cloud Solution Tutorials: The "Before you begin" section of virtually all solution tutorials lists the required tools. For example, the "Deploy a scalable web application on Kubernetes" tutorial explicitly lists "IBM Cloud CLI" and "Git" as prerequisites. This pattern is consistent across tutorials for different services.

Source: IBM Cloud Docs, Solution Tutorial: "Deploy a scalable web application on Kubernetes", Section: "Before you begin".

3. IBM Cloud Documentation, "Getting started with IBM Cloud": The introductory guides for developers consistently direct them to two initial actions: creating an account and setting up their local environment, which includes installing the IBM Cloud CLI to interact with the platform and using Git to access code.

Source: IBM Cloud Docs, "Getting started" section. (The general "Getting started" path for developers highlights CLI setup).

The modernization roadmap is a key deliverable created during the Advise theme of the IBM Garage Method. This initial phase focuses on strategic activities, including assessing the current application portfolio, defining the target state architecture, building a compelling business case, and creating a detailed, prioritized roadmap for the transformation journey. This roadmap guides all subsequent activities in the Build, Move, and Manage phases. The Advise theme ensures that the modernization effort is aligned with business objectives before any development work begins.

A. Reason stage at Practices: "Reason" is not a standard, defined stage or theme within the official IBM Garage Method framework.

B. Develop stage at Practices: "Develop" is not a formal theme; development activities fall under the "Code" and "Deliver" practices, which occur after the strategic roadmap has been established in the Advise theme.

C. Build stage at Themes: The "Build" theme is focused on the hands-on creation of the Minimum Viable Product (MVP) according to the plan laid out in the modernization roadmap, not on creating the roadmap itself.

1. IBM Garage Method - Advise Theme Documentation: "The Advise theme includes practices to help you build your business case and create a roadmap for your transformation. The practices help you assess your current application portfolio, define your target state, and build a roadmap to get there."

Source: IBM. (n.d.). Advise: Create your roadmap to the cloud. IBM Garage Method. Retrieved from https://www.ibm.com/garage/method/themes/advise

2. IBM Cloud Architecture Center - Application Modernization: "The Advise phase is where you build the business case and the roadmap for your modernization journey. You start by assessing your application portfolio to determine which applications to modernize and what modernization pattern to use."

Source: IBM Cloud Architecture Center. (2020, October 27). Application modernization with the IBM Garage. Retrieved from https://www.ibm.com/cloud/architecture/architectures/application-modernization-ibm-garage

3. IBM Developer - Introduction to IBM Garage Method: This article outlines the key themes, stating that the Advise theme is the starting point for an engagement, where the team works with the client to "create a roadmap for transformation."

Source: Parameswaran, S. (2020, May 19). An introduction to the IBM Garage Method. IBM Developer. Retrieved from https://developer.ibm.com/articles/an-introduction-to-the-ibm-garage-method/