Download 1Z0-1084-24 Oracle Cloud Infrastructure Developer Professional and more Exams Computer Science in PDF only on Docsity!
1Z0-1084-23 OCI Developer Professional Practice Tests
Q: 1
Among the following options, which one is NOT a selectable "Action Type" in an Oracle Cloud Infrastructure (OCI) Events rule definition? Explanation: Reference: https://docs.cloud.oracle.com/en-us/iaas/Content/Events/Task/managingrules.htm Knowledge Area:
- Streaming 2. Email
- Functions
- Notifications single Q: 2 Which of the following scenarios is NOT a suitable use case for utilizing the Oracle Cloud Infrastructure (OCI) Events service? Explanation: https://www.oracle.com/in/cloud/events-service/ Knowledge Area:
- Publishing all the OCI resource events in a specific compartment to the OCI Streaming service for later analysis. 2. Triggering a notification action when a function completes its execution.
- Capturing the OCI Monitoring service alarms and invoking autoscaling of compute instances.
- Triggering a function deployed in Oracle Functions when new files are uploaded to an OCI Object Storage bucket.
- Publishing a notification when long-lived tasks complete, such an OCI Autonomous Database backup completion.
Q: 3
What is the maximum allowable execution timeout for a function deployed within an Oracle Functions application? Explanation: Knowledge Area: 1. 2 minutes
- 5 minutes
- 30 seconds
- 60 seconds single Q: 4 Which of the following statements is NOT accurate regarding key rotation in the OCI Vault service when using a master encryption key (MEK) for encrypting Kubernetes secrets in OCI Container Engine for Kubernetes (OKE) clusters to facilitate key management? Explanation: The correct answer is: "Once rotated, older key versions can be used for encryption until they are deleted." The statement that is NOT valid about rotating keys in the OCI Vault service is: "Once rotated, older key versions can be used for encryption until they are deleted." In the OCI Vault service, when you rotate a master encryption key (MEK), a new key version is automatically generated. However, once a key is rotated and a new version is created, the older key versions are no longer usable for encryption. The purpose of key rotation is to ensure that the encryption keys are regularly updated and that older keys are no longer used to protect sensitive data. This enhances security by minimizing the impact of potential key compromises. The other statements mentioned are valid: Both software and hardware security module (HSM)-protected MEKs can be rotated. This provides flexibility in choosing the type of MEK and ensures that key rotation can be performed regardless of the encryption method used. Each key version is tracked internally with separate unique OCIDs (Oracle Cloud Identifiers). This allows for easy management and tracking of different key versions within the OCI Vault service. In summary, the statement that is NOT valid is the one suggesting that older key versions can still be used for encryption until they are deleted. Key rotation is designed to ensure the use of the latest key version and to retire older key versions to enhance security. Knowledge Area:
- Each key version is internally tracked with distinct unique OCIDs. 2. Once rotated, older key versions can be employed for encryption until they are removed.
- When an MEK is rotated, a new key version is automatically generated.
- Both software and HSM-protected MEKs can undergo rotation.
Q: 6
If the --provisioned-concurrency option is not enabled for your function, which parameter is employed to configure the duration for which an idle function will stay in memory before Oracle Functions removes its container image from memory? Explanation: Idle-timeout is the parameter that is used to configure the time period during which an idle function will remain in memory before Oracle Functions removes its container image from memory2. The idle-timeout parameter is specified in seconds and can be set when creating or updating a function2. The default value for idle-timeout is 30 seconds and the maximum value is 900 seconds (15 minutes)2. If a function has the --provisioned-concurrency option enabled, the idle-timeout parameter is ignored and the function instances are always kept in memory3.Verified References: Creating Functions, Provisioned Concurrency Knowledge Area:
- timeout
- access-timeout
- idle-timeout
- None, as this time is not configurable.
Q: 7
Which entity is responsible for patching, upgrading, and maintaining the worker nodes within Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE)? (Choose the most appropriate answer.) Explanation: The user is responsible for patching, upgrading, and maintaining the worker nodes in Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE). In OKE, the user has control over the worker nodes, which are the compute instances that run the Kubernetes worker components. As the user, you are responsible for managing and maintaining these worker nodes, including tasks such as patching the underlying operating system, upgrading Kubernetes versions, and performing any necessary maintenance activities. While Oracle provides the underlying infrastructure and support services, including managing the control plane and ensuring the availability of the OKE service, the responsibility for managing the worker nodes lies with the user. This allows you to have control and flexibility in managing your Kubernetes environment according to your specific needs and requirements. Knowledge Area:
- Oracle Support
- Automation mechanisms
- The user
- Independent Software Vendors single Q: 8 In the context of the shared responsibility model, who bears the responsibility for patching, upgrading, and maintaining the worker nodes in provisioned Oracle Container Engine for Kubernetes (OKE) clusters? Explanation: In the shared responsibility model, Oracle is responsible for securing the underlying cloud infrastructure and platform services, while customers are responsible for securing theirdata and applications within the cloud4. For provisioned OKE clusters, Oracle manages the control plane (master nodes) of the Kubernetes cluster, while customers manage the data plane (worker nodes) of the cluster5. Therefore, it is the responsibility of the customer to perform patching, upgrading, and maintaining of the worker nodes in provisioned OKE clusters5. Customers can use tools such as Terraform or kubectl to automate these tasks5. Knowledge Area:
- Oracle Support is responsible for this task. 2. It is the customer's responsibility.
- The process is automated.
Q: 11
To enforce image verification when deploying container images to Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE) clusters, considering that the master encryption key (MEK) is stored in an OCI Vault, which option should you utilize as per your organization's mandate? Explanation: To mandate image verification when deploying container images to Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE) clusters, you should enable image verification policies separately for each OKE cluster. This is enforced at the cluster level. Enabling image verification policies at the cluster level ensures that all container images deployed to the OKE cluster are automatically verified against the specified master encryption key (MEK). This helps maintain the security and integrity of the deployed microservices by ensuring that only signed and trusted container images are used. Enabling image verification policies at the cluster level allows for consistent and centralized enforcement of the verification process across all nodes and node pools within the cluster. It provides a standardized approach to image verification for the entire cluster, simplifying management and ensuring compliance with the organization's mandate. Enabling image verification policies separately for each node pool or at the pod level would introduce complexity and potential inconsistencies in the verification process. Therefore, enforcing image verification at the cluster level is the recommended approach. Knowledge Area:
- Enable image verification policies separately for each Kubemetes pod deployment because this is enforced at the pod level.
- Enable image verification policies separately for each node pool within each OKE cluster because this is enforced at the node pool level.
- Enable image verification policies separately for each OKE cluster because this is enforced at the cluster level.
- Enable Image verification policies for your OKE service control plane which will enforce this for all OKE clusters.
Q: 12
Which of the following is NOT a suitable use case for utilizing the Oracle Cloud Infrastructure (OCI) Events service? Explanation: The use case that is NOT a valid use case for leveraging the Oracle Cloud Infrastructure (OCI) Events service is "Capturing the OCI Monitoring service alarms and invoking autoscaling of compute instances." The OCI Events service is designed to provide event-driven architecture and enable automated responses to events occurring within the Oracle Cloud Infrastructure. It allows you to react to changes and activities happening within your OCI resources. The Events service can be used to trigger actions based on events like file uploads, resource changes, or task completions. However, capturing the OCI Monitoring service alarms and invoking autoscaling of compute instances is not a direct functionality provided by the OCI Events service. Autoscaling based on monitoring metrics is typically handled by the OCI Autoscaling service, which is specifically designed for that purpose. The OCI Monitoring service provides monitoring and alerting capabilities, while the Autoscaling service handles the dynamic scaling of compute instances based on predefined policies and thresholds. Knowledge Area: 1. Capturing the OCI Monitoring service alarms and invoking autoscaling of compute instances.
- Publishing a notification when long-lived tasks complete, such as an OCI Autonomous Database backup completion.
- Triggering a notification action when a function completes its execution.
- Triggering a function deployed in Oracle Functions when new files are uploaded to an OCI Object Storage bucket.
- Publishing all the OCI resource events in a specific compartment to the OCI Streaming service for later analysis.
Q: 14
Which of the following authentication methods is NOT considered valid for accessing an OCI API Gateway deployment? Explanation: OCI API Gateway supports the following authentication methods for accessing an API deployment3: HTTP Basic: The client sends a username and password with each request. The credentials are validated against a user database in Oracle Identity Cloud Service (IDCS). API Key: The client sends an API key with each request. The API key is validated against a list of keys stored in IDCS or OCI Vault. OAuth: The client obtains an access token from an authorization server (such as IDCS) and sends it with each request. The access token is validated against the authorization server and optionally checked for required scopes. JWT Token: The client obtains a JSON Web Token (JWT) from an identity provider (such as IDCS or OCI IAM) and sends it with each request. The JWT is validated against the identity provider’s public key and optionally checked for required claims. SAML Token is not a valid authentication method for accessing an OCI API Gateway deployment. SAML is an XML-based standard for exchanging authentication and authorization data between different parties, such as a service provider and an identity provider4. SAML tokens are typically used for web browser single sign-on (SSO) scenarios, not for API access4. Knowledge Area:
- HTTP Basic
- API Key
- OAuth
- SAML Token
Q: 15
To ensure that container images pushed to Oracle Cloud Infrastructure Registry (OCIR) are never deleted from the repository, what action should you take? Explanation: The correct answer is: "Edit the tenancy global retention policy." To ensure that container images never get deleted from the Oracle Cloud Infrastructure Registry (OCIR), you should edit the tenancy global retention policy. The tenancy global retention policy is a setting that determines the retention behavior for all the images in the OCIR across the entire tenancy. By editing this policy, you can define the retention behavior that suits your requirements. To edit the tenancy global retention policy, you would typically perform the following steps: Access the Oracle Cloud Infrastructure Console and navigate to the OCIR service. Go to the "Policies" section or "Settings" section in the OCIR service. Locate the tenancy global retention policy settings. Modify the retention policy to specify the desired retention behavior. In this case, you would set the policy to retain all images, ensuring they are never deleted from the repository. By setting the global policy of image retention to "Retain All Images," you can ensure that the container images in your OCIRrepository are permanently retained and not subject to deletion based on any default or automatic retention rules. The other options mentioned are not directly related to ensuring that container images are never deleted from the repository: Creating a group and assigning a policy to perform lifecycle operations on images or writing a policy to limit access to the specific repository in your compartment are access control measures and do not address the retention of images. Setting the global policy of image retention to "Retain All Images" is the correct action to achieve the desired outcome of preventing image deletion from the repository. Knowledge Area:
- Write a policy to limit access to the specific repository in your compartment.
- Create a group and assign a policy to perform lifecycle operations on images.
- Set the global policy for image retention to "Retain All Images." 4. Edit the tenancy's global retention policy.
Q: 18
How would you address the security requirement of encrypting secret information, such as database passwords, for your serverless applications developed with Oracle Functions, in accordance with your organization's corporate security standards? Explanation: The best way to store and use secret information, such as database passwords, in Oracle Functions is to use the OCI Vault service. The OCI Vault service provides encryption and decryption capabilities for sensitive data. You can use the OCI Vault service to encrypt the password and store it as an application-level configuration variable. Then, you can use the generated key to decrypt the password in your function code when you need to access the database. Verified References: Oracle Functions: Using Key Management To Encrypt And Decrypt Configuration Variables Knowledge Area:
- Use OCI Console to input the password in the function configuration section in the provided input field.
- Leverage application-level configuration variables to store passwords because they are automatically encrypted by Oracle Functions.
- Use the OCI Vault service to auto-encrypt the password and then set an application-level configuration variable to reference the auto-decrypted password inside your function container.
- Encrypt the password using the OCI Vault service and then decrypt this password in your function code with the generated key.
Q: 19
What configuration is required to enable access to a private repository in Oracle Cloud Infrastructure Registry (OCIR) from Oracle Cloud Infrastructure (OCI) Container Engine for Kubernetes (OKE)? Explanation: The necessary configuration to provide access to a private repository in OCI Registry (OCIR) from OCI Container Engine for Kubernetes (OKE) is to create a docker-registry secret for OCIR with an identity Auth Token on the cluster and specify the imagePullSecret property in the application deployment manifest. Here's the breakdown of the steps: Create a docker-registry secret for OCIR with an identity Auth Token: In order to authenticate with the private repository in OCIR, you need to create a secret in your OKE cluster that contains the necessary credentials. This can be done by generating an identity Auth Token from the OCI Console and creating a secret in the cluster using the kubectl command. Specify the imagePullSecret property in the application deployment manifest: In your application's deployment manifest (such as a Kubernetes Deployment or StatefulSet YAML file), you need to include the imagePullSecret property and specify the name of the secret you created in the previous step. This allows the OKE cluster to use the credentials from the secret to pull the docker image from the private repository in OCIR during deployment. By following these steps, you can ensure that your OKE cluster has the necessary access to the private repository in OCIR, and your application can successfully pull the required docker image during deployment. Knowledge Area:
- Create a docker-registry secret for OCIR with API key credentials on the cluster, and specify the imagePullSecret property in the application deployment manifest.
- Create a docker-registry secret for OCIR with identity Auth Token on the cluster, and specify the imagePullSecret property in the application deployment manifest.
- Create a dynamic group for nodes in the cluster and a policy that grants the dynamic group permission to read repositories in the same compartment.
- Add a generic secret to the cluster containing your identity credentials, then specify a registryCredentials property in the deployment manifest.
multiple Q: 21 In the DevOps lifecycle, what distinguishes continuous delivery from continuous deployment? (Choose three.) Explanation: The two correct differences between continuous delivery and continuous deployment in the DevOps lifecycle are: Continuous delivery is a process that initiates deployment manually, while continuous deployment is based on automating the deployment process. In continuous delivery, the software is ready for deployment, but the decision to deploy is made manually by a human. On the other hand, continuous deployment automates the deployment process, and once the software passes all the necessary tests and quality checks, it is automatically deployed without human intervention. Continuous delivery involves automatic deployment to a development environment, while continuous deployment involves automatic deployment to a production environment. In continuous delivery, the software is automatically deployed to a development or staging environment for further testing and validation. However, the actual deployment to the production environment is performed manually. In continuous deployment, the software is automatically deployed to the production environment, eliminating the need for manual intervention in the deployment process. These differences highlight the level of automation and human involvement in the deployment process between continuous delivery and continuous deployment approaches in the DevOps lifecycle. Knowledge Area:
Continuous delivery involves automation of developer tasks, while continuous deployment involves manual operational tasks.
Continuous delivery utilizes automatic deployment to a development environment, while continuous deployment involves automatic deployment to a production environment.
- Continuous delivery requires more automatic linting, while continuous deployment testing must be run manually.
- Continuous delivery is a process that initiates deployment manually, while continuous deployment is based on automating the deployment process.
Q: 22
Which open-source engine is harnessed by Oracle Cloud Infrastructure (OCI) to drive Oracle Functions? Explanation: Fn Project is the open source engine that is used by OCI to power Oracle Functions1. Fn Project is an open source, container native, serverless platform that can be run anywhere - any cloud or on-premises1. Fn Project is easy to use, extensible, and performant. You can download and install the open source distribution of Fn Project, develop and test a function locally, and then use the same tooling to deploy that function to Oracle Functions1.Verified References: Overview of Functions Knowledge Area:
- Knative
- Kubeless
- Apache OpenWhisk
- Fn Project
multiple Q: 24 Which TWO statements accurately describe Docker images and containers? (Choose two.) Explanation: Which TWO statements are correct regarding Docker images and containers? (Choose two.) Writing and building a new Dockerfile is the only way you can create new Docker images. A container can exist without an image but an image cannot exist without a container. Only one container can be spawned from a given image at a time. If multiple containers are spawned from the same image, then they all use the same copy of that image in memory. (Correct) An image is a collection of immutable layers whereas a container is a running instance of an image. (Correct) ChatGPT The correct statements regarding Docker images and containers are: If multiple containers are spawned from the same image, then they all use the same copy of that image in memory. This statement is correct. When multiple containers are created from the same Docker image, they share the underlying layers of the image in memory. Each container has its own isolated filesystem and runtime environment, but they all use the same base image, which helps in efficient resource utilization. An image is a collection of immutable layers whereas a container is a running instance of an image. This statement is also correct. Docker images are composed of multiple layers, with each layer representing a specific change or addition to the previous layer. These layers are read-only and can be shared among multiple containers. On the other hand, a container is a lightweight and isolated runtime instance created from a specific image. It is a running process that has its own filesystem, network, and runtime configuration. The statements "Writing and building a new Dockerfile is the only way you can create new Docker images" and "A container can exist without an image but an image cannot exist without a container" are incorrect. Docker images can be created in various ways, including using Dockerfiles, importing from existing images, or pulling from registries. Additionally, a container requires an image to run, so an image must exist before a container can be created from it. Knowledge Area:
- Only one container can be spawned from a given image at a time. 2. An image is a collection of immutable layers, whereas a container is a running instance of an image. 3. If multiple containers are spawned from the same image, then they all use the same copy of that image in memory.
- Writing and building a new Dockerfile is the only way you can create new Docker images.
- A container can exist without an image, but an image cannot exist without a container.
Q: 25
What is a valid concern that requires further investigation in the scenario where an organization's e-commerce application, hosted on Oracle Container Engine for Kubernetes (OKE), is unable to deploy containers from the Oracle Cloud Infrastructure Registry (OCIR) despite having the correct image paths specified in the YAML configuration? Explanation: A valid concern that needs to be further investigated in this scenario is whether the OKE cluster has a secret with the credentials of the Oracle Cloud Infrastructure Registry (OCIR) repository and if that secret is being used in the Kubernetes deployment manifest. Here's why this concern is relevant: Access to the OCIR repository: In order for the OKE cluster to pull images from the OCIR repository, it needs proper authentication credentials. These credentials are typically provided in the form of a secret, which contains the necessary information to authenticate with the registry. Secret in the deployment manifest: The Kubernetes deployment manifest defines how the application containers should be deployed. It includes specifications such as the container image, resource requirements, and environment variables. To pull images from a private repository like OCIR, the deployment manifest needs to reference the appropriate secret that contains the registry credentials. If the images are not being pulled from the designated OCIR repository, it suggests that either the secret with the OCIR credentials is missing or it is not properly referenced in the deployment manifest. Further investigation should focus on verifying the presence and correctness of the secret, as well as confirming that it is correctly referenced in the deployment manifest for the application containers. By ensuring the presence of the secret and proper configuration in the deployment manifest, the OKE cluster will have the necessary credentials to access the OCIR repository and successfully deploy the application containers. Knowledge Area:
- Security List rule for TCP port 22 needs to be added to connect to the OCIR service.
- VCN hosting the OKE cluster worker nodes needs to have a NAT gateway to access OCIR repositories.
- Identity and Access Management (IAM) credentials need to be added for each user that deploys applications to the OKE cluster.
- OKE cluster needs to have a secret with the credentials of their OCIR repository and use that secret in the Kubernetes deployment manifest.
